Skip to main content
Software Engineering

Timeline for Why do dynamic languages make it more difficult to maintain large codebases?

Current License: CC BY-SA 3.0

23 events
when toggle format whatbylicensecomment
Sep 26, 2014 at 14:29commentadded Ark-kun @Jus12 It's a bit embarrassing. I guess, I've ultimately proven my point. Even I can no longer find it. As far as I remember, it was some typo in variable name (like "valeu") or constant (like "fasle"). In static languages this would be caught by the compiler. I think I searched GitHub/Internet for some particular typo and chose that particular code file because TikiWiki is a popular piece of software. github.com/… If you ever find it, let me know =)
Sep 25, 2014 at 4:15commentadded Jus12 @Ark-kun Out of curiosity, can you elaborate on the problem with the code you linked to?
Jul 1, 2014 at 10:16commentadded Aleksandr Panzin I disagree that the purpose of the type system is to limit expressiveness. Strictly and explicitly typed languages/systems are much more verbose than dynamic languages. Haskell is a good example of a language that is strongly typed and inferred. It is still statically typed, it's just inferred. Ruby is known to allow you to do whatever the **** you want, but that's like writing poems in gibberish which limits comprehension... and writing code that a computer can read is easy, but writing code that can be understood by a human is hard.
Apr 7, 2014 at 18:06commentadded Ark-kun @JörgWMittag BTW, can you spot the problem in this code file? svn.code.sf.net/p/tikiwiki/code/trunk/lib/ical/iCal/…
Apr 7, 2014 at 18:03commentadded Ark-kun @JörgWMittag >"So, the reason why those projects are smaller is not because ... it's because ...". No proof given.
Apr 7, 2014 at 18:01commentadded Ark-kun @JörgWMittag >"Theorems which basically tell us one thing: it is impossible to write a type checker which can always determine whether a program is type-safe or not" I don't see how those theorems prove that every type checker may fail.
Apr 7, 2014 at 17:57commentadded Ark-kun @JörgWMittag >"Ergo, without the type system you can write programs that you can't write with the type system" en.wikipedia.org/wiki/Turing_completeness
Feb 9, 2014 at 21:06commentadded Yevgeniy Brikman I'm the author of the Play Framework talk mentioned in the question. I was going to write a reply, but Eric Lippert's answer says it better than I could have, so I upvoted it instead and recommend everyone reads it. Also, remember that a "large codebase" can be "large" across multiple dimensions, including lines of code, how many people work on it simultaneously, and how long it has been around. All of these factors increase "code rot"; static typing is not a magic bullet, but rather one tool to decrease code rot.
Jan 28, 2014 at 22:24commentadded Tikhon Jelvis @JörgWMittag: It doesn't seem to have overloaded literals the way Haskell does: it just has a few nested types of numbers. For example, you can't add your own numeric types, especially if they don't fit into the existing hierarchy. I still don't see any way to do this without either having explicit annotations or using typeclasses and inference. Besides numbers, consider things like Read which also relies on typeclases. My real point is that type systems do not just reject illegal programs. With type inference, they can make programs that would be underspecified without types work.
Jan 28, 2014 at 16:03commentadded Jörg W Mittag Note: I love Scala, I love Haskell, I love powerful expressive flexible static type systems. I just don't buy the idea that you cannot program without them.
Jan 28, 2014 at 16:02commentadded Jörg W Mittag @TikhonJelvis: Ioke has overloaded literals, and is one of the most dynamic languages ever created. A type system rejects illegal programs. If the type system didn't exist, those programs would be legal. Ergo, without the type system you can write programs that you can't write with the type system, IOW you can express more programs without the type system. Now, there are things you can express in the type system itself, but then you just shift the problem around: in Haskell (with extensions) or Scala, you cannot even guarantee that compilation will eventually terminate.
Jan 27, 2014 at 21:55commentadded Tikhon Jelvis A type system can actually make a language more expressive. Consider Haskell typeclasses--they enable really useful things like overloaded literals that are difficult if not impossible to replicate in other languages.
Jan 27, 2014 at 18:39commentadded Ross Judson You present type systems as simplistic things that provide a yes/no answer -- does this program pass? A type system represents what the compiler knows about your program. In modern IDE environments, it also represents what the IDE knows about your program. Programming in the large is greatly aided by providing your tools with comprehensive models. To me your response is excessively philosophical.
Dec 19, 2013 at 9:35commentadded Daniel B Thanks, @Phoshi, that's exactly what I was after. In retrospect, it makes sense that the *lints would take on this type of responsibility.
Dec 19, 2013 at 9:23commentadded Phoshi @DanielB: What you want isn't a function of static typing per-se, but rather the static analyzer in the compiler. For compiled strongly typed languages this is required, but for dynamic strongly typed languages you could theoretically skip it. Nobody would, though. It's harder to static analyse a dynamic language, which is why they're mostly just subject to dynamic analysis, however there's no reason why this must be so. Check out pylint, for example, which professes to catch many typing errors (Though obviously not all, as it's a static analyser)
Dec 19, 2013 at 5:59commentadded Daniel B @Phoshi I understand; to elaborate on my question, let me rephrase it like this: if we assume that I want to neither exhaustively regression test a system by hand after every change, nor do I want to write exhaustive unit tests asserting the exact spelling of every field / property, is there any way to get a level of assurance similar to what a static compiler typically gives? Given that modern IDEs are getting pretty good at guessing what's going on in dynamic languages, shouldn't there be some automated assistance (even if it's a "looser" check than for statically typed languages)?
Dec 17, 2013 at 14:02commentadded Phoshi @DanielB: Depends on the language. Remember, dynamic != weak. In python, for example, "1" != 1, and if you try to use them interchangeably you'll get type errors at runtime. Mostly the closest you get is duck typing, though--if you have the wrong type and call a method, runtime exception. It's not anywhere near as robust as a proper static type system, but it's not untyped.
Dec 17, 2013 at 13:36commentadded Daniel B @Phoshi agreed, but even that joke of a type system catches many menial issues which happen day to day (especially when working with large, boring applications). I'm genuinely curious what exactly takes the place of a type system for dynamic languages, and I'm guessing Jörg has some pointers or counter-arguments.
Dec 17, 2013 at 13:29commentadded Phoshi @DanielB: I think that depends on the power of your type system. You have languages like Java that make a joke out of their types by having things like compareTo return an int. That's a function with three possible return values, and we use a data type that can represent 2^32? Insanity. Consider a language like Haskell, where the type system is in and of itself an expressive system, and you absolutely can write functions with a pretty high level of semantic checking from the type system.
Dec 17, 2013 at 12:49commentadded Daniel B Just to add to the above comment, I mean: the nature of many (medium / large) problems is such that you will need a couple of hundred entities to model it, expressive language or not. An expressive one might cut down the code by a factor of 10x or more, but it will still not be manageable without additional tooling; I'm wondering what this tooling is.
Dec 17, 2013 at 12:47commentadded Daniel B An interesting way of looking at it. Personally, I find that for large projects, type-checkers can be a life saver. They implicitly provide an extremely basic kind of unit-testing (if we can call it that - it's simply testing whether the structures agree or not). This is the kind of testing I have no time to write manually, but needs to happen when the project grows beyond what you can easily hold in your head. I suspect this happens fairly rapidly for most systems, regardless of expressiveness; how is this problem typically solved in the dynamic world?
Dec 17, 2013 at 12:38commentadded Jus12 you should also include Scala, which has awesome type inference.
Dec 17, 2013 at 11:54history answered Jörg W MittagCC BY-SA 3.0
toggle format
close