5 ms·

This reminds me of regex, and the struggle 2 months later to remember wtf I was trying to do there. Easy to write, hard to maintain, so thank you but no thank y

This reminds me of regex, and the struggle 2 months later to remember wtf I was trying to do there. Easy to write, hard to maintain, so thank you but no thank you, I prefer the loops instead even if it means going down at individual elements in a list/matrix. For any meaningful project maintenance is the threshold that will make it or break it.

Felk 7y ago
There are cases where I very much prefer a declarative style. Multiplying matrices for example. Depending on the context, I will know what it does conceptually, but don't want to see the implementation, as it probably won't matter. My rule of thumb is: are you doing something unexpected ? show the implementation : show the concept
- krferriter 7y ago
  How often do you actually write out matrix multiplication in the main code flow? Generally you extract that into a function and just call it like `matrix_multiply(A, B)`, which in language which supports operator overloading could be attached behind the expression `A * B`. It's not that loops aren't happening, but the loops are just wrapped up in another expression that is more semantically meaningful, which is a good practice in general.
noobermin 7y ago
It really depends on the situation. For regex, certain things are much more understandable than a long set of loops for it, as long as the regex isn't too complicated. Ditto for implicit for-loops for addition in say numpy or fortran 90. I've seen scientific codes in C that have like 5 to 6 order nested loops that end up being thousand+ of lines, after which the length requires much much more time reinternalizing after coming back months later, or worse, as someone who didn't write it, all due to the fact that the whole damn thing can't fit on a single page of emacs and be still legible.
coldtea 7y ago
>I prefer the loops instead even if it means going down at individual elements in a list/matrix. Actually you have it backwards, probably because you confused J's somewhat cryptic notation as the only way to implement the same concept. It's the for loops, with their sprawl of non-declarative code, that would be equivalent to the regex opaqueness, and a well named operator or function to achieve the same thing that would be more like J. E.g. would you rather use a: sort(myList, order=desc) or write your own sorting with for loops? Similarly, think of operations like: findElement(myList, predicate) filterElements(myList, predicate) keepElements(myList, predicate) forEach(myList, myFunc) forEachParallel(myList, myFunc, chunks=5) In other words, reduce, map, and specialized versions of them. If 10-20 such language provided functions covered all cases, I'd use them over for loops all the time. In fact that's how people use e.g. lodash. What J adds is a succinct syntax to write and compose such primitives at the language level. But such a syntax is not necessary to achieve the same concept (although not the same brevity/expressiveness) and be better/more readable than for loops... P.S And regexes themselves should be compared to the equivalent parsing code -- which could require a FSM, or an ad-hoc buggy implementation of the same checks/captures spanning 10s or 100s of lines depending on the regex. Except if you just use a regex for very simple things where e.g. a "contains" function or some splitting etc will be simpler.
- tluyben2 7y ago
  I have a substantial library with those functions for C#. Why not use Linq? Because I see people struggle with it (usually external clients who license our code and outsource development); when they do, they resort to loops. So I wrote these simpler functions which are implemented mostly with Linq but they keep people who do not understand linq (again, yes, they are there and rather a lot of them) from messing up the codebase. Advantage is that these functions translate to any other language, while Linq doesn’t, so we have the same (partially implemented) semantics for the same things over a few languages we use.

Felk 7y ago

There are cases where I very much prefer a declarative style. Multiplying matrices for example. Depending on the context, I will know what it does conceptually, but don't want to see the implementation, as it probably won't matter. My rule of thumb is: are you doing something unexpected ? show the implementation : show the concept

krferriter 7y ago
How often do you actually write out matrix multiplication in the main code flow? Generally you extract that into a function and just call it like `matrix_multiply(A, B)`, which in language which supports operator overloading could be attached behind the expression `A * B`. It's not that loops aren't happening, but the loops are just wrapped up in another expression that is more semantically meaningful, which is a good practice in general.

noobermin 7y ago

It really depends on the situation. For regex, certain things are much more understandable than a long set of loops for it, as long as the regex isn't too complicated. Ditto for implicit for-loops for addition in say numpy or fortran 90. I've seen scientific codes in C that have like 5 to 6 order nested loops that end up being thousand+ of lines, after which the length requires much much more time reinternalizing after coming back months later, or worse, as someone who didn't write it, all due to the fact that the whole damn thing can't fit on a single page of emacs and be still legible.

coldtea 7y ago

>I prefer the loops instead even if it means going down at individual elements in a list/matrix. Actually you have it backwards, probably because you confused J's somewhat cryptic notation as the only way to implement the same concept. It's the for loops, with their sprawl of non-declarative code, that would be equivalent to the regex opaqueness, and a well named operator or function to achieve the same thing that would be more like J. E.g. would you rather use a: sort(myList, order=desc) or write your own sorting with for loops? Similarly, think of operations like: findElement(myList, predicate) filterElements(myList, predicate) keepElements(myList, predicate) forEach(myList, myFunc) forEachParallel(myList, myFunc, chunks=5) In other words, reduce, map, and specialized versions of them. If 10-20 such language provided functions covered all cases, I'd use them over for loops all the time. In fact that's how people use e.g. lodash. What J adds is a succinct syntax to write and compose such primitives at the language level. But such a syntax is not necessary to achieve the same concept (although not the same brevity/expressiveness) and be better/more readable than for loops... P.S And regexes themselves should be compared to the equivalent parsing code -- which could require a FSM, or an ad-hoc buggy implementation of the same checks/captures spanning 10s or 100s of lines depending on the regex. Except if you just use a regex for very simple things where e.g. a "contains" function or some splitting etc will be simpler.

tluyben2 7y ago
I have a substantial library with those functions for C#. Why not use Linq? Because I see people struggle with it (usually external clients who license our code and outsource development); when they do, they resort to loops. So I wrote these simpler functions which are implemented mostly with Linq but they keep people who do not understand linq (again, yes, they are there and rather a lot of them) from messing up the codebase. Advantage is that these functions translate to any other language, while Linq doesn’t, so we have the same (partially implemented) semantics for the same things over a few languages we use.