4 ms·

As I said I'd likely use a different language if working in a different domain (but then again I'm not). But you will be hard pressed to find a serious domain

As I said I'd likely use a different language if working in a different domain (but then again I'm not). But you will be hard pressed to find a serious domain where there aren't solid mainstream tech choices. > What I can point to are code constructs that I cannot make in certain languages This is what I was alluding to, these examples are not very relevant. In a larger-scale codebase the important thing is the structure that you build, not the structure you get for free (or are being imposed) by the language. If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases. Functions and records (structs) are sufficient to cover you in almost all real world situations. I believe that the step up from assembly to higher-level languages is a very powerful step, because it frees you from doing a repetitive task again and again, that you can't even realistically do better than the compiler (because of time constraints), at least not on a large scale. Another reason that the step works is that what it automizes are quite local issues to solve. Barring extreme optimization requirements, we can simply come up with a function call ABI and have the compiler solve all register allocation for us. The tradeoffs and ramifications of this are quite clear - we can be confident by now that there are no unknown tradeoffs that will come haunt us later when the project has grown much bigger. The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Garbage collection is another big help automating the repetitive in some domains, but it gets in the way in other domains.

nicoburns 4y ago
> The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them One thing that's hard to express with them is a data type that's TypeA OR TypeB OR TypeC. For that you need Sum Types, which a lot of the newer generation of languages (Rust, Swift, Kotlin) have, but the older generation (Java, C#, C++) historically haven't had at all and still have poor support for. I find this to be a significant productivity boost over languages that don't support this.
- jstimpfle 4y ago
  That's a good point. ADTs (algebraic data types) are certainly nice for certain classes of mathsy problems, compilers, and similar. As I'm moving more and more towards distributed systems work (as well as in-process messaging, queuing, and event handling) I'm still figuring out if I want ADTs things built in, or if enums + simple code are good enough to cover my needs. One thing I don't particularly about ADTs is that they remove opportunities to tweak the representation, and make you think less about smarter ways of avoiding certain complexities caused by choice (Sum Types) in the first place. But I have to admit that very often I'm simply doing the "struct with a tag member and a union member" thing manually, which one gets for free by using standardized ADT syntax.
  - couchand 4y ago
    What's nice about an ADT is that you can actually prove you didn't mess up the tag union. The trust you get from that is a force enabler.
    - jstimpfle 4y ago
      Yes sure - if it becomes a pattern, it makes sense as a language feature. Conversely, if it is a language feature there is the danger of it becoming a pattern without need.
couchand 4y ago
> If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases. This presupposes that the language even has facilities to enable appropriate abstractions! You can't argue that languages don't matter without reckoning with these real world matters. Yes, sure, I can just "abstract it away", yes, sure, "all languages are Turing complete so equivalent".... but no, that's not the whole story at all. > The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Expressive types are that next step up.
- jstimpfle 4y ago
  > Expressive types are that next step up. Maybe, sometimes, ... - in practice, I've often seen them pave the path to madness. When types become "expressive" the problem is that now you have to deal with 2 languages. An ok one and a soul suckingly bad one.

nicoburns 4y ago

> The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them One thing that's hard to express with them is a data type that's TypeA OR TypeB OR TypeC. For that you need Sum Types, which a lot of the newer generation of languages (Rust, Swift, Kotlin) have, but the older generation (Java, C#, C++) historically haven't had at all and still have poor support for. I find this to be a significant productivity boost over languages that don't support this.

jstimpfle 4y ago
That's a good point. ADTs (algebraic data types) are certainly nice for certain classes of mathsy problems, compilers, and similar. As I'm moving more and more towards distributed systems work (as well as in-process messaging, queuing, and event handling) I'm still figuring out if I want ADTs things built in, or if enums + simple code are good enough to cover my needs. One thing I don't particularly about ADTs is that they remove opportunities to tweak the representation, and make you think less about smarter ways of avoiding certain complexities caused by choice (Sum Types) in the first place. But I have to admit that very often I'm simply doing the "struct with a tag member and a union member" thing manually, which one gets for free by using standardized ADT syntax.
- couchand 4y ago
  What's nice about an ADT is that you can actually prove you didn't mess up the tag union. The trust you get from that is a force enabler.
  - jstimpfle 4y ago
    Yes sure - if it becomes a pattern, it makes sense as a language feature. Conversely, if it is a language feature there is the danger of it becoming a pattern without need.

couchand 4y ago

> If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases. This presupposes that the language even has facilities to enable appropriate abstractions! You can't argue that languages don't matter without reckoning with these real world matters. Yes, sure, I can just "abstract it away", yes, sure, "all languages are Turing complete so equivalent".... but no, that's not the whole story at all. > The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Expressive types are that next step up.

jstimpfle 4y ago
> Expressive types are that next step up. Maybe, sometimes, ... - in practice, I've often seen them pave the path to madness. When types become "expressive" the problem is that now you have to deal with 2 languages. An ok one and a soul suckingly bad one.