40 ms·

Are dynamic languages going to replace static languages? (2003)

• me_again 5y ago
  No. Will this article disprove the rule that whenever the headline is a question, the answer is always no? Also no.
• NtrllyIntrstd 5y ago
  Considering that it's 2021, and that more static typing in mammalian cells would have prevented some... unfortunate bugs, I would say no.
  • NtrllyIntrstd 5y ago
    * Sorry, of course I meant ProteinConstructionProviderFactorySingleton
    • ankurdhama 5y ago
      Factory or Singleton or whatever patterns have nothing to do with static typing.
      • NtrllyIntrstd 5y ago
        That was meant as an unrelated jab at Java/OOP (y'know because Uncle Bob). Can't name it cell as that would be too obvious ;)
  • etaioinshrdlu 5y ago
    We don't need static typing, we need code signing. Or at least removing the biological equivalent of auto-running code on CD's inserted into a Windows 98 machine.
    • NtrllyIntrstd 5y ago
      I don't seem to follow you 100%. Are you referring to biology or to software? In a biological sense I can't really see how a trusted platform would work. And even then it wouldn't protect against internal malicious code? I was simply referring to turning Cell :: tRNA -> Protein into Cell :: HumantRNA -> Protein :) And on a software perspective trust isn't really the issue here. Trusted buggy code is still buggy code.
  • nlitened 5y ago
    Yet statically typed biological systems are yet to be ever seen to evolve into existence :)
    • NtrllyIntrstd 5y ago
      Well, we need to give good ol' evolution a bit of slack here, considering that it's not intelligently designed ;)
• lakecresva 5y ago
  Hey look, another thing Uncle Bob was completely wrong about. It's telling that after using "we" to set up the initial question, literally every pronoun in the article where he waxes on about testing is a personal pronoun. He never mentions "...And my colleagues found it easier to understand my code", or "and people found my library more inviting".
  • neolog 5y ago
    Wrong? The most popular languages are Javascript and Python...
    • sarnowski 5y ago
      By which metric? TIOBE paints a different picture where also Python and JS are high but not exclusively. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
      • deleted 5y ago
        [deleted]
      • TJSomething 5y ago
        As TIOBE uses averaged, relative search engine hits for "[programming language name] programming" as its source, it's a significantly lagging indicator, since it counts all pages on the internet equally, regardless of their age. I'm also unsure of the precision of the search "C programming". I suspect that it's catching "C++" in some search engines. Stack Overflow's annual survey puts JavaScript, SQL, and Python at the top, with C at 12th [0]. RedMonk's Top 20 puts JavaScript, Python, and Java at the top, with C in 10th [1]. ITJobsWatch puts JavaScript, SQL, and C# at top, with C at 9th [2]. Dice puts SQL, Java, and Python as its top 3, with C not even ranking in their top 12 [3]. All of those put JavaScript, Java, and Python in the top 5. [0] https://insights.stackoverflow.com/survey/2021#most-popular-technologies-language https://insights.stackoverflow.com/survey/2021#most-popular-... [1] https://redmonk.com/kfitzpatrick/2021/03/02/redmonk-top-20-languages-over-time-january-2021/ https://redmonk.com/kfitzpatrick/2021/03/02/redmonk-top-20-l... [2] https://www.itjobswatch.co.uk/default.aspx?ql=&ll=&id=900&p=6&e=5&page=1&sortby=12&orderby=0 https://www.itjobswatch.co.uk/default.aspx?ql=&ll=&id=900&p=... [3] https://insights.dice.com/2021/01/05/top-12-programming-languages-employers-want-early-2021/ https://insights.dice.com/2021/01/05/top-12-programming-lang...
• frhack 5y ago
  According to Erik Meijer TDD is not the way at all. https://youtu.be/2u0sNRO-QKQ https://youtu.be/2u0sNRO-QKQ
