7 ms·

I'm not convinced scripting languages are not suitable for large projects. It's said a lot, but I've never seen proof one way or the other. I suspect unmanageab

I'm not convinced scripting languages are not suitable for large projects. It's said a lot, but I've never seen proof one way or the other. I suspect unmanageable code-bases derive from uncontrollable project forces, ignorance, or not caring, but not because of the perceived short comings of a scripting language.

DoctorDabadedoo 5y ago
It's a trade off, I think. A compiled static language forces you to behave a certain way at the expense of flexibility/expressiveness, script languages are more flexible, but in a way that is easier to acquire technical debt that might be harder to move away from (IMO).
- agumonkey 5y ago
  I'm sure with time, the dynlang prototype phase -> static in production will be the norm. Gradual typing has been improving (might not be the only way but still)
  - dbrueck 5y ago
    Yes, the problem with strong static typing in many languages is that you have to make decisions about typing at exactly the worst time (at the beginning), while you almost never know up front exactly what you need. For me the ideal would be a language with the expressiveness and fast dev times of Python, and then type information would be collected from actually running the program during development and would gradually shift from auto-generated type hints to more concrete type declarations that could be enforced but that would also assist in compilation & optimization.
    - agumonkey 5y ago
      I've read people saying they do that in 70s 80s 90s.. it's probably an unavoidable phenomenon of solution space exploration. Even car makers use gradually more precise models before selling something. The type gathering from use would be nice.
    - cies 5y ago
      I find that, with a good IDE, the expressiveness of some typed langs matches that of dyn typed langs. You write a bit more code (the types) when using a typed lang, but you write a bit less tests (the stand-in for types dyn langs offer) and your IDE takes care of many of your type signatures. The fast dev times, as in quick "edit -> run -> try" loops, it what I find most attractive of the dyn langs nowadays. And gradual typing might be a way to get there, although I think it is not needed (some strong typed langs have decent hot code reload).
- Hendrikto 5y ago
  People do not seems to have any trouble producing unreadable and unmaintainable code in statically-typed compiled languages.
  - DoctorDabadedoo 5y ago
    Not at all, but having been on the "dynamically typed spaghetti code with very obscure paths/interactions and no test coverage" refactor wagon, I would take a statically typed option any day.
  - cies 5y ago
    Indeed the quality to look for is strong typed, not statically typed. Strong typed code is much easier to refactor.
    - renox 5y ago
      Unfortunately this requires some 'buy in' from the managers which means that many programs are integer/string typed instead of being strongly typed..
strenholme 5y ago
Indeed. Unmanageable code bases come from conversations like this between management and developers: “Look, we need you to implement this feature within the next 24 hours.” “Based on my scrum analysis, I need about a week to implement it.” “Sorry, if it’s not done within the next 24 hours, you will be out of a job.” “OK....” At which point, we get a hideous rush job. I have seen this happen time and time again. There is no language in the world which isn’t going to be able to force clean, manageable code under these kinds of circumstances, which alas can and do happen too often in the caffeine and work obsessed tech culture.
- cies 5y ago
  Have you coded with Haskell or Elm? Im confident that re-factoring that mess that surely comes out of the 24h sprint will be re-factorable without too much pain in these languages. Just a feeling, but coding with them feels like they are refactor-optimized langs.
  - zepto 5y ago
    If you keep having to do 24 hour sprints without refactoring it doesn’t matter.
- crispyalmond 5y ago
  I recently started working at a place which is like this, and the code really shows it. It really does not matter what language is used, it's not going to very maintainable if written so quickly.

DoctorDabadedoo 5y ago

It's a trade off, I think. A compiled static language forces you to behave a certain way at the expense of flexibility/expressiveness, script languages are more flexible, but in a way that is easier to acquire technical debt that might be harder to move away from (IMO).

agumonkey 5y ago
I'm sure with time, the dynlang prototype phase -> static in production will be the norm. Gradual typing has been improving (might not be the only way but still)
- dbrueck 5y ago
  Yes, the problem with strong static typing in many languages is that you have to make decisions about typing at exactly the worst time (at the beginning), while you almost never know up front exactly what you need. For me the ideal would be a language with the expressiveness and fast dev times of Python, and then type information would be collected from actually running the program during development and would gradually shift from auto-generated type hints to more concrete type declarations that could be enforced but that would also assist in compilation & optimization.
  - agumonkey 5y ago
    I've read people saying they do that in 70s 80s 90s.. it's probably an unavoidable phenomenon of solution space exploration. Even car makers use gradually more precise models before selling something. The type gathering from use would be nice.
  - cies 5y ago
    I find that, with a good IDE, the expressiveness of some typed langs matches that of dyn typed langs. You write a bit more code (the types) when using a typed lang, but you write a bit less tests (the stand-in for types dyn langs offer) and your IDE takes care of many of your type signatures. The fast dev times, as in quick "edit -> run -> try" loops, it what I find most attractive of the dyn langs nowadays. And gradual typing might be a way to get there, although I think it is not needed (some strong typed langs have decent hot code reload).
Hendrikto 5y ago
People do not seems to have any trouble producing unreadable and unmaintainable code in statically-typed compiled languages.
- DoctorDabadedoo 5y ago
  Not at all, but having been on the "dynamically typed spaghetti code with very obscure paths/interactions and no test coverage" refactor wagon, I would take a statically typed option any day.
- cies 5y ago
  Indeed the quality to look for is strong typed, not statically typed. Strong typed code is much easier to refactor.
  - renox 5y ago
    Unfortunately this requires some 'buy in' from the managers which means that many programs are integer/string typed instead of being strongly typed..

strenholme 5y ago

Indeed. Unmanageable code bases come from conversations like this between management and developers: “Look, we need you to implement this feature within the next 24 hours.” “Based on my scrum analysis, I need about a week to implement it.” “Sorry, if it’s not done within the next 24 hours, you will be out of a job.” “OK....” At which point, we get a hideous rush job. I have seen this happen time and time again. There is no language in the world which isn’t going to be able to force clean, manageable code under these kinds of circumstances, which alas can and do happen too often in the caffeine and work obsessed tech culture.

cies 5y ago
Have you coded with Haskell or Elm? Im confident that re-factoring that mess that surely comes out of the 24h sprint will be re-factorable without too much pain in these languages. Just a feeling, but coding with them feels like they are refactor-optimized langs.
- zepto 5y ago
  If you keep having to do 24 hour sprints without refactoring it doesn’t matter.
crispyalmond 5y ago
I recently started working at a place which is like this, and the code really shows it. It really does not matter what language is used, it's not going to very maintainable if written so quickly.