4 ms·

The big mistake is in believing there is any value in this- or that-oriented programming, or in a this- or that-oriented language. An engineer uses what is ava

by ncmncm 4y ago

The big mistake is in believing there is any value in this- or that-oriented programming, or in a this- or that-oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every big-enough problem decomposes into a collection of very different subproblems, each of which so decomposes further. The right approach for the top level rarely matches that for most of its parts, nor each for the others, and likewise down the line. Unless you want to use a different language for each level and subproblem, you will want support for all "orientations" in your language. Thus, a "functional" or "OO" language is an absurdity; likewise, a "functional", "OO", or what-have-you program. They make as much sense as a saw-oriented carpenter's toolbox or table, or a screwdriver-oriented machinist's toolkit or engine. Programs should be like water, fluidly matching the shape of the problem solved. If that is 20% functional, 10% O-O, and the rest imperative, so be it. Specialization is for insects. Everything is Turing complete: you can code a solution in any restricted vocabulary. But that means succeeding proves nothing and benefits nobody, but wasted your time and others'. Use a language that does it all, and use it all. Not necessarily all on every program; but all styles get consideration for each part.

lvass 4y ago
"Subproblem" is likely an exaggeration here, otherwise I vehemently disagree. Take Erlang for example, it's theoretically a general purpose language but highly specialized. Would WhatsApp reach a billion users with 50 engineers without this specialization? I doubt it. It's absolutely fine for things to be heavily specialized, as it is fine for our entire civilization to rely division of labor. As the number of developers increase, so should the number of specializations. While a non-turing-complete language doesn't make much sense, web servers, linear algebra and GUIs for example are sufficiently different so that using the same language is unwise.
- ncmncm 4y ago
  There are very successful insects.
  - lvass 4y ago
    No creature is limited to the use of a single programming language, but a lot of programs are. You can learn more than one language and choose one that is appropriate for the task, unlike an insect whose tools are limited so he must have only a few to do everything it needs to. Multi-paradigm is the insectisation here.
    - ncmncm 4y ago
      From the original post: > The right approach for the top level rarely matches that for most of its parts, nor each for the others, and likewise down the line. Unless you want to use a different language for each level and subproblem, you will want support for all "orientations" in your language. It is grossly impractical to use a different language for each fragmentary part of a problem. People do not, as a rule, do that. Trivial exceptions include Python and niche-language programs calling out to C-ABI libraries, programs sending SQL to databases, and web servers sending Javascript to browsers. But those are not about "orientation". You might use two or more different general-purpose languages for different, independent problems, but that does not contradict my remark about the folly of languages that attempt "purity".
AlchemistCamp 4y ago
I completely disagree with the kitchen sink language approach. The benefits in many coding paradigms really kick in once they're used 100%. For example, consider GOTOs. If 99% of your functions don't use any GOTOs but they other 1% does, you can't be sure how the flow of logic lead to any one function. Immutability works in a similar way. I have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily.
- yowlingcat 4y ago
  > have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily. How much of that comes from belief rather than reality, and potentially some room to grow on your end? I can debug well written code in any language I jump into, but I've found poorly written and hard to debug morasses can be written in any language. Poor naming, branch/loop structuring, scoping, data modeling/normalization, module structuring, logging, and dependency selection/integration have all contributed to debugging hassles far more in my production experience than any particular language.
  - AlchemistCamp 4y ago
    > How much of that comes from a belief rather than reality, and potentially some room to grow on your end? You know… suggesting that someone that they’re delusional and uninformed isn’t a very charitable way to discuss anything online. The belief came from personal experience from 2016-2018 while I was much more experienced with JS/TS and relatively new to Elxir. It definitely influenced me to keep exploring and learning things outside the JS ecosystem I’d previously focused on. I’ve grown as a dev since and so has my appreciation of guaranteed immutability. Also working with other languages, particularly Rust, in the past few years has only further underlined the point. It makes a strict delineation between variables, references and arguments that can be mutated and those that can’t. The language went with 100% guarantees instead of 95% guarantees for a good reason. > I can debug well written code in any language I jump into The phrase “well-written” may be doing a lot of lifting here. Different languages and ecosystems make different practices easy and tend to nudge users in different directions. People who don’t like learning often enjoy the idea that any Turing complete language is equivalent from the programmer’s perspective but it’s just not true.
