141–150 of 154 posts
Earlier quoted context omitted.
And it's probably one of the most significant things limiting adoption of Haskell.
Exactly. From my point of view, Haskell is the perfect language which unfortunately comes with the worst naming conventions. (I generally develop in C#, F# and JavaScript)
Earlier quoted context omitted.
I think you are right, and it is a convention in the functional world. People are using (and worse, reusing in a close proximity!) meaningless names like that. And I think these people have zero regard to anyone who is reading their code. Well... more power to python, and culture that embraces 'what your see is what your get' and super-readable code.
We'll have to agree to disagree. I think long variable names for short-lived variables decreases readability. Oftentimes these "points" are just used to glue functional pipelines together and have little-to-no intrinsic meaning. The true documentation comes from the types and is thus more trustworthy.
In C or C++ this newer was the case, because type information was never implied (until recently, when auto was introduced). And in dynamic languages, like Python, this is also almost never the case, because good mainstream developers use object names consistently.
In the functional world however, mainstream (if there is any mainstream, as I often see each developer working in his/her own unique style) folks just say phrases like 'true documentation comes from the types' and write their recursions freely, and with no regard to the reader.
So yes. We'll have to agree to disagree.
Earlier quoted context omitted.
> There still isn't a canonical Promises specification. Yes, there is: https://github.com/promises-aplus/promises-spec
Promises/A+ surfaced less than 6 months ago, and is not implemented by most widely-used frameworks. Still a bit far from canonical.
All the code and such a big abstraction for the first example when it could have done like this: var result = []; paths.forEach(function (i, file){ fs.stat(file, function (err, data){ result.push(data); if (i === 0) { // Use stat size } if (result.length === paths.length) { // Use the stats } }); }); Fairly understandable, more efficient and without introducing logic patterns foreign to many. It also meet his require…
Why don't we all just go back to manually pushing/popping arguments on the stack like in assembly language while we're at it?
Earlier quoted context omitted.
There is actually an interesting technical reason for having short names in generic Haskell functions. Because of parametricity, the behavior of the function doesn't depend on what the values actually are. The shortness of the names really is meant to convey "don't think about what this is doing, because it's not important for this function". In the traditional example for map, map f [] = [] map f (x:xs) = f x : map…
I'm not so sure that briefness and adherence to that convention improves readability. Of course f, x, xs is much much better than 'first' and 'rest', or 'a', 'b', 'c', but something like 'func' and 'iterable' gives more context. And frees one's attention to more important things, than looking up and down the code. Compare: map f [] = [] map f (x:xs) = f x : map f xs With: map f xs = [f x | x Or even better, in Python…
map f xs = [f x | x I find the python version hardest to read (even though it's also "cheating"), which is largely because both the identifiers and the control constructs are alphabetic.
[func(x) for x in iterable]
[call func x for x in iterable]
[f x | x The only other thing is that because "iterable" is such a long word I expect it to be an identifier imported from a library or somewhere else in the program, and certainly not earlier in the line.
In summary, I think a lot of what we find "readable" depends on what we are used to.
Earlier quoted context omitted.
That's kind of false advertisement. Excel (or spreadsheet in general) is great and easy to use because of declarative programming, not because of functional programming. The functional programming aspect of it is minimal. No variables, no state, and no side-effects are mainly attribute of declarative programming. The most important aspect of being functional, high order function, is completely missing.
Even "no variables" and "no state" are arguably untrue. The state of a spreadsheet consists of the values sitting in its cells. You mutate them by editing them. One FP attribute that spreadsheets do have is referential transparency: the same inputs given to the same formula will always produce the same result.
let x = 3, y = 5 in
x + y
Earlier quoted context omitted.
Even "no variables" and "no state" are arguably untrue. The state of a spreadsheet consists of the values sitting in its cells. You mutate them by editing them. One FP attribute that spreadsheets do have is referential transparency: the same inputs given to the same formula will always produce the same result.
But it only recomputes them when you edit them. It's like changing the source code of the program and rerunning it. let x = 3, y = 5 in x + y No (mutable) variables there, but if I change the y = 3 bit to y = 4, the value of the expression changes. That's what it's like in excel, as well.
You're right, of course. But it depends on how you draw the boundaries of the system. If you think of the numbers in your example as code, then the program is stateless, and each time you change a number you get a new program. But if you think of them as parameters that live outside the code, then the edit-recompute cycle is a state change. In a similar if trivial way, if you take (say) a Java program running over a database and decide that the data in the database is "code", that "program" (consisting of Java code plus database) is now "stateless" too, and anyone who updates a database record is changing the "program".
Given that "stateful" vs. "stateless" depends on how you draw the boundaries of the system, the question is how best to draw the boundaries of a spreadsheet. I'm not arguing there's a single correct way to do that, but in my view the user's mental model of a spreadsheet is closer to "a calculating machine with state that I can update" than it is to "a stateless calculating machine with a lot of hard-coded literals".
Psychologically, updating the numbers in a spreadsheet doesn't feel like editing the source code of a program and re-running it. It feels stateful, like mutating something that triggers a cascade of side effects (recalculation). For this reason I think that spreadsheets are closer to the Smalltalk vision of a world of objects that respond to user interaction (as well as to each other) than they are to the functional programming vision of pure code. Put differently, the spreadsheet's I/O, its grid UI, is part of its essence. You can't abstract away from that without losing the heart of the thing. So the analogy with functional programming, though tempting, leads in the wrong direction. Every individual formula that lives in a cell is certainly a functional program when taken in isolation—but the memory model by which the cells reference one another and get updated is stateful.
Earlier quoted context omitted.
I'm not so sure that briefness and adherence to that convention improves readability. Of course f, x, xs is much much better than 'first' and 'rest', or 'a', 'b', 'c', but something like 'func' and 'iterable' gives more context. And frees one's attention to more important things, than looking up and down the code. Compare: map f [] = [] map f (x:xs) = f x : map f xs With: map f xs = [f x | x Or even better, in Python…
I find map f xs = [f x | x the most readable, but given that list comprehension is basically a map and a filter joined together, that definition is kind of cheating. I find the python version hardest to read (even though it's also "cheating"), which is largely because both the identifiers and the control constructs are alphabetic. [func(x) for x in iterable] I have to read the words to figure out that for/in are the…
I think a general rule is that source code readability is inverse to the amount of context information that one needs to remember in order to interpret and understand the code.
If you can look at the code at any place (and at any scale, ranging from a single line to the whole call graph), and without any context understand what is happening at this particular place - code is readable. And on the opposite, if you need to know a lot about the context of each particular line of code - code is unreadable.
Earlier quoted context omitted.
Exactly. From my point of view, Haskell is the perfect language which unfortunately comes with the worst naming conventions. (I generally develop in C#, F# and JavaScript)
The naming conventions are fine, but they're very different from C#, F# or JS - it's basically the difference between reading English text and reading formulas (i.e. compositions of weird letters and symbols).
Earlier quoted context omitted.
Excel is not functional. It is declarative. Alan Kay (yes, that Alan Kay[1] -- the guy that's won a Turing award) formalized spreadsheets as a limited form of first-order functional programming.[0] [0] http://en.wikipedia.org/wiki/Spreadsheet#Values [1] http://en.wikipedia.org/wiki/Alan_Kay
I'm afraid you've misunderstood that Wikipedia page. It attributes the phrase "first-order functional programming" to authors other than Kay. All it attributes to Kay is the phrase "value rule". Kay's interest in spreadsheets wasn't about functional programming, it was about interactive and dynamic computation. I have a pdf of the 1984 Scientific American article that Wikipedia is quoting from. It does include the ph…
I guess we'll agree to disagree, I don't think someone needs to use the phrase "first-order functional programming" when they give the very definition of it, which is what Wikipedia does: summarize Kay's argument.
I do agree the article itself was quite interesting, and certainly ahead of its time.