• Epenthesis 5y ago
  He was right in a sense, the 00s and 10s were the era of the dynamic languages. In momentum if never quite in absolute usage. But my sense is that we're gradually swinging back around to static typing via gradual typing + mainstreaming of ML style features like generics, unions, records that are more expressive than the C/Java model.
  • zumu 5y ago
    Dynamic languages compare well against languages with poor 'static' type systems imho. In both paradigms, null is still the biggest source of pain. In part, I think the move to mainstream more ML features is to finally try and address this.
  • socialdemocrat 5y ago
    I think instead you see both dynamic and static languages borrowing ideas from each other. I don’t think it is without reason Go is succeeding. It makes it feel a lot like writing a dynamic language in a statically typed one. Meanwhile Julia gives dynamic languages some of the same feel as static ones. Both dynamic and static languages have benefits, so I don’t find it weird that they borrow from each other. Personally I prefer opting in to use static type checking over opting out.
    • skohan 5y ago
      Don't you lose a lot of the benefits of static type checking if you don't use it systemically?
      • zozbot234 5y ago
        Not quite. The main problem with gradual typing is performance, because having to do checking and conversion at every boundary or interaction between static- and dynamic-typed code introduces a lot of overhead.
      • DougBTX 5y ago
        Julia strikes a nice middle ground. Functions which don't specify the types of their arguments are implicitly generic, and are JIT compiled when called based on what the actual argument types are. So even if a function doesn't have types specified, if it is called with arguments with incorrect types, then there will be a compile error at a level further down if there's no implementation available for nested function calls. The error messages are not as nice as if the types were specified at the top level, but there's usually still enough static type checking to know whether the code will run or not before it runs, which is one of the big benefits of static type checking. The other benefit of static types is performance due to compile time optimisations, which Julia can benefit from if the functions are type-stable.
• kgeist 5y ago
  There's now a trend to add gradual typing and type hints to dynamic languages, while at the same time, "static" languages are incorporating ideas from dynamic languages. So the end result is a symbiosis, not opposition.
  • dade 5y ago
    > "static" languages are incorporating ideas from dynamic languages. So the end result is a symbiosis, not opposition. If I may ask, what ideas are static languages incorporating from dynamic languages? Could you help clarify?
    • dbt00 5y ago
      Go's interfaces are a great example.
      • wizhi 5y ago
        What makes Go's interfaces dynamic in nature?
        • zmmmmm 5y ago
          they are "duck typed" .... so an object automatically implements an interface if it has methods with the right signatures to satisfy the interface. It's handy if you need to add interfaces onto code you don't control (say, library code) as you can avoid a whole layer of adapter types / functions that you need in true statically typed languages. But I'm curious if its a great idea in the long run to have interfaces being "accidentally" implemented by objects. Doesn't seem like it would stand up well to refactoring or various other scenarios.
          • kaba0 5y ago
            Than it’s the age-old war between nominal and structural typing. The latter can be really comfortable and productive, but as you note, it may be less safe (eg. just because I have a next method doesn’t mean I want to make it an iterable or something like that. It can easily break class invariants)
• abhinav22 5y ago
  Static typing is generally a good thing…I thought this was common sense. Abstractions are very powerful, but when many people work on a codebase, keeping extra checks via static typing imo is good. Unless your Dev team is _highly_ experienced, then you can put away with the training wheels
  • alpaca128 5y ago
    Static types aren't training wheels, though. They're seatbelts. Without it the same type checks still have to be done, but this time by humans. And experience doesn't make them much more reliable at manually doing tedious checks.
    • yxhuvud 5y ago
      Static types can also be a straitjacket. Type systems have improved greatly over time though, so the balance is shifting. The world is not stuck at the point in time (2003) when the article was written, and type systems in general use have improved a lot with both more flexibility, protective power and less bloat.
    • go_elmo 5y ago
      It is just a part of automation to have a static type system, instead of having to do it manually which is the worst task for humans (tedious and error prone). Everyone having to use some python code consisting out of 4 half-baked libraries can confirm - it is a nightmare, at least for me!
    • diragon 5y ago
      >Without it the same type checks still have to be done, but this time by humans. Nah, they don't have to be done. Most programmers using dynamic languages just don't think about types until they need to be thought. That implies there's more resources/energy available to think about the actual problem, which often has almost nothing to do with types. Then if you're using something like Common Lisp/SBCL, you can define the types afterwards where they are most critical. Doing all this well in a dynamic language requires more discipline obviously, since you cannot even release software in a stricter static language if it fails to pass the type checking phase. But it is faster, sometimes significantly faster. Sometimes it may even happen that the coder could not have finished the task in a stricter language, which would imply that the the dynamic language was infinitely faster.