danielscrubs 4y ago
“Everything is Turing complete” isn’t true. You can get quite interesting languages by making sure it isn’t. See strong functional programming for examples. https://en.m.wikipedia.org/wiki/Total_functional_programming https://en.m.wikipedia.org/wiki/Total_functional_programming
- ncmncm 4y ago
  That you can code certain solutions in a non-Turing-complete language is of identically null benefit.
  - tadfisher 4y ago
    Aside from being able to prove that the solution halts, you mean? You get a lot of side benefits as well with a halting program, such as provable limits in time and space for the totality of the program instead of just the functional core bits.
    - ncmncm 4y ago
      Maybe you are unable to prove properties of programs you have coded in Turing-complete languages. Many of us do, though. Routinely. Quick, does this program terminate: int main() {} ? Can't prove it?
      - tadfisher 4y ago
        That's not a very useful program.
        ncmncm 4y ago
        It is the first stage of every useful program. Add to it, and show that it still terminates, uses finite memory, introduces no data races or undefined behavior, and maybe computes a step toward something useful. Repeat until done.
pjmlp 4y ago
I like very much how Wirth puts it, Programs = Algorithms + Data Structures. Everything else is syntactic sugar.
- ncmncm 4y ago
  If that were true, the past 30 years of progress in programming languages would be meaningless. But it is not: a more powerful language enables expressing what a weaker language does not. A language meant for use by professionals should get powerful features, without regard to any spurious notions of "purity".
  - pjmlp 4y ago
    Understanding what that equation means in practice is the difference between having a degree and a six month bootcamp as X Developer.
    - ncmncm 4y ago
      Do you really think you want to go there?
      - pjmlp 4y ago
        I have a thick skin.
        ncmncm 4y ago
        That is not the thickness we are concerned with, here. :)
