5 ms·

> https://vimeo.com/9270320 https://vimeo.com/9270320 There's very little you can prove, other than "less code gives you fewer errors/bugs". Arguably, this is

> https://vimeo.com/9270320 https://vimeo.com/9270320 There's very little you can prove, other than "less code gives you fewer errors/bugs". Arguably, this is primarily due to specification gaps being opaque and less logic to hold state. You can't file a bug or raise an issue about a choice that was already made by a dynamic language. > It's only a shame if you presume to know better than all of those developers. Statistically, someone is going to be right. The "right tool for the job" trope does not extend to every facet of every choice. The totality of developers are not experts in every set of practices (while it still may apply to some cases). Less code is better and until there's a study to say something more, I'm not interested in the hand waving. > > Many of the people who came up with or promoted the idea of dynamically typed languages > Most of the designers of the initial statically typed languages came from that same era This isn't an argument about better, but precisely the point you turn around and make. It's not worse. Less code is better, for sure. > Without something like Smalltalk's "open a code editor when an error occurs" live debugging/editing experience, you'll never get the real benefits of dynamic typing. Debuggers allow this. You generally don't want the user to have this power. There is a shocking lack of science in the industry. Re: The Quorum Programming Language made some attempts at advancement. It's been decades and I still see the same squabbles and continue doing 10x more with dynamic languages than when I am forced back to something like Java. At some point, I have to assume that I'm special or one of those language choices are crippling.

munificent 7y ago
> Statistically, someone is going to be right. Yes. If you ask 100 people what the answer to "3 + 5" is, you'll mostly get "8". But that's because you're asking them all for the right answer to the same problem. If you ask 80 of them the answer to "3 + 5" and 20 the answer to "3 + 2", the right answer isn't 8 and the people who answered 5 for the latter aren't wrong. They are solving different problems. Given the breadth of computing today, it seems very unlikely to me that all programmers are solving the same problem, and thus that there is a single objective right answer for what language or language paradigm is best. It certainly doesn't align with my own personal experience, where I can't point to a single language that I would prefer for all of the different kinds of programs I've written. > Debuggers allow this. Yes, with limitations. A SmallTalker will tell you that debuggers are a pale imitation of the full experience. (I don't have much first-hand experience with it myself, but I know people who get misty-eyed when you ask them about it, despite being very familiar with "modern" debuggers.) > You generally don't want the user to have this power. I don't disagree with you personally, but there's a counter-argument that forcibly separating people into "developers" and "users" is itself a moral failing akin to welding the hood shut on a car. > There is a shocking lack of science in the industry. I'd like more science too, but I don't find its absence that shocking. PL is very hard and expensive to study scientifically. Doing controlled experiments is very difficult when step one is "Design an entire programming language, implement it and all of its tools and ecosystem, and then get people to spend a long amount of time learning it to proficiency." That's a lot more difficult than "Take a sip of two sodas and tell me which one you like more", and even that simple experiment turned out to be famously flawed.
- civility 7y ago
  > 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.

munificent 7y ago

> Statistically, someone is going to be right. Yes. If you ask 100 people what the answer to "3 + 5" is, you'll mostly get "8". But that's because you're asking them all for the right answer to the same problem. If you ask 80 of them the answer to "3 + 5" and 20 the answer to "3 + 2", the right answer isn't 8 and the people who answered 5 for the latter aren't wrong. They are solving different problems. Given the breadth of computing today, it seems very unlikely to me that all programmers are solving the same problem, and thus that there is a single objective right answer for what language or language paradigm is best. It certainly doesn't align with my own personal experience, where I can't point to a single language that I would prefer for all of the different kinds of programs I've written. > Debuggers allow this. Yes, with limitations. A SmallTalker will tell you that debuggers are a pale imitation of the full experience. (I don't have much first-hand experience with it myself, but I know people who get misty-eyed when you ask them about it, despite being very familiar with "modern" debuggers.) > You generally don't want the user to have this power. I don't disagree with you personally, but there's a counter-argument that forcibly separating people into "developers" and "users" is itself a moral failing akin to welding the hood shut on a car. > There is a shocking lack of science in the industry. I'd like more science too, but I don't find its absence that shocking. PL is very hard and expensive to study scientifically. Doing controlled experiments is very difficult when step one is "Design an entire programming language, implement it and all of its tools and ecosystem, and then get people to spend a long amount of time learning it to proficiency." That's a lot more difficult than "Take a sip of two sodas and tell me which one you like more", and even that simple experiment turned out to be famously flawed.

civility 7y ago
> 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.