• cjfd 5y ago
  I would say it is best to do both TDD and have a statically typed language with explicit types written down for every variable. The latter mainly for readability. Let us look for a minute at how mathematicians write things. It is like 'let n be a natural number, let f be a function from the reals to the reals and so on...'. It would be very inconvenient if they wrote things like 'let us have some symbols n and f and you will now have to read the rest of the text to try to figure out what they are....'. It is quite telling that in python it now became customary to include a kind of docstrings to document every parameter. However, no automated process is checking these so they may not be true. So then we start using mypy and, voila, there we are again with static type annotations for every parameter. The whole dynamic language thing was just a detour that did not make anything better. They saved the author a few seconds at the cost of the person trying to read the code taking a few minutes to find out what the type of the parameter was. I also think one should use the 'auto' keyword in C++ quite sparingly.
  • rerx 5y ago
    The auto keyword in C++ is great because it helps you avoid unintended type conversions in assignments. For that reason it should be used widely IMHO. The downside is that it makes it slightly harder to read code outside of an IDE.
    • ComputerGuru 5y ago
      > The downside is that it makes it slightly harder to read code outside of an IDE. If that’s how you feel about auto, wait until you see something like rust’s post-facto type inference.
  • alpaca128 5y ago
    > let us have some symbols n and f and you will now have to read the rest of the text to try to figure out what they are... This point is mostly relevant for mathematics. When you define a variable in a program the reader can easily infer the type by the value it was initialised with. Sure, if you just see "10" you don't know if it's a byte or a long int, but that doesn't matter because only the compiler needs to infer those details. For reading the code it's enough to know it's an integer. I agree about complex types, though. In Python and pure JS it gets really complicated when you have to find out about a dictionary's/object's fields by looking at code inserting them one by one.
• continuational 5y ago
  Regardless of his experience in software development, if his opinion is informed by the type systems of C, C++ and Java, then it must be considered the opinion of a novice when it comes to type systems.
  • yxhuvud 5y ago
    Did you realize the article was written in 2003? Sure, SML , Haskell and some other somewhat powerful type systems did exist at that point, but they were limited to academia and pretty much not used at all outside that.
    • carlmr 5y ago
      That may be true, but it would also mean it's not worth reading an article from 2003 about this topic anymore.
    • fulafel 5y ago
      Also OCaml (1996).
• galaxyLogic 5y ago
  The suggestion here is that unit-tests make type-systems less needed. One could also make the opposite and not contradictory point that type-systems make unit-tests less needed. They both help
  • nodejs_rulez_1 5y ago
    If unit tests are not that needed then you cannot sell TDD courses as easily.
• jpxw 5y ago
  At $WORK I use a dynamically typed language at least 75% of the time. I often wonder how much time (== money) I waste debugging existing code which has a logic error that would have been caught by any type system, or trying to piece together the type of some variable when writing new code. I expect it’s significant.
  • Lapsa 5y ago
    get good
• Zababa 5y ago
  Java, Python, Ruby, Smalltalk, C, C++. That seems like a really small world for someone that calls himself a "craftsman". How about doing a bit of Haskell or SML to see what a static type system can be? > I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler. Isn't he mixing static and compiled languages here? I'm also not convinced at all that dynamically typed code is easier to change. Easier to write maybe, but I thought his whole thing was that writing is the easy part and after that software rots and you have to change it. Edit: > I thought an experiment was in order. So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. I don't think understanding code you just wrote and not having issues in it is a great experiment with a lot of meaning.
  • skohan 5y ago
    > There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler. Yeah this is something I take huge issue with. There's always a tradeoff: less comptime issues means more runtime issues. Comptime issues are predictable and deterministic. Runtime issues may depend on inputs, or external factors like memory constraints, so they're way harder to identify and solve. Static types are like eating your vegetables. You might get more instant gratification from eating cakes, but it's going to come back to bite you later.
    • Zababa 5y ago
      What I find really weird is that he's advocating for tests everywhere. Tests are just another build time measure.
      • skohan 5y ago
        Yes and more labor-intensive and error prone than just using a type checker