benrbray 4y ago
Can you give any examples of useful non-terminating programs? It seems to me all useful programs are terminating (or, we truncate some non-terminating procedure by some convergence criteria). The question is only whether we have the logical tools to prove termination at compile time.
- ncmncm 4y ago
  Programs running in microcontrollers routinely do not terminate; they run as long as there is power. Even many ordinary programs run until they are killed. You seem to confuse algorithms, which by definition must terminate, with programs, which do whatever the hell you like (and sometimes things you don't).

by ncmncm 4y ago

lvass 4y ago

"Subproblem" is likely an exaggeration here, otherwise I vehemently disagree. Take Erlang for example, it's theoretically a general purpose language but highly specialized. Would WhatsApp reach a billion users with 50 engineers without this specialization? I doubt it. It's absolutely fine for things to be heavily specialized, as it is fine for our entire civilization to rely division of labor. As the number of developers increase, so should the number of specializations. While a non-turing-complete language doesn't make much sense, web servers, linear algebra and GUIs for example are sufficiently different so that using the same language is unwise.

ncmncm 4y ago
There are very successful insects.
- lvass 4y ago
  No creature is limited to the use of a single programming language, but a lot of programs are. You can learn more than one language and choose one that is appropriate for the task, unlike an insect whose tools are limited so he must have only a few to do everything it needs to. Multi-paradigm is the insectisation here.
  - ncmncm 4y ago
    From the original post: > The right approach for the top level rarely matches that for most of its parts, nor each for the others, and likewise down the line. Unless you want to use a different language for each level and subproblem, you will want support for all "orientations" in your language. It is grossly impractical to use a different language for each fragmentary part of a problem. People do not, as a rule, do that. Trivial exceptions include Python and niche-language programs calling out to C-ABI libraries, programs sending SQL to databases, and web servers sending Javascript to browsers. But those are not about "orientation". You might use two or more different general-purpose languages for different, independent problems, but that does not contradict my remark about the folly of languages that attempt "purity".

AlchemistCamp 4y ago

I completely disagree with the kitchen sink language approach. The benefits in many coding paradigms really kick in once they're used 100%. For example, consider GOTOs. If 99% of your functions don't use any GOTOs but they other 1% does, you can't be sure how the flow of logic lead to any one function. Immutability works in a similar way. I have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily.

yowlingcat 4y ago
> have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily. How much of that comes from belief rather than reality, and potentially some room to grow on your end? I can debug well written code in any language I jump into, but I've found poorly written and hard to debug morasses can be written in any language. Poor naming, branch/loop structuring, scoping, data modeling/normalization, module structuring, logging, and dependency selection/integration have all contributed to debugging hassles far more in my production experience than any particular language.
- AlchemistCamp 4y ago
  > How much of that comes from a belief rather than reality, and potentially some room to grow on your end? You know… suggesting that someone that they’re delusional and uninformed isn’t a very charitable way to discuss anything online. The belief came from personal experience from 2016-2018 while I was much more experienced with JS/TS and relatively new to Elxir. It definitely influenced me to keep exploring and learning things outside the JS ecosystem I’d previously focused on. I’ve grown as a dev since and so has my appreciation of guaranteed immutability. Also working with other languages, particularly Rust, in the past few years has only further underlined the point. It makes a strict delineation between variables, references and arguments that can be mutated and those that can’t. The language went with 100% guarantees instead of 95% guarantees for a good reason. > I can debug well written code in any language I jump into The phrase “well-written” may be doing a lot of lifting here. Different languages and ecosystems make different practices easy and tend to nudge users in different directions. People who don’t like learning often enjoy the idea that any Turing complete language is equivalent from the programmer’s perspective but it’s just not true.

danielscrubs 4y ago

“Everything is Turing complete” isn’t true. You can get quite interesting languages by making sure it isn’t. See strong functional programming for examples. https://en.m.wikipedia.org/wiki/Total_functional_programming https://en.m.wikipedia.org/wiki/Total_functional_programming

ncmncm 4y ago
That you can code certain solutions in a non-Turing-complete language is of identically null benefit.
- tadfisher 4y ago
  Aside from being able to prove that the solution halts, you mean? You get a lot of side benefits as well with a halting program, such as provable limits in time and space for the totality of the program instead of just the functional core bits.
  - ncmncm 4y ago
    Maybe you are unable to prove properties of programs you have coded in Turing-complete languages. Many of us do, though. Routinely. Quick, does this program terminate: int main() {} ? Can't prove it?
    - tadfisher 4y ago
      That's not a very useful program.
      - ncmncm 4y ago
        It is the first stage of every useful program. Add to it, and show that it still terminates, uses finite memory, introduces no data races or undefined behavior, and maybe computes a step toward something useful. Repeat until done.

pjmlp 4y ago

I like very much how Wirth puts it, Programs = Algorithms + Data Structures. Everything else is syntactic sugar.

ncmncm 4y ago
If that were true, the past 30 years of progress in programming languages would be meaningless. But it is not: a more powerful language enables expressing what a weaker language does not. A language meant for use by professionals should get powerful features, without regard to any spurious notions of "purity".
- pjmlp 4y ago
  Understanding what that equation means in practice is the difference between having a degree and a six month bootcamp as X Developer.
  - ncmncm 4y ago
    Do you really think you want to go there?
    - pjmlp 4y ago
      I have a thick skin.
      - ncmncm 4y ago
        That is not the thickness we are concerned with, here. :)

benrbray 4y ago

Can you give any examples of useful non-terminating programs? It seems to me all useful programs are terminating (or, we truncate some non-terminating procedure by some convergence criteria). The question is only whether we have the logical tools to prove termination at compile time.

ncmncm 4y ago
Programs running in microcontrollers routinely do not terminate; they run as long as there is power. Even many ordinary programs run until they are killed. You seem to confuse algorithms, which by definition must terminate, with programs, which do whatever the hell you like (and sometimes things you don't).