5 ms·

The presenter focuses on the cost of building software in the first place. Yet, in practice, the cost of maintenance often dwarfs the cost of initial developmen

The presenter focuses on the cost of building software in the first place. Yet, in practice, the cost of maintenance often dwarfs the cost of initial development. This is where statically typed languages hold major advantage of dynamically type ones. In part, thanks to the ease of refactoring with modern IDEs. The presented studies can hardly be used as a basis for making his arguments. The study where a student invests a new language that nobody else could possibly know is especially bad. Of course the learning curve is going to be longer for an invented statically typed language! You cannot assess productivity without factoring out the initial learning time. If anything, that study only shows that dynamically typed languages are easier to get into.

flavio81 9y ago
> Yet, in practice, the cost of maintenance often dwarfs the cost of initial development. However, funding the development is sometimes harder than funding the maintenance: You need the system to operate in the first place in order to get the benefits/money/revenue/etc. Once the system is in place and brings benefits, it is easier to fund further investment on the system, be it maintenance, extension,etc.
- KillSticky 9y ago
  The initial development of a chunk of code is not the same as the initial development of a shippable product. Code maintenance starts the moment you need to go back and add anything nontrivial to the existing code. And you will have to go back and change your code many times while using your initial funding. So the product funding argument, while true, does not apply here. Try reading your own code written two weeks ago. How about a month ago? Three month ago? Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you. If your team member added some more methods, they will be listed too. No need to waste time reading the function source to figure out the return type, and then waste more reading the class's source.
  - flavio81 9y ago
    > Try reading your own code written two weeks ago. How about a month ago? Three month ago? In fact i did. Code of 8 months ago (december 2017). Easy to read, because i used named parameters extensively and added comments at every function Signature. Language Python (dynamic). Don't assume that all programmers can't understand their past code. All my peers (we have over 12 years doing this professionally) would do the same. It is part of our job to read code written even years before by us. You never know when a past customer (internal or external) will call you to want an enhancement or upgrade. > With a statically typed language IDE can always do that for you. So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. (Servers almost never have any kind of IDE or even fancy text editor installed). > And you will have to go back and change your code many times while using your initial funding. I am speaking about production software for using within an enterprise context. You have a defined budget and you need to ship a working product. For us , "maintenance" phase starts after the product has gone live in production. For us, if we deploy a working product, it is easy to get additional funding for maintenance and improvement. If we don't, we don't get subsequent funding for anything. Business will value more a slightly buggy program that is ready in 3 months than a perfect program that only is deployed after 8.
    - KillSticky 9y ago
      > So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. This is not a sound argument to advocate dynamic languages. There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns.
      - flavio81 9y ago
        Your argument was that some IDE features are really really needed. > There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns. You are doing a strawman fallacy. I never ever spoke about having or not having code reviews, and separate testing and staging environments. All of these are also necessary, and what in the world does this has to do with static typing? Testing and staging environments are required and doable using any programming language.
Shebanator 9y ago
I agree with you about maintenance costs being more important than initial development costs, especially for large systems. But I have yet to see any real study that proves your assertion that statically typed languages have a "major advantage" in this area. Got any citations? From my personal experience, the completeness and quality of the tests has much more impact on maintainability than the static-ness of your language. But to be fair, I haven't seen a study proving this either.
agentultra 9y ago
A fun counter-example to the productivity argument we often hear from dynamic, duck-typing enthusiasts is the *Haskell vs. Ada vs. C++ vs. Awk vs. ...An Experiment in Software Prototyping Productivity∗[0] paper. The paper compares teams attempting to implement a real-world program used in a weapons targeting system. They are primarily interested in productivity and the results are quite favorable to Haskell. Of note was how rapidly a completely inexperienced programmer was able to learn Haskell and implement a solution to the exercise given the specification. [0] http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel... My own experiences learning Haskell after working Python for more than 10 years suggests this is quite plausible.

flavio81 9y ago

> Yet, in practice, the cost of maintenance often dwarfs the cost of initial development. However, funding the development is sometimes harder than funding the maintenance: You need the system to operate in the first place in order to get the benefits/money/revenue/etc. Once the system is in place and brings benefits, it is easier to fund further investment on the system, be it maintenance, extension,etc.

KillSticky 9y ago
The initial development of a chunk of code is not the same as the initial development of a shippable product. Code maintenance starts the moment you need to go back and add anything nontrivial to the existing code. And you will have to go back and change your code many times while using your initial funding. So the product funding argument, while true, does not apply here. Try reading your own code written two weeks ago. How about a month ago? Three month ago? Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you. If your team member added some more methods, they will be listed too. No need to waste time reading the function source to figure out the return type, and then waste more reading the class's source.
- flavio81 9y ago
  > Try reading your own code written two weeks ago. How about a month ago? Three month ago? In fact i did. Code of 8 months ago (december 2017). Easy to read, because i used named parameters extensively and added comments at every function Signature. Language Python (dynamic). Don't assume that all programmers can't understand their past code. All my peers (we have over 12 years doing this professionally) would do the same. It is part of our job to read code written even years before by us. You never know when a past customer (internal or external) will call you to want an enhancement or upgrade. > With a statically typed language IDE can always do that for you. So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. (Servers almost never have any kind of IDE or even fancy text editor installed). > And you will have to go back and change your code many times while using your initial funding. I am speaking about production software for using within an enterprise context. You have a defined budget and you need to ship a working product. For us , "maintenance" phase starts after the product has gone live in production. For us, if we deploy a working product, it is easy to get additional funding for maintenance and improvement. If we don't, we don't get subsequent funding for anything. Business will value more a slightly buggy program that is ready in 3 months than a perfect program that only is deployed after 8.
  - KillSticky 9y ago
    > So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. This is not a sound argument to advocate dynamic languages. There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns.
    - flavio81 9y ago
      Your argument was that some IDE features are really really needed. > There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns. You are doing a strawman fallacy. I never ever spoke about having or not having code reviews, and separate testing and staging environments. All of these are also necessary, and what in the world does this has to do with static typing? Testing and staging environments are required and doable using any programming language.

Shebanator 9y ago

I agree with you about maintenance costs being more important than initial development costs, especially for large systems. But I have yet to see any real study that proves your assertion that statically typed languages have a "major advantage" in this area. Got any citations? From my personal experience, the completeness and quality of the tests has much more impact on maintainability than the static-ness of your language. But to be fair, I haven't seen a study proving this either.

agentultra 9y ago

A fun counter-example to the productivity argument we often hear from dynamic, duck-typing enthusiasts is the *Haskell vs. Ada vs. C++ vs. Awk vs. ...An Experiment in Software Prototyping Productivity∗[0] paper. The paper compares teams attempting to implement a real-world program used in a weapons targeting system. They are primarily interested in productivity and the results are quite favorable to Haskell. Of note was how rapidly a completely inexperienced programmer was able to learn Haskell and implement a solution to the exercise given the specification. [0] http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel... My own experiences learning Haskell after working Python for more than 10 years suggests this is quite plausible.