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.
Have you thought about using the hammond distance, instead of the array?
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.
We actually do this in our "expensive" check. The reason that we use the 2 arrays is because in 2 array lookups, we can check for matches for all 200 guides. I probably could've made that clearer in the post - the array contains matches for ALL of the guides.
It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It's architecture is horrible, and its catering too much to other languages.
Once it's dead the space it frees up can be filled again by something that actually works.
LT didn't bring any new inventions, emacs, self, morphic, CL, they've all done some aspect of it 30 years earlier.
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).
This is why academia sucks so badly: they think because some features were released in some projects that "there is nothing new under the sun." Bull! There is still a lot to be explored and none of those projects you listed contain much of the live programming story at all (Chris Hancock at MIT did flogo II, which is more relevant than the Lisp and smalltalk projects).
To make any progress at all, we just need to stop listening to those who are living in the glory of a past that wasn't so great anyways.
I guess if you are trying to use Light Table as "the uber clojure IDE" then it was never a goal for Light Table. Intellij Cursive is probably a better editor for that. Light Table's aim was for a form of interactive programming. Anyway, using an editor as an end user is very different to just playing around with its source code, although I applaud that you have done that. I will look into "Self" some more as I don't know enough about it. Do you have some good links on Self to get me started?
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,
Not sure why this is getting downvoted. Perhaps the truth here is harsh, but it's the truth nonetheless. Perhaps not the whole truth, but at least part of it.
The part about LT overpromising and underdelivering is true.
The rest is not true, and said with a partisan rudeness to top, mostly like someone wanting to piss over LT and Chris than a genuine criticism.
It starts: "It's good that LT is finally acknowledged to have failed as "the uber clojure IDE".
It never said it was the "the uber clojure IDE", not even used any words to this effect. It was an experiment in IDEs in general, and in fact the very landing page of the project writes:
"When we released our first blog post about Light Table back in April of 2012, it was just a new concept for an IDE. Thanks to the community, our concept was pushed to become a reality."
Moreover the parent continues:
>It's architecture is horrible, and its catering too much to other languages.
"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.
>Once it's dead the space it frees up can be filled again by something that actually works.
Nobody stopped the parent or anyone else from using something existing "that actually works" or creating something even better.
In fact the project is already usable for a lot of us for daily exploratory coding, not to mention having put some nice ideas to the forefront of future IDE work, including having concretely inspired the Swift playground features (as the Swift designer admitted).
It's just the usual old HN piss contest.
As if it was all a scheme to make $300K off of kickstarter. I don't know where the parent lives, but for someone like Chris and with Chris' past, that's money you can make in half a year in the US software business -- not having to slave to create a whole new IDE, or hire other people to give them a chunk of the money off...
>"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.
I really don't see the advantage of trying to sell clojure and emacs as a package, it just alienates a lot of potential newcomers. Sadly almost every Clojure tutorial I've seen so far does this.
Most tutorials for other programming languages simply go with a text editor of your choice + a console repl.
Agreed, learning Emacs while learning Clojure is just a bad idea. It's a huge distraction and it ties the success of learning Clojure into the success of learning Emacs (which will never be everyone's thing) and reduces your speed while learning.
If you really want to evaluate stuff inline and get a more LISPian experience, use LightTable, not Emacs. But even then, I'd recommend against that. Use what you know.
If you look at the rest of the posts on howistart.org you'll see that each mentions in some way the authors development environment of choice. This is on purpose, howistart is meant to be opinionated and show how the author works, not attempt to be generic.
I'll second this; there's a huge amount of value to be gained by reading opinionated pieces from experienced software developers. Many times it's just inspiration in the form of "huh that's cool, I wonder how I can integrate that feature/technique into my own workflow ..." I think that's also part of the appeal of watching other programmers livestream, though unfortunately there the signal to noise ratio is so much lower there than a well written article.
Well... I may be biased as one of those folks who uses both vim and emacs, but: there is a big (positive) difference in my opinion between evaluating code in-line, right from your source file, in your editor, than copy+pasting it into a REPL somewhere. Loading up your ns in cider and then being able to evaluate functions, edit them, and see their output right in emacs is terrifically powerful. Even in SublimeText or IntelliJ or something you have to wrap the function in question in a print statement to do that, sometimes affecting lexical scope, etc.
No, you don't - in Cursive (in IntelliJ) you have always been able to send forms directly to the REPL from your editor. I think all good Clojure environments allow this.
I'm an ex-Clojurian using Haskell, and my time spent in console REPL vs. Emacs Haskell REPL is pretty evenly split.
I'm was quite grateful the terminal REPL (ghci) is better than `lein repl`. Which I use (Emacs vs. term) in what circumstance depends in part on how long I'm going to be heads down on the problem I'm working on.
Well, the series is titled "How I start" after all. It's not "How you might want to get your feet wet" -- it's "How I, that actually have used X in anger, get stuff done". That doesn't mean your point isn't valid, but I think showing off how the author actually works makes sense in this context.
Why though?
Cursive has a working debugger while Emacs doesn't.
Emacs has a lot of stuff outside the realm of Clojure, like irc mail and orgmode, but Cursive really is the more advanced Clojure environment.
Even @dnolen seems to have switched to it.
Maybe it's just my 4gigs of RAM speaking, but Cursive is sluggish and heavy. I have Emacs running in a drop down terminal, that I can hide and show fast, I can run many languages simultaneously (Python and Clojure for me), I can quickly navigate and to all sorts of things without any load time. Everything feels very effortless, thus why I'd recommend Emacs. Not to say that I am above opening up Cursive for serious refactoring or navigation. :)
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.