• aitchnyu 5y ago
  My wish is a language that lets you instantly run changes but build enforcing static types. For example, if I change the signature of a function, I can update one url that uses it and instantly see the changes, and the language/tooling tells me there are 4 places where the code broke. I guess Python or JS will be the first to reach this goal.
  • slmjkdbtl 5y ago
    It sounds like a dynamic language + optional external static analysis tool which exists in a lot of languages as third party softwares, like typescript / flow.
  • native_samples 5y ago
    Actually it already exists. You can do that with any bytecode-targeting JVM language. For a compiler that can compile even with errors in the code, look at ECJ. If you take HotSpot and attach a debugger in your IDE, then you have some hotswap capabilities [1]. You can redefine the contents of methods, add methods and add classes (e.g. lambdas). This is OK as far as it goes. But this is no inherent limitation of Java. In fact the debugger protocol lets you request arbitrary changes, it's just not all JVMs support them. One that does is called DCEVM [2]. It fleshes out the hotswap capabilities far more extensively and lets you do things like delete methods, change prototypes, alter the inheritance hierarchies etc, all on the fly whilst the app is loaded and running. DCEVM is an open source patchset onto HotSpot, but it's not really a pro level tool. JRebel [3] is a company that makes hotswap tools as a commercial product. Many companies use it. These are a neat capabilities and I've used them a few times, but even with that level of power, it's not always complete for every use case. The problem is that most apps have initialized state. Web servers often do not, because they throw away state at the end of every request, and there it works better, but if you're working on e.g. a GUI or a CLI tool with a shell, or really anything where the program has to maintain state for longer than a split second, changing code becomes of more limited use because you are going to end up changing initialization code that won't re-run. You can add various ad-hoc hooks to your app to let you force re-init whilst running, but it's not totally smooth. Note: this isn't a limitation of the language or runtime. It's inherent to the concept of hotswapping code. There is work to resolve even this problem. The Espresso JVM has full hotswap support, and a callback interface that lets the app learn when its own code is being redefined. It can use those callbacks to trigger re-initialization of any state that's required. [4] Espresso is still new but this sort of thing lights the way to apps that perhaps never need to be shut down at all, not even for upgrades. [1] https://www.jetbrains.com/help/idea/altering-the-program-s-execution-flow.html#reload_classes https://www.jetbrains.com/help/idea/altering-the-program-s-e... [2] http://dcevm.github.io/ http://dcevm.github.io/ [3] https://www.jrebel.com/products/jrebel https://www.jrebel.com/products/jrebel [4] https://www.graalvm.org/reference-manual/java-on-truffle/hotswap-plugin/ https://www.graalvm.org/reference-manual/java-on-truffle/hot...
• Animats 5y ago
  Two decades later, we have a more of a handle on what needs to be dynamic, and what doesn't. Too much dynamism is a headache for both debugging and for the language implementation. In Python, you can, if you work at it, find a variable in some other process by name, and store into it from another thread. While this is unlikely, you cannot definitively tell at compile time it won't happen. This prevents most compiler optimizations.
  • da39a3ee 5y ago
    You meant "other thread" rather than "other process", right? But that doesn't take much work at all -- just a mutable data structure as a global variable.
    • Animats 5y ago
      "Other thread", yes. The point, though, is that basic optimizations, like hoisting some computation out of a loop, are off the table in Python, because the compiler can't be sure something won't mess with the innards of the loop at run time. Yes, you can do awful things involving creating an optimized loop, detecting at run time that someone broke it from the outside, and switching from compiled to interpreted mode. I think PyPy does stuff like that. It's a huge effort in the compiler and in the runtime to handle such cases. It's also part of why Python sucks at threading, with the Global Interpreter Lock. There's not enough separation between threads.
      • da39a3ee 5y ago
        Ruby has a GIL too, as far as I understand. Is the GIL in Ruby comparable to that in Python and present for similar reasons? If so, does that suggest that it's a genuine design constraint rather than a bad design decision? You don't say so explicitly, but your last sentence sounds like it's saying Python's GIL is due to bad design.
• coldtea 5y ago
  Yes, in about a decade, in the next fad cycle. Then it's back to static languages again and so on.
• ardit33 5y ago
  Didn't happen, but they became more popular. The fact is, that dynamic languages are great for small personal projects, or modular scripts, but if your projects grow more than 10k Loc, and you have 2+ devs working on it, dynamic typing becomes a major liability. The raise of unit testing in the early 2003-2006, coincided with the raise of popularity of the Python web frameworks and Ruby on Rails. Suddenly Unit testing became a necessity, while previously it was a 'nice to have', as static typing covered a lot of the errors that dynamic languages introduced. Before 2005, in most places, 'integration testing' was the norm, but not unit testing. In the other hand, Objective-C took a very interesting turn, where it is a static typed language, but it is message oriented, and you can use it in a semi dynamic typing way. You can send a message (method call) to any object, which allows for interesting compositions (eg. [(id)myObject anyMethod] ). Calling a method on a nil object, doesn't raise exceptions, etc... I thought it made an awesome compromise. Unfortunately, Swift went the opposite way, which I didn't think was the right call. (as Java already covered that area well). Hence Swift hasn't taken off, appart from iOS as it didn't really introduce anything new, just little soup of paradigms that don't fundamentally make things much better. It was a missed opportunity.
  • socialdemocrat 5y ago
    Size isn’t really a problem for dynamic languages. There has been extensive tests of this. Huge Erlang projects of 1.5 million lines of code have been developed faster and with fewer bugs than comparable systems using statically typed languages like C++. I think size becomes a problem when you don’t properly modularize and test. Also I think often it is more about the specific language in use rather than dynamic vs static typing. I would rather use Go than JavaScript. But I would use Julia over almost anything else when possible.
  • arcturus17 5y ago
    Youtube, Github, Shopify or PornHub are all written in dynamic languages, but here is an anonymous expert telling us how they’re a liability in projects with 10k LOC and 2 devs. The theory that unit tests started happening around the rise of Python and Ruby is vague, unsubstantiated and intellectually lazy. I actually remember the rise of TDD being intimately related to the enterprise world and Java but I’m certainly not going to pass that as scientific fact.
