3 ms·

I learned to program sometime around 1988 or 89 when I was 12 and have been doing it for 28 years. I saw several of these rise and fall, and conventions have c

I learned to program sometime around 1988 or 89 when I was 12 and have been doing it for 28 years. I saw several of these rise and fall, and conventions have changed greatly even though most of us are still using C-style languages. The highest leverage I've found comes from spreadsheets and relational databases because they require little or no code to accomplish so much. So I think that declarative or 4th generation programming languages deserve an honorable mention in the "yes" category. The lowest leverage has been on the object-oriented side, especially with C++. Java is the least abstract language I've used in recent memory, due to its obsession with staying as far from functional programming as it can (closures were accomplished with anonymous objects until version 8!). There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values. So I think the "No" category needs a mention of highly imperative code and its tendency to become spaghetti. The single most damaging practice I encounter daily is the breaking of convention and the loss of programming context that we've built up in our minds over the years. So while most functional programming languages are conceptually brilliant, they stray so far from mainstream languages like Javascript that I think they complicate syntax unnecessarily. Heavy-handed patterns also urge us to segregate code into parts when the logic doesn't require it, which I often find unintuitive. Mobile development especially, with its obsession with delegation, event broadcasting, observers and nondeterministic behavior of partially uninitialized views (especially recycler view and UITableView) feels like always having to remember 10 or 20 digits when we can only comfortably manage 7. Types for the sake of types will likely expand code size and complexity by an order of magnitude when a simple compiler would have accomplished nearly as much. I have low confidence that any of these will survive the next tech bubble. I view parallelism and AI as a great uncharted sector of computer science that was stifled by Microsoft, Apple, Intel and NVIDIA. Had FPGAs or open source graphics cards taken off after the 90s, we would have a very different view of things like the Actor model (Erlang, Go, etc). So shared threads are a huge "no", but the private address spaces/streams/message passing and copy-on-write model of UNIX is a huge "yes" and we'll likely see these techniques adopted at the language level in the next decade. It would also be nice to have the numerical computing techniques from MATLAB so we can operate on matrices instead of primitives and saturate the hardware with less effort. Under these tools and conventions, AI loses much of its mystery because you realize you can always brute force a solution and evolve more elegant ones later to find a better local optimum.

k__ 9y ago
You're right with the syntax. Just look at Reason. They make OCaml more userfriendly for JavaScript devs, and FP-people are hating that the language loses all its beauty...
charlysl 9y ago
"closures were accomplished with anonymous objects until version 8!" Java has had closures through inner classes since the beginning, albeit admittedly in a verbose way. This is a quote from page 540 of "Concepts, Techniques and Models of Computer Programming": Full lexical scoping. Full lexical scoping means that the language supports procedure values with external references. This allows a class to be defined inside the scope of a procedure or another class. Both Smalltalk-80 and Java support procedure values (with some restrictions). In Java they are instances of inner classes (i.e., nested classes). They are quite verbose due to the class syntax (see the epigraph at the beginning of this section). But I think this is already enough to do high order programming, given that it effectively allows having functions as values (and hence high order functions), and support all 4 basic techniques high order programming builds upon: procedural abstraction (which relies on closures), genericity, instantiation and embedding [1]. I have to admit that I am not sure if I understand what you mean by "There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values". My (possibly wrong) interpretation is that you are referring to lazy execution, given that this technique associates a variable with a function that creates its value but whose execution is delayed until triggered when the value is actually needed. Is this correct? If it is, then explicit lazy execution can certainly be accomplished in Java, given that, as I have said before, it allows embedding procedure values in a data structure. Of course, this is not as convenient as implicit lazy execution as in Haskell with its non strict evaluation, but it achieves the main purpose of laziness all the same, which is to optimize resources by allowing consumers rather than producers to drive value creation and hence generate data structures incrementally (as they are needed) rather than eagerly (as in simpler data driven techniques): stream programming; another advantage of laziness is of course purely functional persistent data structures in some cases with good performance ([3] and [4]). "It would also be nice to have the numerical computing techniques from MATLAB" I couldn't agree more with this. For instance, if possible, for a ML project I think it's better to do as much research/experiments/development as possible in Matlab/Octave, and then translate it to Python or whatever the production language is (would love to hear opinions on this). It would be so nice if such translation could be avoided (maybe a preprocessor could automate it, but still ...). I believe that the reason is that Matlab is just a much more natural language for mathematical programming. I did the wonderful mooc [2] in Matlab, and much prefered it compared to the Python solutions I saw. [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [2] https://www.edx.org/course/learning-data-introductory-machine-caltechx-cs1156x-0 https://www.edx.org/course/learning-data-introductory-machin... [3] http://lambda-the-ultimate.org/node/2665 http://lambda-the-ultimate.org/node/2665 [4] https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

k__ 9y ago

You're right with the syntax. Just look at Reason. They make OCaml more userfriendly for JavaScript devs, and FP-people are hating that the language loses all its beauty...

charlysl 9y ago

"closures were accomplished with anonymous objects until version 8!" Java has had closures through inner classes since the beginning, albeit admittedly in a verbose way. This is a quote from page 540 of "Concepts, Techniques and Models of Computer Programming": Full lexical scoping. Full lexical scoping means that the language supports procedure values with external references. This allows a class to be defined inside the scope of a procedure or another class. Both Smalltalk-80 and Java support procedure values (with some restrictions). In Java they are instances of inner classes (i.e., nested classes). They are quite verbose due to the class syntax (see the epigraph at the beginning of this section). But I think this is already enough to do high order programming, given that it effectively allows having functions as values (and hence high order functions), and support all 4 basic techniques high order programming builds upon: procedural abstraction (which relies on closures), genericity, instantiation and embedding [1]. I have to admit that I am not sure if I understand what you mean by "There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values". My (possibly wrong) interpretation is that you are referring to lazy execution, given that this technique associates a variable with a function that creates its value but whose execution is delayed until triggered when the value is actually needed. Is this correct? If it is, then explicit lazy execution can certainly be accomplished in Java, given that, as I have said before, it allows embedding procedure values in a data structure. Of course, this is not as convenient as implicit lazy execution as in Haskell with its non strict evaluation, but it achieves the main purpose of laziness all the same, which is to optimize resources by allowing consumers rather than producers to drive value creation and hence generate data structures incrementally (as they are needed) rather than eagerly (as in simpler data driven techniques): stream programming; another advantage of laziness is of course purely functional persistent data structures in some cases with good performance ([3] and [4]). "It would also be nice to have the numerical computing techniques from MATLAB" I couldn't agree more with this. For instance, if possible, for a ML project I think it's better to do as much research/experiments/development as possible in Matlab/Octave, and then translate it to Python or whatever the production language is (would love to hear opinions on this). It would be so nice if such translation could be avoided (maybe a preprocessor could automate it, but still ...). I believe that the reason is that Matlab is just a much more natural language for mathematical programming. I did the wonderful mooc [2] in Matlab, and much prefered it compared to the Python solutions I saw. [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [2] https://www.edx.org/course/learning-data-introductory-machine-caltechx-cs1156x-0 https://www.edx.org/course/learning-data-introductory-machin... [3] http://lambda-the-ultimate.org/node/2665 http://lambda-the-ultimate.org/node/2665 [4] https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf