5 ms·

> I can't point to a single language that I would prefer for all of the different kinds of programs I've written. I never liked the "pick the right tool for jo

> I can't point to a single language that I would prefer for all of the different kinds of programs I've written. I never liked the "pick the right tool for job" cliche in the context of programming languages. I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? Other than size, weight, power, and price limitations, I don't pick different computers for different problems. I mean I could live with one ISA for pretty much everything, including GPUs. I'm sure different people would pick different answers (one of your points), but after looking at a lot of languages over the years (including some of yours), I can't come up with two features I want which are inherently in conflict and necessitate being different languages. I don't think it has to be a superset of all languages monstrosity either. And for the sake of argument, let's say this is just for one-person development. There's too much politics in trying to decide what features you /don't/ want your coworkers to abuse. :-)

munificent 7y ago
> I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? Nope. Granted, I may work on a greater breadth of software than the average programmer. But, at the very least, I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management. But I sure as hell prefer memory safe languages when I'm not doing that. I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything. Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong.
- civility 7y ago
  > I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management Fair enough, and I guess I'm forced to agree a little. However, if the one true language already existed, the VM/GC problem wouldn't have to be solved twice. Somebody had to write the first assembler in machine code, too. I've written a (Hans Boehm style) GC of my own, and I admit that wouldn't fit with what I had in mind either, but working with raw bytes is a solvable problem in almost any level of programming language as a few library functions. All the batch or command line utilities, GUI applications, back end server modules, and most of the one-off exploratory programs could fit in a single elegant language. > I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything. Again I agree, but (to me) this has a solution. I could be very content with a statically typed language with a single variant type for when you need to handle JSON-ish type dynamic variables or hierarchical data. I think dynamic and static typing can coexist very nicely in one language. > Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong. I did caveat this was for single person programs and that different people would make different choices. I think my point was just that, having looked at languages from Icon to Prolog to SQL to Scheme to Ocaml to Rust to C++ and a lot of others, I think there is a point in the high-D trade space where I would be content to live and breath for almost every programming problem. I've never gotten anyone else to agree, but I think it's an interesting exercise to fill in the details. I mean, computers are so much malleable than real world tools - you could have a single thing which handles screws, nails, rivets, and bolts effectively.
- mpweiher 7y ago
  I find Objective-C to have that range. I have used it for implementing everything from kernel drivers (DriverKit, yay!) to programming languages to server apps and GUI apps. Not perfect at the entire range, but it does have it. And having used it and seen what worked well and what didn't, I have some ideas as to how to make it better. I think it could be improved by having the Smalltalk-side be the default and then add mechanisms to move towards the machine again. Either very simply (add some primitive type declarations) or with greater power, from a less constrained base.
  - civility 7y ago
    I always liked the way Objective-C added the message passing syntax in a way which fit in well with C. The [squareBrackets means: "we're in SmallTalk land"] looks nice to me. The @ (at sign) sigils I don't appreciate as much. > I think it could be improved by having the Smalltalk-side be the default It does kind of seem like you'd want the higher level language on the outside and only dive into the lower language when you need it, but I could go either way for that.
jasode 7y ago
>I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? >However, if the one true language already existed, The one true language can't exist because we want to use a finite set of characters to express convenient programming syntax. (A previous comment about this.[0]) It might be possible to craft a single optimal language for only one particular programmer but I even doubt that limited scenario is even realistic. Consider trying to combine syntax of 2 languages that many programmers use: (1) bash (2) C Language In bash, running an external program is a first class concept. Therefore the syntax is simple. E.g.: gzip file.txt rsync $HOME /backup Basically, whatever one types at a bash command prompt is just copy-pasted into a .sh file. But in C Language, external programs are not first-class concepts so one must use a library call such as "system()": main() { system("gzip file.txt"); system("rsync $HOME /backup"); } In C, we have to type out "system("")" that surrounds each external program. We have to add the noisier syntax of semicolons after each line. It's ugly and verbose for scripting work. In the reverse example, C makes it easy to bit-shift a number using << and >>. y = x << 3; How would one transfer that cleanly and conveniently to bash? Bash uses a bunch of special symbols for special functions.[1] Bashes uses << >> for input output redirection. Therefore, bash would need to have noisier syntax such as "bitshiftleft(x, 3)" So, if we attempt to create a Frankenstein language called "bashclang" that combine concepts of bash and C, which set of programmers do we inconvenience with the noisier syntax? What if we just tweaked C's parsing rules so that naked syntax to run external programs would look like bash? Well, what if you have executable binaries with names like "void", "switch"? Those are reserved names in C Language. Same thing happens with other concepts like matrices. In Julia and Mathematica, matrices are first class. You can type them conveniently without any special decoration. But in Python, they are bolted on with a package like NumPy. So one has type type out the noiser syntax of np.full() and np.matmul(). Convenient syntax to enable easy-to-read semantics in one language leads to contradictions and ambiguity in another language. To add to munificent's comment, I also don't see how one language can offer both garbage-collected memory and manual allocated memory using convenient concise syntax _and_ and zero-cost runtime performance-penalty for manual memory. Those two goals contradict each other. When I want to write a line-of-business type app, I just use C# with GC strings. On the other hand, when I'm writing a server-side app that's processing terabytes of data, I can use C++ with manually allocated strings with no virtualmachine runtime overhead for max performance. [0] https://news.ycombinator.com/item?id=15483141 https://news.ycombinator.com/item?id=15483141 [1] https://mywiki.wooledge.org/BashGuide/SpecialCharacters https://mywiki.wooledge.org/BashGuide/SpecialCharacters
mpweiher 7y ago
> never liked the "pick the right tool for job" cliche in the context of programming languages Me neither. Many of the differences are fairly random, at least in relation to the task they're being applied to. Reminds me of the distinction we had in the late 80s and early 90s between "server" and "client" operating systems. "Client" operating systems had user friendly GUIs and crashed a lot. "Server" operating systems were solid but didn't have (nice) GUIs. Makes sense, right? Except that it was complete hogwash, there was no actual reason for it except random chance/history. As NeXTstep amply proved. Why do we have Java with byte-codes on the server? This was initially invented for small machines, and the bytecodes/VM were for applets and "write once, run anywhere". How does that make sense on a server. You are deploying to a known machine. With a known instruction set architecture. It doesn't, that's how. But Java failed on the desktop and the server was all that was left. > I don't think it has to be a superset of all languages monstrosity either. Agreed. Most programming languages are actually quite similar. I am personally finding that the concepts I am adding to Objective-Smalltalk[1] work well, er, "synergistically" in (a) shell scripting (b) application scripting (c) GUI programming (d) server programming. Haven't really tried HPC or embedded yet. [1] http://objective.st http://objective.st

munificent 7y ago

> I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? Nope. Granted, I may work on a greater breadth of software than the average programmer. But, at the very least, I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management. But I sure as hell prefer memory safe languages when I'm not doing that. I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything. Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong.

civility 7y ago
> I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management Fair enough, and I guess I'm forced to agree a little. However, if the one true language already existed, the VM/GC problem wouldn't have to be solved twice. Somebody had to write the first assembler in machine code, too. I've written a (Hans Boehm style) GC of my own, and I admit that wouldn't fit with what I had in mind either, but working with raw bytes is a solvable problem in almost any level of programming language as a few library functions. All the batch or command line utilities, GUI applications, back end server modules, and most of the one-off exploratory programs could fit in a single elegant language. > I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything. Again I agree, but (to me) this has a solution. I could be very content with a statically typed language with a single variant type for when you need to handle JSON-ish type dynamic variables or hierarchical data. I think dynamic and static typing can coexist very nicely in one language. > Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong. I did caveat this was for single person programs and that different people would make different choices. I think my point was just that, having looked at languages from Icon to Prolog to SQL to Scheme to Ocaml to Rust to C++ and a lot of others, I think there is a point in the high-D trade space where I would be content to live and breath for almost every programming problem. I've never gotten anyone else to agree, but I think it's an interesting exercise to fill in the details. I mean, computers are so much malleable than real world tools - you could have a single thing which handles screws, nails, rivets, and bolts effectively.
mpweiher 7y ago
I find Objective-C to have that range. I have used it for implementing everything from kernel drivers (DriverKit, yay!) to programming languages to server apps and GUI apps. Not perfect at the entire range, but it does have it. And having used it and seen what worked well and what didn't, I have some ideas as to how to make it better. I think it could be improved by having the Smalltalk-side be the default and then add mechanisms to move towards the machine again. Either very simply (add some primitive type declarations) or with greater power, from a less constrained base.
- civility 7y ago
  I always liked the way Objective-C added the message passing syntax in a way which fit in well with C. The [squareBrackets means: "we're in SmallTalk land"] looks nice to me. The @ (at sign) sigils I don't appreciate as much. > I think it could be improved by having the Smalltalk-side be the default It does kind of seem like you'd want the higher level language on the outside and only dive into the lower language when you need it, but I could go either way for that.

jasode 7y ago

>I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? >However, if the one true language already existed, The one true language can't exist because we want to use a finite set of characters to express convenient programming syntax. (A previous comment about this.[0]) It might be possible to craft a single optimal language for only one particular programmer but I even doubt that limited scenario is even realistic. Consider trying to combine syntax of 2 languages that many programmers use: (1) bash (2) C Language In bash, running an external program is a first class concept. Therefore the syntax is simple. E.g.: gzip file.txt rsync $HOME /backup Basically, whatever one types at a bash command prompt is just copy-pasted into a .sh file. But in C Language, external programs are not first-class concepts so one must use a library call such as "system()": main() { system("gzip file.txt"); system("rsync $HOME /backup"); } In C, we have to type out "system("")" that surrounds each external program. We have to add the noisier syntax of semicolons after each line. It's ugly and verbose for scripting work. In the reverse example, C makes it easy to bit-shift a number using << and >>. y = x << 3; How would one transfer that cleanly and conveniently to bash? Bash uses a bunch of special symbols for special functions.[1] Bashes uses << >> for input output redirection. Therefore, bash would need to have noisier syntax such as "bitshiftleft(x, 3)" So, if we attempt to create a Frankenstein language called "bashclang" that combine concepts of bash and C, which set of programmers do we inconvenience with the noisier syntax? What if we just tweaked C's parsing rules so that naked syntax to run external programs would look like bash? Well, what if you have executable binaries with names like "void", "switch"? Those are reserved names in C Language. Same thing happens with other concepts like matrices. In Julia and Mathematica, matrices are first class. You can type them conveniently without any special decoration. But in Python, they are bolted on with a package like NumPy. So one has type type out the noiser syntax of np.full() and np.matmul(). Convenient syntax to enable easy-to-read semantics in one language leads to contradictions and ambiguity in another language. To add to munificent's comment, I also don't see how one language can offer both garbage-collected memory and manual allocated memory using convenient concise syntax _and_ and zero-cost runtime performance-penalty for manual memory. Those two goals contradict each other. When I want to write a line-of-business type app, I just use C# with GC strings. On the other hand, when I'm writing a server-side app that's processing terabytes of data, I can use C++ with manually allocated strings with no virtualmachine runtime overhead for max performance. [0] https://news.ycombinator.com/item?id=15483141 https://news.ycombinator.com/item?id=15483141 [1] https://mywiki.wooledge.org/BashGuide/SpecialCharacters https://mywiki.wooledge.org/BashGuide/SpecialCharacters

mpweiher 7y ago

> never liked the "pick the right tool for job" cliche in the context of programming languages Me neither. Many of the differences are fairly random, at least in relation to the task they're being applied to. Reminds me of the distinction we had in the late 80s and early 90s between "server" and "client" operating systems. "Client" operating systems had user friendly GUIs and crashed a lot. "Server" operating systems were solid but didn't have (nice) GUIs. Makes sense, right? Except that it was complete hogwash, there was no actual reason for it except random chance/history. As NeXTstep amply proved. Why do we have Java with byte-codes on the server? This was initially invented for small machines, and the bytecodes/VM were for applets and "write once, run anywhere". How does that make sense on a server. You are deploying to a known machine. With a known instruction set architecture. It doesn't, that's how. But Java failed on the desktop and the server was all that was left. > I don't think it has to be a superset of all languages monstrosity either. Agreed. Most programming languages are actually quite similar. I am personally finding that the concepts I am adding to Objective-Smalltalk[1] work well, er, "synergistically" in (a) shell scripting (b) application scripting (c) GUI programming (d) server programming. Haven't really tried HPC or embedded yet. [1] http://objective.st http://objective.st