3 ms·

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

by cygned 10y ago

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.

ArkyBeagle 10y ago
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.
- uryga 10y ago
  why quote C? I read about Forth people doing that, is that it?
jakub_h 10y ago
> And from my experience, it's way easier to model data with three simple structures; vectors (= arrays), maps and sets. So, Lua tables? ;)
- bsder 10y ago
  Unfortunately, Lua violates Commandment Zero: Thou shalt not index from one. :)
  - jakub_h 10y ago
    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.)
    - bsder 10y ago
      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.
Roboprog 10y ago
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.
- nickpsecurity 10y ago
  Languages like PreScheme compile to C with no GC. You manage memory manually. So there's those kind of systems too.
- jghn 10y ago
  Some of the largest "strong types" advocates are FP folks
  - Roboprog 10y ago
    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".
- cygned 10y ago
  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 https://youtube.com/watch?v=Tb823aqgX_0

by cygned 10y ago

ArkyBeagle 10y ago

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.

uryga 10y ago
why quote C? I read about Forth people doing that, is that it?

jakub_h 10y ago

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

bsder 10y ago
Unfortunately, Lua violates Commandment Zero: Thou shalt not index from one. :)
- jakub_h 10y ago
  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.)
  - bsder 10y ago
    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.

Roboprog 10y ago

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.

nickpsecurity 10y ago
Languages like PreScheme compile to C with no GC. You manage memory manually. So there's those kind of systems too.
jghn 10y ago
Some of the largest "strong types" advocates are FP folks
- Roboprog 10y ago
  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".
cygned 10y ago
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 https://youtube.com/watch?v=Tb823aqgX_0