HN user

ticking

48 karma
Posts0
Comments30
View on HN
No posts found.

The method they accidentally found is not as bad as you make it to be.

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.

The fie is huge because it seems that animations were converted to multiple PDF pages.

So page count is not a useful metric for presentation progression and information amount.

It never said it was the "the uber clojure IDE", not even used any words to this effect.

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

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.

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.

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.

I agree 100% with you. Rigidity is something you don't want, but this is something entirely different.

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.

Just do

  public foo(Bar bar) {
        bar = baz(bar);
        //Lots (10+ lines) of code
        return finishProcess(bar);  //Note, this should have been updatedBar.
  }
nothing prevents you from reusing the variable name. The point about immutability is that the objects themselves don't change.

The current serialisation code needs to die, and be replaced with something usable and already existing, e.g. zeromq + msgpack.

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

English is the best candidate because it has the second largest user base (1.2 Billion vs 1.3 Billion for Mandarin), http://en.wikipedia.org/wiki/List_of_languages_by_total_numb... and is twice as spoken as the third most popular language Spanish. (0.55 Billion)

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.

Unicode is notoriously tricky to implement, there have been bugs where users could take over others accounts by choosing a different unicode representation of the same string.

I'd much rather have something that works and is simple. Than something that makes it easy for everybody and is broken.

Even though I'm not a native english speaker and couldn't write my name in ASCI, I really despise Unicode.

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.

I loved the Makezine weekend projects with Bre Pettis (the guy in the video).

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.

TL;DR The only problem is that ISPs love to oversell their capacities. And important services don't need that much bandwidth. NN has nothing to do with this.

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)

I find false accusations, which in this case even lead to the accused loosing their jobs a serious hardship. Consider our societies view of men that are nice to children, most immediately think "pedophile", instead of nice guy. Just because we have to fight for true freedom of women, doesn't mean we shouldn't fight for the same when it comes to men. We need more men in social jobs, and we need a mens right movement to foster this, just as we need more women in IT. The real thing we need though is a unified movement that fights against discrimination of any kind without a label of a particular gender, race, religion or ideology.

There is a ton of Languages for erlangs BEAM,

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.