• seanwilson 5y ago
  > I can no longer concieve of writing software without using test driven development. I can't imagine not having a comprehensive suite of unit tests to back up my development. I'm the same with strong static typing. At its most basic, why would I give up getting the computer to automatically check for me at compile time that I'm passing the right number of parameters to a function, that a parameter is an array and not a string, a field can never be null, and that I haven't made a typo in a variable name? Coding without these trivial checks of correctness feels archaic and backwards to me. To make up for it in a dynamic language, you end up having to reimplement what a type checker would do for you with no guarantee you didn't miss something or make a mistake, with the added cost of e.g. polluting your projects with noisy defensive code that double checks the types of parameters, adding extra tests, and bolting on linting, analysis and IDE tools to help. I'm with the other posters too about the article content, if you haven't coded in a language like OCaml, Haskell, ML etc. you really don't know enough about what strong static types offer to discount them. Java, C and C++ have much weaker checks of correctness and lack type inference + pattern matching that make strong types pleasant to work with. The article says more about e.g. Java vs Python. You want strong static types + tests, they're not mutually exclusive at all but complementary.
  • capableweb 5y ago
    > if you haven't coded in a language like OCaml, Haskell, ML etc Same argument could be made the other way, if you haven't used Smalltalk, Clojure (and other languages that are strongly dynamic), you shouldn't discount them.
    • DaiPlusPlus 5y ago
      > strongly dynamic Que?
      • enricozb 5y ago
        class A(random.choice([B, C]): ...
        • 5y ago
• d3nj4l 5y ago
  Funnily enough, Uncle Bob's latest obsession is Clojure, so you can say for sure he's on the dynamic train now.
  • Zababa 5y ago
    Considering his strongest argument for Clojure seems to be "economy of expression" [1], I think it's time to stop following what he things. For someone that spent a lot of his career talking about rotting code, how to adapt to change, things like that; his only argument being "it's faster to write" feels really weak. [1]: https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure....
    • capableweb 5y ago
      You seem to misunderstand the argument he makes in that post. > It is just simpler, and easier, and less occluding to write expressive code in Clojure. It requires fewer lines. It require fewer characters. It require fewer hours. It requires fewer mental gymnastics. This paragraph is not only about "faster to write". It's about faster to understand, easier to maintain (less code to understand), easier to change and a lot more. I urge you to re-read the post again and think about what's being written, > I think it's time to stop following what he things. I think this is true for many "leaders" in programming. We should never follow people because they are (self-described/community-described) as "thought leaders", it simply leads to too much cargo culting. You see this in Clojure, VueJS and so many other ecosystems. Ideas are good if they are good ideas, not good because of who said them.
      • Zababa 5y ago
        At not point he mention that the code is faster to read or understand though, just that it's easier to write "expressive code", whatever that means. He also lies a bit by saying "You’ve just seen 80% or so of the syntax of Clojure.": https://clojure.org/guides/weird_characters https://clojure.org/guides/weird_characters. > Ideas are good if they are good ideas, not good because of who said them. You're right about that, I always insist a bit more with Robert Martin because there is a lot of cargo culting around what he says. Clean code and TDD are other good examples of that.
• dgb23 5y ago
  Here is what I think about this. I write "we" as in us as programmers. YMMV. 1. The type system is not the only consideration, nor is it the most important one for most cases. 2. Language choice often boils down to cultural things: what is already written, who can write it already, the lowest common denominator. This is not always a good thing, but often it is necessary. 3. The tools we use shape the way we think. 4. Tools should be invisible, like an extension of ourselves. 5. Static vs. Dynamic is a false dichotomy. There is a gradualism to it and it includes more than typing. 6. Constraints are important, because they facilitate engineering, confidence and systems thinking. 7. Interactivity is powerful, because it facilitates understanding, expression and domain thinking. 8. There are cases where either of these things are more beneficial. 9. Some languages are half-assing either of those to be more familiar. 10. We should give ourselves more credit to be able to use the right tool for the job.
• 0dayz 5y ago
  What i remember back in the day was that the advocates for dynamic languages were certain that everyone would write in dynamic languages because we would had all the most optimized implementation and not having to do it by hand.
• rzwitserloot 5y ago
  > But now, as we all gradually adopt Test Driven Development Snorted out loud at that one. This post seems to assign value to static typing: That it aids in avoiding bugs. It then makes the case that TDD will do a much better job at it, and thus, obsoletes the need for this (having 2 systems would be redundant!). The problem is, that's just one of the many things static typing does. static typing also deals with the general problem of discoverability: When I'm writing code, how do I know which features and functions are available, right now? "Just read a ton of docs and be a walking dictionary of API calls" is a really bad answer to the question. So is: "Welp, re-read the intro page of the docs over and over". A much better answer would be: Well, at the touch of a single keyboard shortcut, or even 'as you type', you get a curated list of the most likely things you'd want to do right now so you can just eyeball that as you program. static typing makes that way, way easier to do vs. dynamic. But, I think even as far back as 2003, Bob "TDD!" Martin was already reframing all coding issues in terms of TDD so this isn't exactly surprising.
  • Lapsa 5y ago
    Discoverability is really important if you live in Microsoft world with its documentation and API quality.
• p0nce 5y ago
  Static types are small-time unittests so no.
• dragonwriter 5y ago
  > Are dynamic languages going to replace static languages? (2003) No, dynamic and static languages are going to merge, coming at optional, selective static typing via opt-in static typecheckers on the dynamic side and opt-outs via dynamic escape hatches and/or use of broad (e.g., Any) types from the static side.
  • Lichtso 5y ago
    This. I don't get why most think they have to be either/or and are exclusive. Both have their advantages and disadvantages as devotees of both sides can attest. So why not let the programmer choose on a case basis with a project wide default policy.
• w_t_payne 5y ago
  Both dynamic languages and static languages have their place. Personally, I'm a big fan of an iterative refinement process where an algorithm prototype in a dynamic language is gradually transformed into a production implementation in a typed, fast static language.
• de_keyboard 5y ago
  I think ultimately static languages will win because: - Most things you want to express can be expressed in a static language - Tooling is much easier to build over static languages, and I think automated checkers are the future of rapid development of robust programs I don't think that OOP languages as they are now (particularly Java 8) are the future, but something with less ceremony like an ML. Java and C# might flourish in the long term by becoming ML languages, but only if they are prepared to remove the cruft.
  • Lapsa 5y ago
    > - Most things you want to express can be expressed in a static language wtf argument
• butterisgood 5y ago
  No
• Lapsa 5y ago
  > Life in a dynamically typed world is fundamentally simpler. Amen.
  • bbrree66 5y ago
    This is the exact opposite of what is true in the real world.
• Sunscratch 5y ago
  While it is very fun to hack using dynamically typed languages, it’s obvious that they are not suitable for large enterprise systems. Refactoring, code navigation, code reading is much much more better with statically typed languages. Moreover, modern ST languages like Scala have a “feel of” DT languages due to type inference, without compromising static type checking
• StevePerkins 5y ago
  I never understand these "dynamic vs. static" threads. All of the comments saying that types are somehow undesirable. Or trying to appear wise and above it all with some variant of the middle-ground fallacy. The advantages of a dynamic type system are two-fold: 1. Dynamic typing and a meta-object protocol allow for certain design patterns. Arguably makes it a bit easier to write DSL's. 2. You don't have to spend 500 milliseconds typing the word `string` or `int`. However, in reality: 1. Virtually no one in these threads are actually writing DSL's, or applying any of those design patterns. They're writing line-of-business CRUD apps, and simply don't feel like reading or typing `string` or `int`. 2. Most static languages are getting more sophisticated with type inference, such that you don't have to type `string` or `int` nearly as often (although we can debate whether this actually makes your code more readable or less). So in sum, most people aren't even getting much if any purported advantage, and in exchange they are giving up a slew of compile-time checks that must instead be manually implemented in (unreliable) tests. It's just madness. You don't want to type `string` or `int`. It really is as simple as that.
  • jiggawatts 5y ago
    > You don't want to type `string` or `int`. It really is as simple as that. I prefer to write "string" or "int", but it can be borderline impossible to write the type of a complex query, the kind of thing returned by LINQ or the like. What's the type of a class or struct that has fifty non-optional (not null) fields of various types? Easy! It's just the name of the class or struct. What's the name of the same class after applying the "select" or "project" operator, with one of the fifty or so fields removed? Umm... Okay, next: How about the name of the type that is a projection that removes one arbitrary column based on a dynamic, runtime input? Can your static language express this at all? This is the most basic query operation possible, affecting one column or field, and your fancy static typing has fallen flat on its face. This is not about typing speed. It's about solving trivial problems with fit-for-purpose tools instead of fighting the compiler. This is why SQL is still a thing, and why a lot of people massage data with Python or R instead of C++.
    • throwaway889900 5y ago
• mmarq 5y ago
  No.
• Guid_NewGuid 5y ago
  I have tried to keep an open mind on this topic, or rather developing one, but alas I remain a zealot. I recently wanted to make a simple enough PR to a large JavaScript codebase to fix a bug. After a few hours I found where the call was happening and what changes I needed to make. At a simple level the code update was "measure the length of each of these things and store them, for each of the stored things align them relative to the longest length of stored items and add them to the state". It took about 3 times longer to get to working code because of the lack of types. "Oh, you've used `i` in some context, you must just mean a global of indeterminate type, better keep running. Oh you forgot whether the method name on type of string is SubString or Substring? Sorry can't help you, don't know what a string is. You don't know/remember what you can do with this variable? Neither do I!" Sure you can have linters or whatever to catch these stupid mistakes but I'd rather just have the bloody thing work first time. I'd rather have my tools assist me than feel like an alpha-chad because I've managed to memorise the entire API of something. I have more useful things to keep in my brain. Sure it might let you go quickly in your 50 line script but woe-betide any developer who comes later.
• api 5y ago
  Dynamic languages create technical debt. They allow fast development up front at the price of more bugs later as the code "rots" and more resource consumption later as you scale (for server-side stuff) or as your application is used more heavily (for things you distribute). More resource consumption in the cloud means higher cloud bills, and more resource consumption locally means your app is "slow" and users don't like it. My experience with dynamic language rot is that a single developer or a small team can create a clean bug-free dynamic application but as soon as you start adding features, refactoring, or adding developers you get all kinds of runtime-only bugs that creep in. Older unsafe static languages like C and C++ have the same problem to a lesser degree in that the compiler will catch egregious type bugs but things like memory errors, type conversion gotchas, etc. will creep in over time unless you have some really diligent testing and auditing in place. Dynamic languages are suitable for prototyping, glue, and throwaway code, which is why we used to call them scripting languages. I do have to add though that today's best static languages like Go and Rust are vastly superior to 1990s-2000s era C or the carpal tunnel inducing "enterprise" nightmare that Java became. Even C++ has improved if you use more modern constructions like lambdas, and nearly all languages have better libraries and better ecosystems than they did back then.
• butterisgood 5y ago
  How do unit tests prevent one from committing type errors in the "product" code? All it does is show you that you know how to write test code that doesn't supply the wrong inputs to functions. I'm not shipping the tests. The fact that they work is very nice, and it can prove that the code under test is working, not that all attempts to use the code in something larger aren't broken. So all that's left in this article is that dynamic languages make for easier to refactor code. That might be true, but it doesn't have to be so bad in practice when you keep your interfaces very small and focused.
• ragnese 5y ago
  They almost did, and I mostly blame Java. Java's type system is so poor that you go through all this ceremony of declaring types (and remember that Java didn't even always have `var` and `<>` inference shortcuts), and you still inevitably had a bunch of runtime type bugs because of its obscene handling of null and its type-erased generics (and maybe even its intentionally-incorrect array type variance). Its type system was so lame that it gave rise to most of the "Gang of Four" patterns, most of which are just workarounds for Java- not some first order principles of programming. So you had these awkward and verbose "patterns" and polymorphism and naming a bazillion new types that were almost the same as each other, and STILL had runtime type errors and crashes. What's the point? It's no wonder at all that every desktop app I installed on my Linux machine in 2008 was written in Python. It's no wonder someone thought it was actually a good idea to run *JavaScript*, of all things, on the backend *and* the desktop. Holy crap- how bad do statically-typed languages have to be to make people want JavaScript?! (I'll tell you: they have to be Java and C++98 bad- that's how bad.) Thank goodness for Swift, Rust, Go, etc in the post-2010 world. For the last few years people are looking down their noses at dynamically typed languages, but I think statically-typed languages almost died thanks to Java and C++.
  • btmcnellis 5y ago
    > Its type system was so lame that it gave rise to most of the "Gang of Four" patterns, most of which are just workarounds for Java- not some first order principles of programming. Java wasn't released until after the first edition of Gang of Four. C++ is probably what you should be pointing the finger at.
    • ragnese 5y ago
      Totally right, I apologize. I think my point still stands if we replace Java with C++ (and I still think Java was worse than C++ for static typing's reputation).
      • michaelnik 5y ago
        Gosling designed Java with a C/C++-style syntax that system and application programmers would find familiar. [https://en.wikipedia.org/wiki/Java_(programming_language) https://en.wikipedia.org/wiki/Java_(programming_language)]
• slifin 5y ago
  For me they did C# -> PHP -> F# -> ReasonML -> Clojure(Script) Clojure programs have a pulse a spark of life that I can mold at runtime with a bit of static analysis via clj-kondo it's a crazy productive creation environment
• teddyh 5y ago
  The arguments for typed languages seems to often take a motte-and-bailey form: The easily-defendable “motte” form being similar to “You always need to know if the thing you got was a string or a complex object.” which, when agreed to, becomes the “bailey” form: “Now that we have agreed that types are always good, please declare for every single numeric variable what width of integer they should use, and if they are signed or not. It’s the only way. You don’t want to return to the ways of chaos, do you?” I am not entirely convinced of the validity of the latter argument.
• nradov 5y ago
  It would be nice to have a language with a scalable type system. Allow dynamic typing for quick prototyping and exploratory programming, then layer on static typing as needed for performance and reliability. For example start by declaring a variable, which could be anything. Then constrain it to be a number. Then a floating point number. Then a floating point number in the range [0.0, 1.0). And please optimize for performance instead of precision. Etc.
  • reader_mode 5y ago
    TypScript is sort of this. It's the best of both worlds, if it wasn't built on top of JS legacy garbage type system and core types it would be ideal. But a powerful structural type system built on a flexible object model is really a great mix - type as much as you need, ignore types when they get in the way.
  • dunefox 5y ago
    Sounds like Racket with Typed Racket.
  • deleted 5y ago
    [deleted]
• tech_tuna 5y ago
  100% nope. I've been coding for more than 2 decades. Like everyone else, I have my favorite languages and tools. I don't like "messy" languages and I'll just keep this going into flamewar territory and not say what I consider messy. :) I have used dynamic languages a lot and I enjoy them in many ways, especially Python. But I've been using Go for a few years now and I'm hooked. For me, Go is pleasant enough that I don't mind its warts and I loooove the compile time checking. It has some other great features, tooling-wise as well. I still love Python and I will continue to use it for the foreseeable future but I prefer Go when I have the option. If anything, Go has sort of rekindled my appreciation for static typing. I'm kind of hunting for a reason to learn Rust sometime soon. Runtime is funtime with dynamic languages and I'm kind of burnt out on that. :)
• magwa101 5y ago
  If your unit tests are checking types explicitly, or implicitly you are writing a compiler over and over and over...
• bhaavan 5y ago
  boolean answer = No;
• Chris2048 5y ago
  I think this argument is at the wrong level. Dynamic langs can be static (but without the guarantee that it always will be), static languages can be dynamic but with difficulties. If guarantees are the issue, standards, language features/structure and constraints are the crux. Take a dynamic language, and explicitly label what is dynamic, and what is static, and you can restore static guarantees, while still having dynamic features if need be. Hybrid langs, with better reflectivity will win - you can have "both". That said, software development models that don't trust their devs are always going to choose locked down languages, and claim this is the only "viable" way - much like those companies that claiming they cannot seem to hire employees, but don't mention "at the price we want".
• igouy 5y ago
  > I can no longer concieve of writing software without using test driven development. But apparently writes without testing the writing. > I can no longer conceive of… https://yourlogicalfallacyis.com/personal-incredulity https://yourlogicalfallacyis.com/personal-incredulity
• arvindrajnaidu 5y ago
  Static Type Checking is a test. Only difference is it looks nothing like your regular tests.
  • igouy 5y ago
    The difference is that type check shows a property is universally ∀ true across all of the code, while a run time test shows a property is ∃ true in this one part of the code.
• arduinomancer 5y ago
  I'm curious if other people have the same experience but I find if I write something complex in Python/JavaScript the majority of the time it does not work the first time I run it. Whereas with Java majority of the time things work first try because any trivial type issue have been sorted already by the compiler.
• iainctduncan 5y ago
  Are nails going to replace screws? No. And neither will screws replace nails.
• austern 5y ago
  It's interesting to note that this blog post was written in 2003, and that a lot of the arguments we've seen in this thread, both for and against dynamically typed languages, are exactly the same arguments people might have used back then. One question to ask is whether there's anything we know today about this question that we didn't already know 20 years ago. My suggested answers: 1. We now know, 20 years later, that dynamic-typing languages have not replaced static-typing languages. All of the languages from that '03 blog post are still heavily used. If we look at more recently introduced languages, some are statically typed and some are dynamically typed. Evidently programmers still see value in both of those ideas, and neither looks like it's replacing the other. 2. We now know that it's possible to add type deduction to statically typed languages and type annotation to dynamically typed languages, even older languages like C++ and Java and Python.