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.

https://www.youtube.com/watch?v=Ox5P7QyL774

https://www.youtube.com/watch?v=3ka4KY7TMTU

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.
  }