Reminds me of the original version of greplin, which became cue, which shutdown [1] after failure to acquire funding/achieve profit:
> Cue started out as Greplin, a search startup that indexed all of a person’s online social content off Facebook, Gmail and Twitter. Last year they pivoted and launched a personal assistant app called Cue, that turned a person’s e-mails, contacts and files into a daily agenda with key items like restaurant reservations and flight confirmations.
I was a huge fan of the initial versions of Greplin, used it all the time. It sort of got steadily worse as it went sadly.
A simple and effective update/replacement of the concept is a solid idea. Though in fairness search is not nearly as annoying as it used to be, most phones and OS broad search functions can handle quite a bit of the use case.
Some IM punters exploited issues with the primitive HTML renderering capabilities in AOL, when receiving certain HTML AOL would either take too many cycles render it, detracting from its network code cycles causing a disconnect from he server (booted), or in some cases crash. Some IMing also exploited bandwidth disparity, whereby they would send more than you could consume forcing a disconnect.
Couldn't agree more with all the comments on quality and maturity of X-Men, Spiderman, and Batman series of that era. Paired with reading the comics they really cemented the Marvel and DC universes for me.
Have add in Exo Squad! While it's not a comic book adaptation, it's a kids-targeted cartoon from that 90s era with very mature themes. Great first-gen action figures and genesis game as well.
I've rewatched the series recently (can purchase on iTunes and find on youtube) and it still holds up. Would love to see it as a live-action series and/or in cinematic form.
Wow! I completely forgot about Ronin Warriors. I need to find and rewatch them—I hope they're available somewhere. I had those action figures as well. They were great.
Which Exo figures did/do you have? (I had Lt. Marsh, Wolf, Marsala, and Phaeton or Typhonus (can't recall which).
Redis uses a skip list (doubly linked) implementation for sorted sets, here are antirez's (BDFL) comments as to why from 7 years ago:
There are a few reasons:
1) They are not very memory intensive. It's up to you basically. Changing parameters about the probability of a node to have a given number of levels will make then less memory intensive than btrees.
2) A sorted set is often target of many ZRANGE or ZREVRANGE operations, that is, traversing the skip list as a linked list. With this operation the cache locality of skip lists is at least as good as with other kind of balanced trees.
3) They are simpler to implement, debug, and so forth. For instance thanks to the skip list simplicity I received a patch (already in Redis master) with augmented skip lists implementing ZRANK in O(log(N)). It required little changes to the code.
Data structures in Redis have evolved a bit in the last 7 years. One of the main workhorses is indeed something called a "ziplist". The implementation (especially the format description at the top) is worth a read: https://github.com/antirez/redis/blob/90a6f7fc98df849a9890ab...
For those who are familiar with pre-2.6 Redis code, there used to be something called zipmap, but it was deprecated in favor of ziplist.
I have not looked at Redis code in eons, but I think it's not exactly true - all the structures are there, it's just that redis will favor ziplist for the very small ones.
A ziplist is a list of compact varying length integers (or strings) where only the bits that make a difference are stored (I contributed the 24-bit version to Redis[1]). The argument is that a sequential search over a small data structure always wins over more complex things like hash tables, skiplists, etc.
As you get more data, Redis will switch to using skiplists or whatever - there is a config setting for that (-max-ziplist-entries and -max-ziplist-value).
Elaborating on gtrubetskoy comment, ziplists are doubly linked lists (of integers and strings) encoded into an array of bytes that stores the size of both the next and previous element so you can quickly find the location of the next/previous element. This makes ziplists space efficient and have great cache efficient, but expensive to insert into since you need to reallocate the array and shift a potentially large number of elements over every time you inset/delete. These properties make ziplists useful when they are small, but not so as they get larger, so Redis will switch to different implementations once the ziplists reach a certain size.
Interestingly, Redis lists are implemented as a double linked list of ziplists, where the size of each ziplists is bounded. This gives you good caching as the quicklist is being traversed, while limiting the cost of an insertion. Redis will also compress ziplists not near the edge in order to save space.
John von Neumann -- December 28, 1903 – February 8, 1957 (cancer) -- was a Hungarian and later American pure and applied mathematician, physicist, inventor and polymath. He made major contributions to a number of fields,[2] including mathematics (foundations of mathematics, functional analysis, ergodic theory, geometry, topology, and numerical analysis), physics (quantum mechanics, hydrodynamics, and fluid dynamics), economics (game theory), computing (Von Neumann architecture, linear programming, self-replicating machines, stochastic computing), and statistics. [1]
"A von Neumann biographer, Norman Macrae, has speculated that the cancer was caused by von Neumann's presence at the Operation Crossroads nuclear tests held in 1946 at Bikini Atoll." [2]
co-founder of a very-recently Google & Atlas Venture backed startup (so not an investment deterrent; no issues on the engineering deep-dive during diligence, and received kudos on our architecture and some clever stuff we developed). love .NET and the MSFT support & team over at azure... been on it since beta circa 09'. I'm also an avid python numpy & matlab programmer, even submit patches to and support a few open source python libraries (ps: flask is my favorite web framework).
in this discourse (and that of the original article and its comments) of the original article) I've encountered a tremendous amount of opinion/perspective that contrast my own/teams, and the experiences we've had - so I'm sharing my thoughts below. I may not address each questions but it's at least a stream of consciousness evoked by the topic.
(btw: I came from an all-java shop (oracle) by way of a company they acquired in '07.)
our language is C#, target framework 4.0.
- misc: C# is semantically equivalent to Java, virtually the same for the core libraries; syntax and the nuance of the latter aside it's easy to embrace engineers from the opposing worlds within each others framework.
- diamonds in the rough: there is a treasure-trove of very smart previously inaccessible engineers toiling away in corporate waste-land, skilled in C#, and ineligible (by syntax/familiarity guidelines) for lots of startup reqs. example: we have a brilliant mathematician on our team that's been coding in C# since its release, working for investment banks where C# was the internal language of choice. as always, it's really about the person, not the language (look at what php's done to push the envelope with PHP... mysql...).
- .NET in terms of limited capability: we've written some pretty heavy non-linear optimization frameworks, stuff that while easy to prototype in python, we've found much more maintainable in C# due to the VS IDE, static typing, and the effectiveness & patterns they beget. also the efficiency inherent in some of the data structures to their static nature has been noticeably performant. (btw, latest CLR has truly dynamic types, and an independent fully dynamic runtime DLR.)
- prototyping: django's beautiful admin framework aside, .NET MVC 2 via C# and Django via Python yield very similar efforts for prototyping. MVC has a struts-like template for pushing admin stuff up quickly.
- cool/weird stuff: we've built (and had one of the best software engineering companies attest to) an incredibly innovative multi-dimensional-map for 'moving' throughout a highly constrained NP solution space during non-linear optimization. C# and Java do not support generic generics (think maps of N # of maps with X type). we have code-generate this, and their super efficient. it's something you could just bang away on at python or in lisp to prototype quickly, but you would need careful optimize and code to get performant, and also maintainable and provable (mathematically) across a multitude of types inherited for varying different sources throughout a framework. object-oriented languages w/static typing afford you this. yes it could have been done in open source C++, C or Java, but we did do it in .NET. It's one of the fun and weird things we've worked on. inspiration is/should not be limited by a language, regardless if it's correlated, it's not causal. please see auto vector regression by one of this years nobel laureate in economics or this: http://www.venganza.org/about/open-letter/ - for quick intuition as to why. :]
- liquidity/exit event, and the choice: we didn't choose .NET due to a likelihood of acquisition, or not choose it in fear of it preventing one (I mean this as in every sense except that in which .NET made our business look more compelling; hone our competitive advantage, etc.) I agree for a framework company (solely depending upon the level of the framework) this could be critical, but for most companies where at least one level of abstraction (framework included) obviates development platform dependency from a decision to use the service, it's negligible. we chose it because of how pervasive windows and its embedded and compact environments were in some of the disparate systems we're integrating with. it made life easier. it's worth stating that, whilst I stand by my first sentence, a couple of our most likely acquirers do have predominantly microsoft stacks, or are c++ based and could assimilate our development ethos quickly.
- cost of tech: we're bizspark'd which made this venture possible, I agree, without that .NET would not have been feasible decision. we would have went java or python (especially given the fantastic client-side deployments dropbox was doing w/it at the time). we would not have chosen MONO - at the time ASP.NET via Mono scaled poorly and MVC didn't exist for it (digression: absolutely no way in hell anyone should build on the old asp.net forms paradigm or hold it against .NET now that MVC is an option: even excluding the IoC weirdness and its terrible pattern, I still cringe when I see .aspx extension on a site. that said MONO for our integration platform would have been perfectly fine.
- long term cost (post 3 years): azure is not expensive, like all platforms (I have EC2 and app-engine experience) if you optimize for it, you can make it cost-effective. more importantly, if you're not earning $ or in some cases raise/preserve capital after 3 years (or until you hit $1.5m in rev per the bizspark restrictions) what kind of business are running?
- source control: TFS (team foundation server) is fantastic, from its testing framework, bug repository, and with some hacking its workflow systems it's a tool I've found as powerful (but easier to configure) than clear case, the systems we used at oracle, and myriad other variants I've worked with over the years. it's not source safe :].
- complexity: we've had to lift up the hood quite a bit to accomplish what we wanted. "the ability to patch and pull in req's for changes to FOSS software" is but one way to customize. .NET offers many, down to the many ways you can override/overload/extend even the most isolated libraries with the latest syntax sugar, to getting your hands a little dirty in MSIL. while not the FOSS way, it's possible. whether or not it's ideal is a matter of perception - e.g. when you work in (and accept) a proprietary environment.
- developer vs. engineer culture: semantics here. probably the b&b of this article, I think culture, pervasiveness (not independent of the former), and founding team/CTO experience, and biz strategy sum up to the decision as to why people do or do not use .NET. I find it difficult to place a coefficient on each of those terms but it's empirically manifest that more often than not they weigh against the choice to use .NET. strategy includes cost, only recently (~3 yrs) obviated by bizspark. it's also the market stuff I mentioned. FOSS has existed for years as an alternative - this is why it's pervaded (among other reasons). I have no data on founder XP, but I've met very few others that have experience working in .NET languages, I think this is a big contributor to start culture & personality types and where most .NET developers dwell - that's why I labeled that intersection 'diamonds in the rough'. last statement should show how those terms are not mutually exclusive.
- language/tech zealots: agreed, they're everywhere. even people I respect tremendously just have this natural predilection toward their preferred tech and its advantages.
my .2e-1
observation: have you seen the wonderful and cross-platform [android, ios, win phone] natively compiled .NET tech miguel's team @ xamarin have been working on? I suspect the # of corp clients that are leveraging that tech and the exposure to consumers the app-serving end-devices have will inspire those corp developers to create their own apps eventually... could bring a lot of .NET favoring newcomers (and different demographic) into the startup scene - neither a bad thing.
Interestingly enough this is most often the case with pure mathemetics: their proofs are pursued purely in the interest of understanding & attaining them - the implications & applications of which are sometimes unrealized for decades (a great example is Evariste Galois: his number theory and symmetry/group work was decades-later applied by physicists to define many of the laws physics appear to obey - check out the wiki).
Or a certain obscure piece of algebra discovered by one G. Boole.
(Edit: During his time, Boole's results were practically unknown except to other logicians, and certainly nobody expected to find any practical use for them. It wasn't until the 1930s when Claude Shannon realized that the algebra that now carries Boole's name could be used to analyze digital electric cirquits.)
