3 ms·

It's the same reason to learn alternatives to anything: to have a wider breadth of knowledge. Your thought process becomes more open and can better way alternat

by jjice 4y ago

It's the same reason to learn alternatives to anything: to have a wider breadth of knowledge. Your thought process becomes more open and can better way alternatives because you actually have alternatives. My compiler course in college was in SML and it was excellent for teaching more more than just compilers. It taught me a lot about recursion and the idea of composing a problem in terms of itself, which has been incredibly powerful in my career. Being exposed to other great concepts like algebraic data types (sum types/Rust's enums) just helps expand my way of thinking when I write PHP code at work. The idea of using a function as a fundamental building block for abstracting ideas has also been fantastic. Mostly in the form of using functions as arguments to alter behavior. As with everything, there's a balance. I don't write pure FP, nor do I want to, but the ideas are huge. Same with OOP. OOP has some good ideas, but I don't lean on the words of the GOF as if they were GOD. Pulling in the best of all worlds has been really huge for my life as an engineer.

Banana699 4y ago
Dijkstra once explained how his process for writing code is to state\solve the problem in the most obvious and natural language possible. If a compiler\interpreter existed for that language, then he's done, he now has an executable solution to the problem. If not, then he recursively solves the problem of translating each construct of this non-executable-but-convenient language down into other constructs, if those constructs are executable, well and good, if not, he has to break them down further. Learning new programming languages, paradigms, architectures, approaches and formalisms aids this process because it gives you more mental building blocks to use in your journey from non-executable specifications to executable implementations. Even if you never write haskell, learning it makes your brain evolve a haskell-like pseudocode in which to think and express problems, and this can come in handy when the problem is most naturally expressed in haskell. If a haskell implementation exist, great, if not, transform the haskell formulation gradually into whatever executable form available. This, for a certain class of problems - let us rather unimaginatively call them 'haskell problems' -, is better and more enlightening than attempting to directly solve them in executable format. ------ One common saying is "You Can Write Fortran In Any Language", another one is "Any Sufficiently Complicated C Program Contains An Ad-hoc Informal Implementation Of Common Lisp". The fundamental truth that both of those aphorisms hint at is that programmers are human compilers, the programming language they write in is their target language, the "assembly", and the description of of the problem they are solving is the source language they are compiling. Here's the thing though : just like actual compilers, programmers don't have to compile the source language all in one go. Machine compilers often go through several detours and meander through different intermediate representation of the code being translated before outputting the final target. The equivalent of this for programmers is the Dijkstra process, describe your problems in a hierarchy of languages that ends, not begins, with the programming language you happen to use. If the problem is best described as a Fortran program, write it (in your head) as a Fortran program then implement whatever necessary of Fortran in the actual available language to write the program. If the problem is best described as Common Lisp program, then think about it in your head as a Common Lisp program then implement the necessary parts of Common Lisp in C to write the program (The full quote is only saying this is bad insofar as it happens non-deliberately and haphazardly, if it's deliberate then it's just good design). Programming Languages are notations/pseudocode/ways of thought/mental models/semantic repositories of meaning, they can be useful even if there is not a single executable implementation of them in sight.
- dial9-1 4y ago
  every program is a compiler
- kazinator 4y ago
  > If a compiler\interpreter existed for that language ... Then Dijkstra would have written a disparaging article about it, and then worked the solution in Algol 60.

by jjice 4y ago

Banana699 4y ago

Dijkstra once explained how his process for writing code is to state\solve the problem in the most obvious and natural language possible. If a compiler\interpreter existed for that language, then he's done, he now has an executable solution to the problem. If not, then he recursively solves the problem of translating each construct of this non-executable-but-convenient language down into other constructs, if those constructs are executable, well and good, if not, he has to break them down further. Learning new programming languages, paradigms, architectures, approaches and formalisms aids this process because it gives you more mental building blocks to use in your journey from non-executable specifications to executable implementations. Even if you never write haskell, learning it makes your brain evolve a haskell-like pseudocode in which to think and express problems, and this can come in handy when the problem is most naturally expressed in haskell. If a haskell implementation exist, great, if not, transform the haskell formulation gradually into whatever executable form available. This, for a certain class of problems - let us rather unimaginatively call them 'haskell problems' -, is better and more enlightening than attempting to directly solve them in executable format. ------ One common saying is "You Can Write Fortran In Any Language", another one is "Any Sufficiently Complicated C Program Contains An Ad-hoc Informal Implementation Of Common Lisp". The fundamental truth that both of those aphorisms hint at is that programmers are human compilers, the programming language they write in is their target language, the "assembly", and the description of of the problem they are solving is the source language they are compiling. Here's the thing though : just like actual compilers, programmers don't have to compile the source language all in one go. Machine compilers often go through several detours and meander through different intermediate representation of the code being translated before outputting the final target. The equivalent of this for programmers is the Dijkstra process, describe your problems in a hierarchy of languages that ends, not begins, with the programming language you happen to use. If the problem is best described as a Fortran program, write it (in your head) as a Fortran program then implement whatever necessary of Fortran in the actual available language to write the program. If the problem is best described as Common Lisp program, then think about it in your head as a Common Lisp program then implement the necessary parts of Common Lisp in C to write the program (The full quote is only saying this is bad insofar as it happens non-deliberately and haphazardly, if it's deliberate then it's just good design). Programming Languages are notations/pseudocode/ways of thought/mental models/semantic repositories of meaning, they can be useful even if there is not a single executable implementation of them in sight.

dial9-1 4y ago
every program is a compiler
kazinator 4y ago
> If a compiler\interpreter existed for that language ... Then Dijkstra would have written a disparaging article about it, and then worked the solution in Algol 60.