4 ms·

> 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, b

> 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.

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.