3 ms·

I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language. The hardest problem is usually some

I've been programming for 35 years or more, and I've yet to come across situations where the hard problem was the language. The hardest problem is usually something else, but IME some languages make it much easier to solve a given hard problem than others. Some languages are qualitatively safer. Some languages are much more expressive, in the sense that I can implement my solution with far less code/time/cost without compromising anywhere else. There is a difference between whether I can solve a problem and how efficiently and pleasantly I can solve a problem. I find choice of language rarely affects the former but often profoundly affects the latter.

PaulDavisThe1st 4y ago
100%. But that's why I mentioned performance. I work with realtime audio, and this puts most of the "pleasantly solve the problem" options off the table.
- Chris_Newton 4y ago
  It’s true that for genuinely performance-sensitive applications the options are more limited, but there are worlds of difference between assembly language, C and Rust, for example. There’s still a place for each of them, but other things being equal, Rust wins by a wide margin on both safety and expressiveness.
  - PaulDavisThe1st 4y ago
    Might be true, but since the hard problems rarely involve safety or expressiveness, it's not clear what the benefit is.
    - Chris_Newton 4y ago
      I’m very curious about what kind of hard problems you have in mind where an implementation wouldn’t benefit from better safety and expressiveness. I’ve done my share of both mathematical and systems programming. In both cases I’d say eliminating types of bug that typically come with low-level/high-performance code was highly relevant. Also, quite often my biggest practical frustration was trying to iterate on a solution while language barriers made implementing each new attempt tedious in some way.
      - kilgnad 4y ago
        databases, haha. That's where modern programming throws most of the hard stuff nowadays. in fact all of the hard parts of modern programming can be characterized by a single problem that all of these languages like go and rust are attempting to solve: Shared mutating state. Really the parent and everyone here is just complaining about this one singular problem and how no language has completely solved it yet with a method that's Easy and safe. In fact all these new languages have a sort of similar primary purpose of attempting to abstract this problem away.
        Chris_Newton 4y ago
        Shared mutating state. Really the parent and everyone here is just complaining about this one singular problem and how no language has completely solved it yet with a method that's Easy and safe. If my comment was the parent you’re referring to, that isn’t really my position at all. Certainly there are challenges that come with shared mutable state, but we also have some good tools for dealing with those already. There is a more general problem of managing side effects and external resources, where I think there’s room for better language support, so that might be a better example. The biggest single frustration I find with many popular programming languages is that once I’ve figured out how to solve the real world problem we’re dealing with, I want to implement that solution as fast as my mind can think and my fingers can type. I don’t want to get bogged down with wrangling general purpose data structures and algorithms, or wondering how to implement an idea with whatever networking or database or mathematical library we use, or writing a screenful of infrastructure plumbing to talk to a cloud service, or trying to figure out all the possible ways that a function I’m calling might tell me it failed and hand-crafting a few lines of boilerplate for every single one. I haven’t found a language and ecosystem yet that I feel give me that, even though I’ve found many features in reasonably well-known languages and libraries and tools that individually make good progress in that direction.
        PaulDavisThe1st 4y ago
        That is not the "single problem" I am complaining about. We already good methods for dealing with this. In fact, we have several, and what is often the hardest coding question is when to use which one (e.g. RCU versus mutexes). There are plenty of other "hard" problems in modern programming that have nothing to do with shared mutating state (unless you broaden the definition of that so much that it becomes essentially meaningless). Here's one example: resolving the tension between cache locality and time-varying data access patterns. Here's another: zero-copy data pathways between user space and hardware. Here's another: resolving the relative costs of fundamental GUI implementation choices (e.g. retained or immediate mode drawing models; pre-rendering components or using vector graphics; absolute positioning vs constraint packing)

PaulDavisThe1st 4y ago

100%. But that's why I mentioned performance. I work with realtime audio, and this puts most of the "pleasantly solve the problem" options off the table.

Chris_Newton 4y ago
It’s true that for genuinely performance-sensitive applications the options are more limited, but there are worlds of difference between assembly language, C and Rust, for example. There’s still a place for each of them, but other things being equal, Rust wins by a wide margin on both safety and expressiveness.
- PaulDavisThe1st 4y ago
  Might be true, but since the hard problems rarely involve safety or expressiveness, it's not clear what the benefit is.
  - Chris_Newton 4y ago
    I’m very curious about what kind of hard problems you have in mind where an implementation wouldn’t benefit from better safety and expressiveness. I’ve done my share of both mathematical and systems programming. In both cases I’d say eliminating types of bug that typically come with low-level/high-performance code was highly relevant. Also, quite often my biggest practical frustration was trying to iterate on a solution while language barriers made implementing each new attempt tedious in some way.
    - kilgnad 4y ago
      databases, haha. That's where modern programming throws most of the hard stuff nowadays. in fact all of the hard parts of modern programming can be characterized by a single problem that all of these languages like go and rust are attempting to solve: Shared mutating state. Really the parent and everyone here is just complaining about this one singular problem and how no language has completely solved it yet with a method that's Easy and safe. In fact all these new languages have a sort of similar primary purpose of attempting to abstract this problem away.
      - Chris_Newton 4y ago
        Shared mutating state. Really the parent and everyone here is just complaining about this one singular problem and how no language has completely solved it yet with a method that's Easy and safe. If my comment was the parent you’re referring to, that isn’t really my position at all. Certainly there are challenges that come with shared mutable state, but we also have some good tools for dealing with those already. There is a more general problem of managing side effects and external resources, where I think there’s room for better language support, so that might be a better example. The biggest single frustration I find with many popular programming languages is that once I’ve figured out how to solve the real world problem we’re dealing with, I want to implement that solution as fast as my mind can think and my fingers can type. I don’t want to get bogged down with wrangling general purpose data structures and algorithms, or wondering how to implement an idea with whatever networking or database or mathematical library we use, or writing a screenful of infrastructure plumbing to talk to a cloud service, or trying to figure out all the possible ways that a function I’m calling might tell me it failed and hand-crafting a few lines of boilerplate for every single one. I haven’t found a language and ecosystem yet that I feel give me that, even though I’ve found many features in reasonably well-known languages and libraries and tools that individually make good progress in that direction.
      - PaulDavisThe1st 4y ago
        That is not the "single problem" I am complaining about. We already good methods for dealing with this. In fact, we have several, and what is often the hardest coding question is when to use which one (e.g. RCU versus mutexes). There are plenty of other "hard" problems in modern programming that have nothing to do with shared mutating state (unless you broaden the definition of that so much that it becomes essentially meaningless). Here's one example: resolving the tension between cache locality and time-varying data access patterns. Here's another: zero-copy data pathways between user space and hardware. Here's another: resolving the relative costs of fundamental GUI implementation choices (e.g. retained or immediate mode drawing models; pre-rendering components or using vector graphics; absolute positioning vs constraint packing)