Hacker News Reader

Comment by cygned | Hacker News Reader

I have quite some background in OOP and switched to functional programming a few years ago, now working a lot with Clojure, where you actually have the "code is data" paradigm. And from my experience, it's way easier to model data with three simple structures; vectors (= arrays), maps and sets. There are other things, too, but most of the time these three types are sufficient. It requires some discipline in the beginning but it can give you a lot of benefits.

View on HN

Just to reinforce this, the same is essentially true of all the languages I have touched. If the language has associative arrays ( e.g. maps ) all the better. But associativity is not difficult even in assembly language - so long as O(n) lookups are okay. Adding basic better-than-linear searches ( O(log(n)) ) is also not horribly complex - the 'C' library bsearch() is a conceptual template here.

Having large arrays of const data to drive 'C' programs can - emphasis can - lead to much more manageable 'C' code.

why quote C? I read about Forth people doing that, is that it?

You are going to be lectured at length by the (OOP) static types crowd. And they have a point about using explicit types, when it's easy.

That said, I wish the "strong types" crowd would take a look at all of the temporal coupling that their OOP designs are causing, with their update-at-will practices. Now that we have working garbage collector software plus adequate hardware support, why not make use of that?

FP needs to become a more widely used practice.

Languages like PreScheme compile to C with no GC. You manage memory manually. So there's those kind of systems too.

Some of the largest "strong types" advocates are FP folks

Some are, some aren't :-)

Some are just lost if autocomplete in the IDE doesn't enter stuff for them, and the more verbosely the IDE spews, the better, cuz it looks like "work".

I think, a "Data Driven Development" approach would make a lot of implementations easier.

Something as described in this talk: https://youtube.com/watch?v=Tb823aqgX_0

> And from my experience, it's way easier to model data with three simple structures; vectors (= arrays), maps and sets.

So, Lua tables? ;)

Unfortunately, Lua violates Commandment Zero:

Thou shalt not index from one.

That may be fixable at compile time, I believe. In the worst case, you could write a patch. (Dijkstra would prefer a half-open indexing scheme anyway.)

And be incompatible with the universe of Lua programs.

The problem was that Lua reified 1-indexing into the language when they optimized to make arrays faster and then created length operators. At that point, 1-indexing got baked into the language.

Reply on news.ycombinator.com