Hacker News Reader

Comment by caseymarquis | Hacker News Reader

I think working on a large project in c89 made me better at writing in other languages.

When you strip all your useful tools and concepts away, you're forced to rethink how you can organize with just data types and functions. Surprisingly, you can do pretty well with just these.

It's the sort of thing that helps with recognizing when you're looking at FizzBuzz and when you actually need to use a generic factory.

View on HN

When I started working with PHP over a decade ago I had some experience with Java so I thought it was funny that in PHP everything is an 'array'. Now that I'm working with JS and Elixir and getting into functional programming I'm realizing, that hey, maybe that is the right way to go. Putting everything into structures like maps helps blur the line between code and data.

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.

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?

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

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

Reply on news.ycombinator.com