5 ms·

Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language t

Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language they select. But yes, complexity is also a major problem.

alkonaut 7y ago
What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with almost any tool. But that's not what's interesting. I want to see tools that not just lets but rather guides inexperienced developers into making maintainable software. Things like "no nulls" or "immutable by default" in Rust and most functional languages are two examples of such designs. OO itself doesn't necessarily mean the developers get trapped in poor code, but the traditional 3 (C++, Java, C#) sure do give developers lots of guns to shoot at their feet. Perhaps not mainly because they are OO, but because they inherited some poor fundamental decisions about mutability and nulls (from C) and about inheritance as a default method of abstraction (from C++) etc.
- pytester 7y ago
  >isn't how easy it is to write good code, but how hard it is to write bad code In many languages they make it harder to write bad code but they do so at the expense of delivering functionality quickly. There's a clear trade off there - one which is often very project dependent (some projects primarily need to develop functionality quickly; others prioritize stability). The problem of slowing down development becomes particularly pronounced when developing something where the biggest risk isn't building the thing wrong, but building the wrong thing. It's extremely expensive to use a very strict language if you're developing code where requirements are highly in flux and cannot be discerned up front. Ideally general purpose languages should enable a smooth transition from coding up a prototype/MVP all the way to production-hardened, spotlessly clean code. I like rust a lot but I would only use it to write very low level code where the requirements are cast in stone and speed and stability is of the utmost importance. It's a lovely language but it's very slow to build stuff in, and in almost all cases it should be used to rewrite something existing rather than to build it anew.
  - alkonaut 7y ago
    I agree - in a prototyping phase it may be beneficial to be able to throw something together. The problem is that what you throw together is invariably the base for the real thing. The motto of "design one to throw away" is great, but I haven't seen it applied as much as it should. Using a "stiff" set of tools might slow down the first stages of prototyping, but it also makes the prototype easier to modify as requirements change. The question I suppose is simply where the equilibrium occurs. I.e. does Rust or F# make a thing that is easier to modify (because of less coupling) already after one or two months, or only after one or two years?
    - pytester 7y ago
      >The problem is that what you throw together is invariably the base for the real thing. This isn't invariable at all. More often what you throw together gets thrown away. I'd estimate this happens to more (working) code I've written over my career than not. The hardest thing to get right is often getting the contours of a tool right and ascertaining what it should do - not making it work right after it has proven itself. >Using a "stiff" set of tools might slow down the first stages of prototyping, but it also makes the prototype easier to modify as requirements change. This is only really the case where the prototype was fundamentally solving the right problem in the right way to begin with and the subsequent changes are incremental in nature. If the design of, say, a microcomponent is flawed from the outset or it did the wrong thing and you have to re-do it, those "stiff" tools slow you down. Using an extremely strict set of tools in a prototyping environment also invariably means a lot of extra up front work dealing with the tools' attempts to protect you from bugs which have an extremely low probability of occurring and/or an extremely low cost when they do occur. If F# or rust or haskell really was quicker and more effective in a prototyping environment as well as when writing production hardened code, programmers would likely eventually converge on only using them. That isn't what is happening.
      - morgancmartin 7y ago
        > If F# or rust or haskell really was quicker and more effective in a prototyping environment as well as when writing production hardened code, programmers would likely eventually converge on only using them. That isn't what is happening. This does not seem to me to be a safe assumption to make. The market is irrational. There is no reason to believe popularity has any significant correlation to the effectiveness of a tool.
- pjmlp 7y ago
  On the other hand, very few languages are capable to rival C++, Java, C# in terms of tooling and available libraries.
fnordsensei 7y ago
On the other hand, it seems a bit wild to propose that tools don’t have inherent affordances of their own. What complicates assessment is that for many attributes, it’s impossible to assess the tool and the user in isolation. This is not unique to programming languages.

alkonaut 7y ago

What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with almost any tool. But that's not what's interesting. I want to see tools that not just lets but rather guides inexperienced developers into making maintainable software. Things like "no nulls" or "immutable by default" in Rust and most functional languages are two examples of such designs. OO itself doesn't necessarily mean the developers get trapped in poor code, but the traditional 3 (C++, Java, C#) sure do give developers lots of guns to shoot at their feet. Perhaps not mainly because they are OO, but because they inherited some poor fundamental decisions about mutability and nulls (from C) and about inheritance as a default method of abstraction (from C++) etc.

pytester 7y ago
>isn't how easy it is to write good code, but how hard it is to write bad code In many languages they make it harder to write bad code but they do so at the expense of delivering functionality quickly. There's a clear trade off there - one which is often very project dependent (some projects primarily need to develop functionality quickly; others prioritize stability). The problem of slowing down development becomes particularly pronounced when developing something where the biggest risk isn't building the thing wrong, but building the wrong thing. It's extremely expensive to use a very strict language if you're developing code where requirements are highly in flux and cannot be discerned up front. Ideally general purpose languages should enable a smooth transition from coding up a prototype/MVP all the way to production-hardened, spotlessly clean code. I like rust a lot but I would only use it to write very low level code where the requirements are cast in stone and speed and stability is of the utmost importance. It's a lovely language but it's very slow to build stuff in, and in almost all cases it should be used to rewrite something existing rather than to build it anew.
- alkonaut 7y ago
  I agree - in a prototyping phase it may be beneficial to be able to throw something together. The problem is that what you throw together is invariably the base for the real thing. The motto of "design one to throw away" is great, but I haven't seen it applied as much as it should. Using a "stiff" set of tools might slow down the first stages of prototyping, but it also makes the prototype easier to modify as requirements change. The question I suppose is simply where the equilibrium occurs. I.e. does Rust or F# make a thing that is easier to modify (because of less coupling) already after one or two months, or only after one or two years?
  - pytester 7y ago
    >The problem is that what you throw together is invariably the base for the real thing. This isn't invariable at all. More often what you throw together gets thrown away. I'd estimate this happens to more (working) code I've written over my career than not. The hardest thing to get right is often getting the contours of a tool right and ascertaining what it should do - not making it work right after it has proven itself. >Using a "stiff" set of tools might slow down the first stages of prototyping, but it also makes the prototype easier to modify as requirements change. This is only really the case where the prototype was fundamentally solving the right problem in the right way to begin with and the subsequent changes are incremental in nature. If the design of, say, a microcomponent is flawed from the outset or it did the wrong thing and you have to re-do it, those "stiff" tools slow you down. Using an extremely strict set of tools in a prototyping environment also invariably means a lot of extra up front work dealing with the tools' attempts to protect you from bugs which have an extremely low probability of occurring and/or an extremely low cost when they do occur. If F# or rust or haskell really was quicker and more effective in a prototyping environment as well as when writing production hardened code, programmers would likely eventually converge on only using them. That isn't what is happening.
    - morgancmartin 7y ago
      > If F# or rust or haskell really was quicker and more effective in a prototyping environment as well as when writing production hardened code, programmers would likely eventually converge on only using them. That isn't what is happening. This does not seem to me to be a safe assumption to make. The market is irrational. There is no reason to believe popularity has any significant correlation to the effectiveness of a tool.
pjmlp 7y ago
On the other hand, very few languages are capable to rival C++, Java, C# in terms of tooling and available libraries.

fnordsensei 7y ago

On the other hand, it seems a bit wild to propose that tools don’t have inherent affordances of their own. What complicates assessment is that for many attributes, it’s impossible to assess the tool and the user in isolation. This is not unique to programming languages.