ticking
https://en.wikipedia.org/wiki/Rabin–Karp_algorithm
Rabin karp with rolling hashes is actually (not exactly but almost) what tools like rsync, or bittorent use to find chunks and differences in files. So it scales really well.
The algorithms you cite come from a time when computers looked rather different in their architectures.
Linearly scanning the entire genome from ram for example, could be significantly better than performing multiple index lookups from disk.
Many problems of bioinformatics (the text processing) aren't that hard or special anymore, a genome is tiny compared to the amount of data we have lying around elsewhere.
It should give you the same answer in 3 CPU instructions on registers instead of 2 array lookups and arithmetic in ram. XOR, hammond weight/bitcount and and equality check.
sadly it looks like they are still quite far away from their goal.
You should watch the videos on the introduction page and play a bit with the system, it's interesting to see how much interactivity and liveliness was already achieved in the 80s/90s,
So page count is not a useful metric for presentation progression and information amount.
In the beginning it was clearly marketed as a clojure ide, and if you look at the comments on HN at the time it's clear that it was perceived as such.
http://www.chris-granger.com/2012/04/12/light-table---a-new-...
https://news.ycombinator.com/item?id=3836978
>"Catering too much to other languages"? What does that even mean? Did anybody signed to the parent that it would only be for his favorite language (the "uber clojure IDE" he dreamt?)? It was due to huge community demand that LT promised to support Javascript and Python too.
This is what broke it's back though. By trying to go with all languages at once they failed to focus on getting one right first. They should have added new ones later on.
>Nobody stopped the parent or anyone else from using something existing "that actually works" or creating something even better.
I've heard it many times over the years in the clojure world, "I'd start on an editor, but it looks like LT is going to be exactly what I want so I'll just wait." Only after its failure was apparent things like Gorilla-Repl popped up.
> including having concretely inspired the Swift playground features (as the Swift designer admitted).
I'd like a source for that. LT is directly inspired by the work of Bred Victor who _worked for apple_ and Swift has at least one of the Factor devs, which is a highly dynamic language with a live coding environment.
> As if it was all a scheme to make $300K off of kickstarter. He made a lot more than that on Kickstarter, and has some Venture capital as well iirc.
Chris has a history of half finished unmaintained projects, so especially with his past I'd be suspicious.
Eve is the same, it promises to make programming mainstream but storing your UI in a Datalog DB is a huge mess. DL is great, but the stuff he does with it is just horrid.
LT has shown however that you can make a load of money of kickstarter without delivering a product, but people will still throw money at you for building the next big unfinished thing (see their new pet project with a broken architecture called EVE).
Once it's dead the space it frees up can be filled again by something that actually works.
lolnope
Most tutorials for other programming languages simply go with a text editor of your choice + a console repl.
ROS serialisation format is basically a C++ struct that gets send over the wire. You specify your .msg definition, tell the (horrible) build system that you want to use it, and the build system will compile it to deserialisation code in your language. During deserialisation of C/C++ this code will just try to recast the message from a void* buffer to a valid .msg struct.
So O(1) message parsing, nice in theory, but also what causes the rigidity that makes it harder for dynamic languages that would easily be capable to deal with a self-encoding message format.
But because you end up with this unsafe recasting "parser", you _really_ want to feed it what it expects, and this is why during tcpros handshake between two clients they will exchange hashes of the msg format that they speak.
Note that this is fundamentally different from JSON where you are adding fields. JSON _will still work_, as long as the new message is a superset of the old one.
But with ros msgs a command might end up putting your nice robotic arm into the table/human because you changed the LED from a green one to a multicoloured that has a field `color[3]` instead of `color`. The field will use up more space, and the field that came after it, say `arm-height`, will now have the color value in it.
But we got the hash of messages to protect us from this right?
NO! Because the build system does a half assed normalisation step on each .msg format in which it removes comments, reformats and reorders fields and tries to find the canonical _textual_ representation of messages. Sadly somebody forgot to keep the arity (variable/tuple/list) in there. So it gets thrown out and is not part of the hash.
Source: I build a ros-msg deserializer from scratch for clojure that can import message definitions at runtime, compiling them into ad-hock deserialisers.
public foo(Bar bar) {
bar = baz(bar);
//Lots (10+ lines) of code
return finishProcess(bar); //Note, this should have been updatedBar.
}
If foo is immutable there is no harm if something else tries to manipulate it because it will just derive a new data-structure.
There are currently horrible bugs in the very foundation of ROS, the spec of the serialisation format and its hashing, that are in `wontfix` status because the maintainers are idiots.
The arity of a field (value, array [and its arity], list) is not part of the hash of a message definition. Thus it is possible to change a message definition breaking existing protocols without the clients noticing. This is a hard to detect bug, that I've seen several times in the wild. But it won't be fixed because it would break old precompiled packages (yes one would have to recompile things gasp). So instead everything is left broken.
But hey I heard they want to change the messaging protocol to CORBA for 2.0, what could go wrong with that...
If I got to pick the universal language, it would be Lojban (a few hundred speakers), but that is not a realistic goal, teaching the other 6 Billion people a language that is already spoken by 1/7th of the population is at least plausible.
> Why would you want that...
Why would, you not want that?! Many popular programming languages are based on array indexing through pointer arithmetic, having a variable width encoding there is a horrible idea, because you have to iterate through the text to get to an index.
Length is the number of characters, which is just the number of bytes in ASCI, but has to be calculated by looking at every character in UTF-8.
I'd much rather have something that works and is simple. Than something that makes it easy for everybody and is broken.
Its broken technically and a setback socially.
Unicode itself is such a unfathomably huge project that it's impossible to do it right, too many languages, too many weird writing systems, and too many ways to do mathematical notation on paper that can't be expressed. Just look at the code pages, they are an utter mess.
Computers and ASCI were a chance to start anew, to establish english as a universal language, spoken by everybody.
The pressure on governments who would wanted to partake in the digital revolution would have forced them to introduce it as an official secondary language.
Granted english is not the nicest language, but is the best candidate we have in terms of adoption, and relative simplicity (Mandarin is another contester, but several thousand logograms are really impractical to encode.).
Take a look at the open source world, where everybody speaks english and collaborates regardless of nationality. One of the main factors why this is possible, is that we found a common language, forced on us by the tools and programming languages we use.
If humanity wants get rid of wars, poverty and nationalism, we have to find a common language first.
A simple encoding and universal communication is a feature, fragmented communication is the bug.
Besides. UTF-8 is broken because it doesn't allow for constant time random character access and length counting.
It's horrible to see what a fat greedy bastard he has become.
Taking from the OS community, giving nothing back and then even selling out to stratasys, a company that has actively fought DIY and OS 3D printers with its patents for decades.
The "911 calls should not be interrupted by torrents" is such a load of crap argument. It has nothing to do with net neutrality but is all about service level agreements.
With landlines, the main problem here is not that your neighbour could prevent you from making a 911 call by torrenting, but that his torrenting affects your bandwidth at all.
When you buy 10mbit from your ISP, you should _always_ be provided with that speed, and the ISP should take measures to ensure that. Not on a per service level, but on a per customer basis.
But instead ISPs like to sell "up to 25mbit" offers which actually means "0mbit guaranteed, the rest is lottery" because you share that "25mbit" connection with everybody on the street.
Mobile contracts are a bit trickier, because there the topology is unknown and can change anytime, but even here we can calculate a lower bound if we take into account that each lte cell can only support a few hundred [(maybe a few thousand, if you have really fancy tech and own a very wide frequency spectrum)](https://www.linkedin.com/groups/Plz-anyone-help-me-How-11807...) connections at the same time.
Even if we assumed that an lte cell can have an utopian 10.000 _active_ users using every available frequency, we would still be left with 300mbit/10.000=30kbit per user, [which is still enough for that goddamn 911 call.](http://www.erlang.com/bandwidth.html)
My favorite: Joxa a Clojure inspired (really just inspired ;)) lisp http://joxa.org/
Then there are Elixir (mentioned already) and Reia, Both seem to be inspired by Ruby. http://reia-lang.org/ http://elixir-lang.org/
Erlang has a far superior computational model an implementation than Node, it can handle way more requests faster and is newcomer friendlier as any web request is simply a message received.