42 ms·

> The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I wri

> The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English. I think this is the root of the disagreement. For my domain at least, I find it very hard to write robust software in some languages and fairly routine in others. Unfortunately the data on this topic is very limited - typically groups of college students implement something in various languages to compare. Hardly a realistic test. What I can point to are code constructs that I cannot make in certain languages where the work arounds are either more verbose or less precise.

jstimpfle 4y ago
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

jstimpfle 4y ago

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