33 ms·

>I'm hoping the technology will advance enough so that we eventually get one language that can navigate both side of the spectrum. Giving you the ease of Python

by jasode 7y ago

>I'm hoping the technology will advance enough so that we eventually get one language that can navigate both side of the spectrum. Giving you the ease of Python/Ruby scripting, data analysis, and agility for medium projects, but letting you transition to Haskell/Rust safety nets and perfs with strict typing + memory safety without GC + good I/O hygiene in a progressive way. Something that can scale up, and scale down. [...] >Now you could argue that we can't have it all: choose the right tool for the right job. But I disagree. I think we will eventually have it all. The idea of One Language that covers everything (or even most scenarios) is a seductive goal but it's not mathematically possible to create because the finite characters we use to design a language's syntax forces us to make certain concepts more inconvenient than others. This inevitably leads to multiple languages that emphasize different techniques. Previous comments about why this is unavoidable: https://news.ycombinator.com/item?id=15483141 https://news.ycombinator.com/item?id=15483141 https://news.ycombinator.com/item?id=19974887 https://news.ycombinator.com/item?id=19974887 (One could argue that the lowest level of binary 0s and 1s is already the "One Programming Language For Everything" because it's the ancestor of all subsequent languages but that's just an academic distinction. Working in pure 0s and 1s is not a realistic language for working programmers and they'd inevitably find the syntax too inconvenient and thus invent new languages on top of it such as assembly code, Lisp, etc.)

BiteCode_dev 7y ago
> not mathematically possible to create because the finite characters we use to design a language's syntax forces us to make certain concepts more inconvenient than others There is a huge number of combinations possible, especially once keywords come into play. I don't think that's the limitation. On big limitation is that people that are good at creating dynamic languages are bad at creating strict ones, and vice versa. You can see in a comment bellow than some people talk about swift, Raiky, kotlin like solutions to this problem (as I mentioned in my post it would happen). But of course, they don't have the I/O solution Haskell has, the borrow checker rust has, nor the agility or signal/noise ratio of Python. They have a compromise. A compromise that can be good. Those languages are well designed. But it's not "the ultimate solution", because the don't navigate any end of the spectrum.
- jasode 7y ago
  ">There is a huge number of combinations possible, especially once keywords come into play. I don't think that's the limitation." The mathematical limitation still remains even if you switch from 1-character symbols like '+' to verbose words like "plus()". You can attempt to invent a new programming language using longer keywords but you'll still run into contradictions of expressing concepts because there's always an implicit runtime assumption behind any syntax that hides the raw manipulation of 0s and 1s. If you didn't hide such assumptions (i.e. "abstractions"), then that means the 0s & 1s and NAND gates would be explicitly visible to the programmer at the syntax layer and that's unusable for non-trivial programs. There's a reason why no credible computer science paper[0] has claimed to have invented the One Programming Language that can cover the full spectrum of tasks for all situations. It's not because computer scientists with PhDs over the last 50 years are collectively dumb. It's because it's not mathematically possible. [0] e.g. one can search academic archives: https://arxiv.org/archive/cs https://arxiv.org/archive/cs
  - BiteCode_dev 7y ago
    It would be like saying you can't have high level languages because assembly have only a few limited combinations of registers. You can always abstract things away. In fact, you are making the assumption that there is no more generalist logical concepts we can discover that can abstract or merge what now appears to be conflicting paradigms. I imagine people said that to Argand. Nah, you can't do that sqrt(-1) thing, you'll run into contradictions. Given that we have been at the task for less than a century, which is like 1 minute of human history, I'm not inclined to such categorical rejection of the possibility.
  - SAI_Peregrinus 7y ago
    Unlambda makes everything equally difficult!
pythonaut_16 7y ago
I don't think syntax is the big limitation here; it's library and behavior design. The One Language concept could still be considered to be accomplished by a language with two syntaxes provided they have a low friction to interoperability.
andrewflnr 7y ago
I believe this is a failure of imagination. I'm not a beginner programmer. I've played with a lot of different languages and read about a lot more, and I still have a strong gut feeling that they can be unified if we just figure out the right framework. Note that I, for one, would consider a language that shepherds you towards highly interoperable DSLs to be (close to) a success; something like Racket that could generate efficient native binaries would be really close... I don't believe for a second that syntax is the obstacle. You can express all the complexity you need with composition. Also, the One True Language will obviously have macros.
- jasode 7y ago
  > I, for one, would consider a language that shepherds you towards highly interoperable DSLs [...] Also, the One True Language will obviously have macros. But that just motivates someone else who isn't you to prefer another language that has that "DSL" and macros as the baseline syntax of the new language for convenience. Now you have 2+ languages again. If someone else prefers not to type out extra parentheses ")))))" to balance things and/or requires highest performance of no GC, then a "Racket/Lisp-like" language can't be the basis of The One True Language. >You can express all the complexity you need with composition. True, and to generalize further, a Turing Complete language can be used to create another Turing Complete language. But the ability to build any complexity by composition is itself the motivation to create another programming language that doesn't require the extra work of composition. For example, one can program in the C Language and combine its primitives to build the "C++ Language" (first C++ compiler was C-with-classes) and the C++ Language can be used to build Javascript interpreter (Netscape browser was written in C++). And then Javascript can be used to build the first Typescript compiler. Thus we might say (via tortured logic) that C Language can let you write a "DSL" as complicated as C++ and Javascript and Typescript. Even though that's true in sense, people don't think of "C Language" as the One True Language. It's the same situation of not thinking of low-level 0s and 1s of NAND gates as being the One True Language even though composition of NAND gates will let you build any other language.
  - andrewflnr 7y ago
    > But that just motivates someone else who isn't you to prefer another language Sure, they'll want to, and they probably will, but they won't have to due to performance or other constraints, which is how I understood the goal. > But the ability to build any complexity by composition is itself the motivation to create another programming language that doesn't require the extra work of composition. That's what the macros are for. All part of the plan. > ... Even though that's true in sense, people don't think of "C Language" as the One True Language. C is not certainly not a convenient language for hosting DSLs, due to insufficient abstraction capabilities, but the real missing ingredient is interop between the DSLs. C doesn't make it easy to pass data between them, etc. NAND gates are not a great comparison. You want to be composing abstractions to create other composable abstractions. You could extend the analogy to composing circuits into bigger circuits, but that's really just converging back to a high level language.
deleted 7y ago
[deleted]

by jasode 7y ago

BiteCode_dev 7y ago

> not mathematically possible to create because the finite characters we use to design a language's syntax forces us to make certain concepts more inconvenient than others There is a huge number of combinations possible, especially once keywords come into play. I don't think that's the limitation. On big limitation is that people that are good at creating dynamic languages are bad at creating strict ones, and vice versa. You can see in a comment bellow than some people talk about swift, Raiky, kotlin like solutions to this problem (as I mentioned in my post it would happen). But of course, they don't have the I/O solution Haskell has, the borrow checker rust has, nor the agility or signal/noise ratio of Python. They have a compromise. A compromise that can be good. Those languages are well designed. But it's not "the ultimate solution", because the don't navigate any end of the spectrum.

jasode 7y ago
">There is a huge number of combinations possible, especially once keywords come into play. I don't think that's the limitation." The mathematical limitation still remains even if you switch from 1-character symbols like '+' to verbose words like "plus()". You can attempt to invent a new programming language using longer keywords but you'll still run into contradictions of expressing concepts because there's always an implicit runtime assumption behind any syntax that hides the raw manipulation of 0s and 1s. If you didn't hide such assumptions (i.e. "abstractions"), then that means the 0s & 1s and NAND gates would be explicitly visible to the programmer at the syntax layer and that's unusable for non-trivial programs. There's a reason why no credible computer science paper[0] has claimed to have invented the One Programming Language that can cover the full spectrum of tasks for all situations. It's not because computer scientists with PhDs over the last 50 years are collectively dumb. It's because it's not mathematically possible. [0] e.g. one can search academic archives: https://arxiv.org/archive/cs https://arxiv.org/archive/cs
- BiteCode_dev 7y ago
  It would be like saying you can't have high level languages because assembly have only a few limited combinations of registers. You can always abstract things away. In fact, you are making the assumption that there is no more generalist logical concepts we can discover that can abstract or merge what now appears to be conflicting paradigms. I imagine people said that to Argand. Nah, you can't do that sqrt(-1) thing, you'll run into contradictions. Given that we have been at the task for less than a century, which is like 1 minute of human history, I'm not inclined to such categorical rejection of the possibility.
- SAI_Peregrinus 7y ago
  Unlambda makes everything equally difficult!

pythonaut_16 7y ago

I don't think syntax is the big limitation here; it's library and behavior design. The One Language concept could still be considered to be accomplished by a language with two syntaxes provided they have a low friction to interoperability.

andrewflnr 7y ago

I believe this is a failure of imagination. I'm not a beginner programmer. I've played with a lot of different languages and read about a lot more, and I still have a strong gut feeling that they can be unified if we just figure out the right framework. Note that I, for one, would consider a language that shepherds you towards highly interoperable DSLs to be (close to) a success; something like Racket that could generate efficient native binaries would be really close... I don't believe for a second that syntax is the obstacle. You can express all the complexity you need with composition. Also, the One True Language will obviously have macros.

jasode 7y ago
> I, for one, would consider a language that shepherds you towards highly interoperable DSLs [...] Also, the One True Language will obviously have macros. But that just motivates someone else who isn't you to prefer another language that has that "DSL" and macros as the baseline syntax of the new language for convenience. Now you have 2+ languages again. If someone else prefers not to type out extra parentheses ")))))" to balance things and/or requires highest performance of no GC, then a "Racket/Lisp-like" language can't be the basis of The One True Language. >You can express all the complexity you need with composition. True, and to generalize further, a Turing Complete language can be used to create another Turing Complete language. But the ability to build any complexity by composition is itself the motivation to create another programming language that doesn't require the extra work of composition. For example, one can program in the C Language and combine its primitives to build the "C++ Language" (first C++ compiler was C-with-classes) and the C++ Language can be used to build Javascript interpreter (Netscape browser was written in C++). And then Javascript can be used to build the first Typescript compiler. Thus we might say (via tortured logic) that C Language can let you write a "DSL" as complicated as C++ and Javascript and Typescript. Even though that's true in sense, people don't think of "C Language" as the One True Language. It's the same situation of not thinking of low-level 0s and 1s of NAND gates as being the One True Language even though composition of NAND gates will let you build any other language.
- andrewflnr 7y ago
  > But that just motivates someone else who isn't you to prefer another language Sure, they'll want to, and they probably will, but they won't have to due to performance or other constraints, which is how I understood the goal. > But the ability to build any complexity by composition is itself the motivation to create another programming language that doesn't require the extra work of composition. That's what the macros are for. All part of the plan. > ... Even though that's true in sense, people don't think of "C Language" as the One True Language. C is not certainly not a convenient language for hosting DSLs, due to insufficient abstraction capabilities, but the real missing ingredient is interop between the DSLs. C doesn't make it easy to pass data between them, etc. NAND gates are not a great comparison. You want to be composing abstractions to create other composable abstractions. You could extend the analogy to composing circuits into bigger circuits, but that's really just converging back to a high level language.

deleted 7y ago

[deleted]