I'm thinking about writing about blog called 'Dogs Are Green.' I don't have any evidence, but it's my opinion.
Dynamic Languages are Unmaintainable
41–50 of 71 posts
Re: Dynamic Languages are Unmaintainable
#42Having written a lot of scientific code in Python, I agree (partly). The lack of static analysis is extremely irritating when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. You can often catch these with PyDev/eclipse, but not always. I try to rewrite any code which isn't fast enough in C (or C++, using a few of its "features" as possible) and wrap it up as a Py…
> when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name.
If you are writing C++, you can't hot edit and continue without re-compilation. With a scripting language and proper flow control, you can edit upon exception and resume.
Re: Dynamic Languages are Unmaintainable
#43One thing I've only come to appreciate during my professional development is that there are huge differences in the kinds of software people write and what's good in one scenario isn't necessarily good in another. A lot of people around here fall into the trap (myself included) of thinking that web programming is the entire universe of programming. That's not so, and the difference matters greatly. If you're going to…
I have done fair amount of numeric programming and I have not seen any significant benefits from type checking. For me, only these increase robustness:
1. Ability to minimize the amount of code you write. Code you don't write is code without bugs. this means either writing problem specific libraries or having them in the system (Matlab creates more robust code than writing it all by yourself)
2. ability to minimize boilerplate. This is where dynamic languages often win.
3. Ability to change code easily and test or run frequently (not necessarily unit testing). Rewriting usually makes code more robust. Time and money always runs out. Always.
The only constant law for selecting programming language for numeric programming is: IF YOU DON'T HAVE TO SPEND SIGNIFICANT TIME OPTIMIZING YOUR CODE AFTERWARDS, YOU ARE USING TOO LOW LEVEL LANGUAGE. If you don't have to optimize for speed, it means that you have been micro-optimizing your code everywhere without even noticing it. This is why C, C++ or Fortran should never be the main programming language you use. Use Python, Common Lisp, Matlab, Haskell, whatever and when you hit performance bottleneck, you write minimal amount of C or C++ code to get over it.
Re: Dynamic Languages are Unmaintainable
#44I use dynamically typed languages maybe 90% of the time, and completely agree. But here's the thing: for most projects - including ones in production - it doesn't matter because the app won't be large enough to not completely fit in a mental model. If the app starts getting too large, then by all means rewrite it in a statically typed language. If you're getting to that point, a rewrite is probably warranted anyways;…
I'd add: one way of dealing with this is to have lots of loosely coupled small systems.
Easier said than done and sometimes not an option, but it's a strategy that can work with web app types stuff. The buzzword here's probably SOA.
Re: Dynamic Languages are Unmaintainable
#45Having written a lot of scientific code in Python, I agree (partly). The lack of static analysis is extremely irritating when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. You can often catch these with PyDev/eclipse, but not always. I try to rewrite any code which isn't fast enough in C (or C++, using a few of its "features" as possible) and wrap it up as a Py…
> when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. If you are writing C++, you can't hot edit and continue without re-compilation. With a scripting language and proper flow control, you can edit upon exception and resume.
> you can't hot edit and continue without re-compilation
But with recompilation you can. watcom allowed stepping back during debugging as long as the operation was possible to revert. From there patching up the code to include a new version of the function shouldn't be that hard. Not sure if anyone's actually done it, but it's certainly not impossible.
Ksplice works similar way if I'm not mistaken to do reboot-less kernel upgrades. (patching the functions part that is, not recovering the code that's already running them)
Re: Dynamic Languages are Unmaintainable
#46I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.
(define square ((a number)) :out number (+ a 2)) This program is arguably incorrect, even though the types match up and there is no mutable state.
The program is correct, but the function name is wrong.
Re: Dynamic Languages are Unmaintainable
#47I use dynamically typed languages maybe 90% of the time, and completely agree. But here's the thing: for most projects - including ones in production - it doesn't matter because the app won't be large enough to not completely fit in a mental model. If the app starts getting too large, then by all means rewrite it in a statically typed language. If you're getting to that point, a rewrite is probably warranted anyways;…
I would also argue that you can get the benefits of a static type system with hardly any cost. Usually when people talk about dynamic vs static typing they imagine something like Ruby or Python vs Java, but there's no reason why you can't have a high-level, expressive language with static types. All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be…
Re: Dynamic Languages are Unmaintainable
#48Earlier quoted context omitted.
It's better to do the wrong thing quickly.
Eh, you'll have an annoying time putting a man on the moon with that attitude. But hey, your twitters will hockeystick better! It all depends on your problem domain--the cost of failure for certain things (pacemakers, telco software, car engine ECU code, and so on) may be much, much greater than the cost of being super retentive in your development.
Yes, it depends on the domain but outside a few industries (and low-level code) software isn't a life-or-death matter.
Infrastructure is a different kettle of fish, while it might sometimes be a life-or-death matter, generally it's just safer to seek pure robustness here: monopolies with government connections do not need to fear losing competitiveness since they can (a) manipulate the rules of the market, and (b) bind market players with contracts.
I don't like your insinuation that I'm just talking about cool hockey-stick startups; in the domains in which non life-or-death, free-market business and software colide, losing competitiveness/product-market fit is the central failure mode. And you absolutely cannot become robust against the market. You must either (1) become faster than the market, or you must (2) control the market.
Re: Dynamic Languages are Unmaintainable
#49Having written a lot of scientific code in Python, I agree (partly). The lack of static analysis is extremely irritating when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. You can often catch these with PyDev/eclipse, but not always. I try to rewrite any code which isn't fast enough in C (or C++, using a few of its "features" as possible) and wrap it up as a Py…
> when you've been running a long old calculation for 20 minutes and it chokes on a misspelled variable name. If you are writing C++, you can't hot edit and continue without re-compilation. With a scripting language and proper flow control, you can edit upon exception and resume.
I do often break into a REPL on a python exception; but I mostly use that to diagnose the problem and restart from scratch, rather than actually editing the code inside the REPL.
This is probably because I don't have the setup required to persist the changes back down to the source file, even when that source file is different from the one actually loaded (eg in my development folder rather than the installed site-packages version.)
Re: Dynamic Languages are Unmaintainable
#50I use a strongly, statically typed functional language. Because my code has no mutable state, the type system of the program proves the program correct. So I don't have to write any tests at all and maintenance is easy.
Which type system proves program correctness? A good type system can guarantee that your program doesn't suffer from certain classes of errors but that's very very far from correctness. Unless you only write programs that don't have any goal at all besides being memory safe: Behold MemSafe 2.9: it doesn't do anything at all, and most importantly, it doesn't do it in a memory safe way!
A strong type system can do more than prove memory safety. It can guarantee that their are no unhandled cases, and that data has been properly processed before going into a certain use; however it (generally) cannot guarantee correctness.
I say generally because the Haskell type system (with some extensions) is Turing complete, so you probably code implement a code prover in the type system.