1. 33
  1.  

  2. 7

    Great article; it’s rare to see the debate framed clearly with respect for both sides.

    However, I’m not sure I agree with his assessment of the terms “strongly typed” and “weakly typed”. Maybe it’s just the circles I hang out in, but I feel like there’s a pretty widespread agreement that “weakly typed” means a system like Javascript, Forth, or Perl, where operations like trying to add a function to an integer will try to produce a result rather than throw an exception no matter how nonsensical their inputs are.

    I suppose one counter to that would be to say that such a distinction usually happens on a per-operation basis; that is, even a supposedly “weakly typed” language would still have some operations for which it would signal a type errors, and thus “strong” and “weak” don’t describe properties of the type system as a whole? I don’t think that means they’re meaningless terms though.

    1. 3

      I tend to agree with the article’s notion, though I think it shows up more evidently in static typing camps. There’s roughly an expressive order like C < Java < { Scala, Haskell, ML } < Coq < HoTT which often takes undue weight since { Dynamically Typed Languages } goes at the bottom of that scale.

      I think the divide you bring up is interesting, though. I’d like to use a phrase like “exceptional languages” to refer to “strong, dynamic” in this notation since they have the property of changing program flow to avoid runtime-discovered type errors while javascript/forth/perl do not.

      1. 1

        Yeah, I think it’s a useful distinction, and it sounds like “strong/weak” isn’t as widely agreed-upon as my own experience had led me to believe, so it would be good to have some other term for it. I don’t know if “exceptional” is what I’d use though.

      2. 3

        There are two reasons that the term is basically meaningless.

        First, lots of people who use the term “weakly types” include both memory-unsafe languages with unsound type systems like C and safe languages with no type system like Perl. These systems don’t really have anything in common, and categorizing them together is the result of confusion.

        Second, the semantics of JavaScript’s + operation is just a particular function definition. It’s easy to write a function that has exactly that behavior in Python or Scheme or any other language that’s no “weakly” typed. So it turns out that people aren’t saying anything at all about the language or about types, but instead are talking about the behavior of particular standard library operations.

        1. 1

          I feel like there’s a pretty widespread agreement that “weakly typed” means a system like Javascript, Forth, or Perl, where operations like trying to add a function to an integer will try to produce a result rather than throw an exception no matter how nonsensical their inputs are.

          Ruby is usually lumped in with the “weakly typed” languages, and will throw a NoMethodError (or possibly a TypeError) in many of these cases.

          1. 5

            Huh; I’ve never heard anyone classify Ruby as weakly typed. They’re probably using the definition in the article in that case; it’s just not one I’ve seen myself.

            1. 2

              Weakly typed absent some specific context or property to be applied to could mean virtually anything anyway, so it’s not good terminology to use when you want to make yourself understood.

              Conventionally I’ve seen it used to refer to (automatic) type coercion (such as in PHP, JS) but I’ve seen it used to contrast the subject from some other system/property perceived to be “stronger”.

        2. 8

          It’s great to see that this has found a permanent home, I link to this article regularly :)

          1. 8

            Reminds me of this quip: http://ro-che.info/ccc/17

            1. 10

              I don’t really understand why we have to either be “for static types” or exclusively “for dynamic types.” Isn’t possible to be for neither and understand that they each have their own unique set of trade offs?

              1. 13

                I think there’s a feeling that static types completely supersede dynamic types with such minimal side effects that there’s no conceivable reason to pick dynamic types should you have the option. These arguments usually proceed technically noting that statically typed languages can embed dynamically typed languages with no trouble while the opposite is not true. This seems to be a clear indication that static typed languages are “more powerful” than dynamic typed languages. Further, since this embedding proceeds via static typing formalism it’s easy to say that those who disagree simply have not learned sufficiently much to be familiar with this argument and would be immediately changed should they ever learn it. Finally, it’s sometimes the case that a person who’s been extensively exposed to dynamically typed languages will learn the static formalism to understand the “uni-typed argument” and then will end up feeling static types are superior thus forming an existence proof of this progression.

                I think that’s a technical description of what happens sometimes from the statically typed languages camp. Note that it’s a bit fallacious in that it conflates “embedding” with “superiority” without really defining the latter. Oftentimes definitions of superiority are given but it’s unclear whether those notions still follow from “embeds” let alone whether everyone ever agrees about those definitions.

                From the dynamically typed languages camp people tend to argue from proof of popularity and existence of solutions. It’s hard to understand why introducing more technology, its corresponding immediate mental overhead (again, static types embed dynamic types and thus, often, are additional formalism beyond dynamically typed languages), and the associated retraining costs will “improve” code which can and has already been written. It’s rare to find anyone who would argue that code written in a dynamically typed language cannot be more easily made to run than code written in a statically typed language (though both camps may implicitly assign different value judgements on this outcome).

                As a final force, it’s often the case that additional formalization can be added “atop” a language. Some might even consider “unit testing” at large to be such a thing, although a more commonly acceptable example might be Valgrind. This extra formalization can be seen as either “checking programs” or “restricting the language definition” based on your point of view. It turns out that oftentimes people using dynamically typed languages will seek out these extra formalizations in order to provide faster feedback loops on the correctness, safety, or resource utilization of their programs. It also turns out that people using statically typed languages do the same (again, see Valgrind) although these tend to be characteristically different from the systems used for dynamically typed languages since statically typed languages already have higher levels of formalization.


                Ultimately, all of these forces are at play and lead to a great deal of debate while the real value judgements at play are ignored. Greater formalization leads to faster response cycles on program creation (which is often considered a pro) but may do so using less information and thus be less informative themselves. Ultimately, this forms a UX problem: for different kinds of programming tasks do you want a programming interface which tells you quickly when you’ve made some class of errors or one that defers failure and allows you to determine more information about the runtime first?

                A further concern is that systems which defer more errors for later stages today tend to be less capable of “completeness”. As an example, building a unit testing suite will help you to validate your program but due to its expense and nature it’s unlikely to ever build a unit testing suite which comprehensively confirms global properties of your program (such as static type safety). Dually, systems which respond more quickly tend to be less capable of “depth” as they must operate with less runtime information.

                Both of these weaknesses are being addressed. “Incomplete” systems are growing more powerful and seeking out ways of examining whole ASTs for interesting properties (see: Typed Clojure or Dialyzer) while “shallow” systems are growing stronger formalisms for capturing higher information scenarios (see dependently typed languages and theorem provers).


                The “embedding” property is an interesting one that everyone should be familiar with—and I think personally I agree with some of the static typing zealots who suggest that people who “do not understand static types” tend to be unfamiliar with it whether or not I agree that this unfamiliarity is damaging. However, instead of using it as a poor proxy for “superiority"—especially of any particular language over any other—it’s better to see it as evidence that all of these techniques are, in theory, composable.

                Since we’re ultimately solving a UX problem which discerns between variables like “error detection turnout cycle time”, “richness of error information”, and “completeness of evidence of validity” we might prefer a system (or set of systems) which allow us to tune each of these things and use them as the situation calls for it. As far as I’m aware no such system exists, though GHC’s –fdefer-type-errors is a step in that direction as is Typed Clojure and Typescript.

                Finally, there’s an open research question as to “ease of use” and “error risk”. It’s hard to answer questions directly such as “is it easier to learn a statically typed language or a dynamically typed one” as it’s impossible to (a) formulate what “easier to learn” means and (b), more powerfully, it’s impossible to establish that counterfactual without using a randomized study which is, today, infeasible.

                There is a lot of evidence in process engineering that suggests that early error detection vastly improves total cost of creation (I wish I could remember the guy’s name who pioneered a lot of the observational research on this!). This seems to provide justification that statically typed languages can lead to much faster total development time. Unfortunately, this effect is often compared with startup times (which can be mitigated by an enormous variety of techniques including pure tool familiarity) and mischaracterized. This is sad because it’d be great to have real data about how different kinds of process testing (and I’ve outlined quite a variety above) actually do or do not improve various kinds of projects. Information like that would be instrumental to efforts to better solve the language UX problem outlined above.

                1. 10

                  Welcome to tribalism on the Web, I guess? People identify with their tools inappropriately and interpret good things said about alternatives as attacks on themselves.

                  1. 2

                    Knowledge of the state of the art almost always means not finding uni-typed systems very interesting. At least for practical day-to-day work anyway. We’re talking about differences on the scale of arguing in favor of outhouses rather than indoor plumbing. You won’t get serious arguments for that from people with comprehensible value preferences.

                    I used to use Clojure (Python, Common Lisp), now use Haskell. I simply didn’t know any better despite thinking I knew what type systems were like due to exposure to other statically typed langs.

                    I was very wrong. And no, Scala and OCaml don’t hit the mark.

                    I’ve talked to people that have published on augmented uni-typed systems who still didn’t know much about what writing code in more advanced languages was like, so it’s not only industrial programmers that lack exposure.

                    Mine and other peoples' experiences are discussed here: http://bitemyapp.com/posts/2014-04-29-meditations-on-learning-haskell.html

                    Repeat: I used to be on the other side of these debates. Had tons of experience in Lisps, statically typed languages, FP, the works. I still didn’t know any better.

                    1. 9

                      Knowledge of the state of the art almost always means not finding uni-typed systems very interesting. At least for practical day-to-day work anyway. We’re talking about differences on the scale of arguing in favor of outhouses rather than indoor plumbing. You won’t get serious arguments for that from people with comprehensible value preferences.

                      Well, that’s pretty condescending. Either I don’t understand functional programming or I don’t have “comprehensible value preferences.”

                      I know this may shock you, but I’m actually quite happy to program in either Haskell or Python. (And gasp, I like Go too! I know, crucify me already and get it over with.) It very much depends on what I’m doing. And if you can get off that high horse of yours, you might discover that there are a lot more people like me.

                      (Hint: Life is about trade offs. Sometimes an outhouse is exactly the thing you want because indoor plumbing isn’t feasible or is too costly. And you know what? There’s absolutely nothing wrong with that.)

                      We are already in a situation where programmers immediately dismiss Haskell with the quip, “I’m just not smart enough to grok it.” (Uttered from the mouths of programmers that I otherwise respect. But what do I know? I have incomprehensible value preferences!) If you’re going to play right into that, then you really have zero hope of motivating that sort of programmer to really dip their toes into a language like Haskell.

                      And if that’s the case, then at the end of the day, what is it that you hope to achieve by purposefully using language that encourages tribalism and snobbery?

                      It’s easy to say, “Well, once you know what I know, then you’ll see the light and all will be well.” It’s much harder to figure out a way to relate functional programming to those who haven’t been exposed to it and demonstrate how it can improve their lives. Feel free to guess at which approach I’ve found to be more effective in practice.

                      Repeat: I used to be on the other side of these debates.

                      Dammit! You’ve utterly and completely missed my point. This isn’t a debate. My comment didn’t say, “Well actually, dynamic typing is superior.” It said, “There are different trade-offs involved when using static typing and dynamic typing.” This implies that one could be a better a choice than the other depending on which trade offs you value.

                      1. 2

                        I know this may shock you, but I’m actually quite happy to program in either Haskell or Python.

                        Not especially. I use Python too.

                        (And gasp, I like Go too! I know, crucify me already and get it over with.)

                        Are dramatic parentheticals necessary for your response to my comment?

                        (Hint: Life is about trade offs. Sometimes an outhouse is exactly the thing you want because indoor plumbing isn’t feasible or is too costly. And you know what? There’s absolutely nothing wrong with that.)

                        This is a false economy in this case. My mistake for resorting to the analogy.

                        If you’re going to play right into that, then you really have zero hope of motivating that sort of programmer to really dip their toes into a language like Haskell.

                        I’ve motivated my share programmers into learning Haskell and continue to do through education. I’ve only gotten guff from people with something to protect on an internet forum.

                        It’s much harder to figure out a way to relate functional programming to those who haven’t been exposed to it and demonstrate how it can improve their lives.

                        I don’t have this problem at all when I teach people Haskell. But they have to be ready to learn. If it’s about debating on an internet forum, then yeah, I’m wasting my time.

                        It’s not difficult to teach Haskell if you understand Haskell. Haskell isn’t the easiest language I’ve taught, but it’s far from the hardest.

                        Do you write software for a living? This stuff is a lot more impactful when you’re a professional software engineer who has to maintain systems over a period of time as opposed to writing code that works once and then is discarded.

                        Have you read the post I linked? The points about maintenance, refactoring, etc that I’m alluding to are a core part of the value proposition.

                        1. 7

                          Do you write software for a living? This stuff is a lot more impactful when you’re a professional software engineer who has to maintain systems over a period of time as opposed to writing code that works once and then is discarded.

                          Way to be patronising, dude. Plenty of really smart serious professional people prefer to program in “uni-typed” systems and have created some pretty fabulous stuff with them. Can’t we all just enjoy our own preferences without denigrating each others?

                          1. 1

                            Plenty of really smart serious professional people prefer to program in “uni-typed”

                            I count my past self among those smart, serious, professional people that preferred to program in uni-typed languages.

                            and have created some pretty fabulous stuff with them.

                            I’ve seen some cool demoscene projects made from m4 macros generating native assembler. Don’t think that’ll convince me to write my code in asm+m4 though.

                            Don’t make dishonest arguments, you’re a smart person and know full well that has entirely to do with labor input and raw numbers.

                            Can’t we all just enjoy our own preferences without denigrating each others?

                            Could, but the situation is a bit more like herd immunity and vaccination than it is gay marriage. Sadly with software we’re all tied together to varying degrees unless we’re individually prepared to go full-unabomber and not use anybody else’s stuff.

                            Do people have a right to refuse vaccination and spread the risk among an unknowing public?

                            I’m not saying people should write everything in Haskell. Rather, informed decisions should be made knowing that most comparisons currently lead to false economies. We should move forward knowing what’s been possible for the last two decades let alone what’s currently in the works (Idris et al).

                            As an industry, we don’t keep introducing programming languages that are a massive backwards step without there being some kind of education gap.

                            I wouldn’t take seriously a doctor that told me to treat my flu with bloodletting. My doctor’s opinions on bloodletting wouldn’t deserve the mutual respect of his peers either. If we want to be treated like professionals (engineers) then we should take things like this seriously. We’re using inferior tools due to preference and aversion to the unfamiliar. This is deeply unprofessional.

                            I think Heartbleed has demonstrated how fatal that reliance on dated tooling utilized by other people can be.

                            I know people that have (partly) gone the desert island route, mostly grumpy C and Forth programmers. I don’t have that choice because I code for a living.

                            1. 3

                              Do people have a right to refuse vaccination and spread the risk among an unknowing public?

                              How about you code in your system, and I code in my system, and we agree to communicate between our systems using a exchange of uni-typed byte arrays, tagged according to a prearranged scheme. Like maybe IP datagrams.

                              Then at runtime we could check those incoming byte arrays and if they look sensible we can build other, higher level unityped tagged byte arrays, which we could interpret as json or maybe haskell source code or jpegs.

                              Then, if those arrays look OK we could, again at runtime, construct safely typed values in our systems which are isomorphic to the values which are referants of the byte arrays. Voila! Safety and happiness.

                              1. 2

                                SOA has been a tactic for accommodating polyglot environments for a long time, but I don’t think that’ll work for all infrastructure.

                                That did introduce the amusing idea of avoiding embedding C libraries and instead exposing it as a local domain socket service.

                          2. 3

                            Are dramatic parentheticals necessary for your response to my comment?

                            Is snobbery necessary for yours? If you’re going to label everyone either ignorant or incomprehensible, then you probably shouldn’t expect to get completely cordial responses.

                            This is a false economy in this case.

                            Why? Static and dynamic typing each have their own trade offs. That’s my only point. Your analogy perfectly demonstrated this fact.

                            Do you write software for a living? This stuff is a lot more impactful when you’re a professional software engineer who has to maintain systems over a period of time as opposed to writing code that works once and then is discarded.

                            The condescension continues. But the answer to your question is yes.

                            It’s not difficult at all to teach Haskell if you understand Haskell. Generally, the most difficult people to teach are the ones holding onto false analogies from programming languages that aren’t Haskell or Haskell derived.

                            Teaching has never been something that I’ve observed to be easy. I can’t imagine why anyone would think it’s easy. And I’ve never been in a situation where insulting or blaming the student has ever helped improve learning outcomes.

                            I strongly recommend taking a step back and really reading what you’re writing here. I don’t know if you intend it or not, but there is a very strong holier than thou message radiating from your choice of words. If you want to succeed in effectively communicating with as many people as possible, I’d recommend working on dropping that.

                            1. 1

                              Why? Static and dynamic typing each have their own trade offs. That’s my only point. Your analogy perfectly demonstrated this fact.

                              They don’t, actually. That’s the false economy I’m talking about.

                              There are incompatible dimensions of time preference being applied here that leads to this thinking. Fixed cost/bandaid tearing vs. high, ongoing costs.

                              And I’ve never been in a situation where insulting or blaming the student has ever helped improve learning outcomes.

                              You’re not here to learn, which is why I already know this is a waste of my time.

                              I don’t know if you intend it or not, but there is a very strong holier than thou message radiating from your choice of words.

                              I’m unyielding to poor argumentation.

                              I respond much much better to originality, even if the argument is still bad.

                              I’ve heard all this a thousand times before and even used to be on the other side of the exact same arguments. I’d like to at least hear something new. I could draw up a variation of that classic Usenet “spam eradication idea” checklist for these threads and probably catch 98% of what’s said.

                              The question remains, what does the remaining 2% look like after the homeopathists are done complaining about not being given their due respect for their practice of alternative medicine?

                              I have a track record of willingness to change my mind - do you? All I’ve really gotten out of you so far is tone-policing.

                              Be honest, am I wasting my time here or are you just trying to make this thread go further down and to the right? Are you up for learning something new?

                              1. 6

                                If I have learned anything in this industry, it’s that the dogmatic view is, with certainty approaching 1, wrong.

                                The fact is – in this debate, it’s not burntsushi who’s in need of a mind-change, indeed, he’s advocating for an understanding of the plain and simple fact that not everyone has the same outlook on the qualities and relative value of a language. In particular, it is not unreasonable to argue that you may be a special case, and we shouldn’t demonize people for using the tool that works for them and their team.

                                I say this as someone who really likes functional, strongly typed languages (I spent a fair amount of time writing exclusively Haskell, and still work it into my job occasionally, pretty sure we had a twitter conversation about it the other day).

                                I also say this as someone who really likes object-oriented, dynamically typed languages. I even advocate for them to be used instead of typed alternatives!

                                I think you are presenting the case for strongly typed languages in a very poor way, and indeed this whole thread is characteristic of the common ‘talk-past-each-other’ style, with the slight caveat that burntsushi is indeed saying something different than the usual, though in the usual style of tilting at computational windmills.

                                The facts are these, at the end of the day, your ideology, my ideology, everyone’s ideology is crap. What matters is results, and the fact is lots of companies make plenty of money on the backs of dynamic and static type systems. Some companies transition to or from one to the other, increasing profits in the meantime. This indicates to me the simple fact that the language and it’s characteristics, at the end of the day, are immaterial to the value a company achieves. What is more likely more important is finding the right tools, the right developers, and the right structures to support those developers and tools so that they can deliver value. Whether it’s static, strong typing in Haskell, dynamic typing in Ruby, weak-static typing in C, or butterflys-and-chaos-theory, all that matters is that value is delivered, and the fact is – both deliver, despite zealotry from both sides.

                                1. 2

                                  I’m not saying we should all be using Haskell for all things.

                                  Quoting myself from earlier in this thread: “I’m not saying people should write everything in Haskell.”

                                  The only ideologies I’m espousing are that of modernism and progress. If you don’t think CS has improved over time, then there’s a lacuna that cannot be crossed and we need not argue with each other.

                                  The pugs Perl (self-styled post-modern programming language) 6 prototype was in Haskell :)

                                  1. 4

                                    The only ideologies I’m espousing are that of modernism and progress.

                                    You can either insult the people who haven’t yet reached your plateau of enlightenment or you can advocate for progress. They are mutually exclusive goals because progress requires convincing others. Convincing others doesn’t work when you insult them.

                                    1. 1

                                      I agree – CS improves over time, nor did I mean to imply that you claimed we should all use Haskell (or anything else, other than, it seems, static typing).

                                      That said, I think CS improves in multiple directions – including static typing, and dynamic typing. It is not unreasonable to assert that there are multiple valuable paths to travel when designing a language. Dynamic typing does have value not provided by static typing, just as static has benefits over dynamic. It’s a spectrum with more than a few critical points we can optimize toward, depending on the domain.

                                      Perhaps the divide we are experiencing has less to do with the technical merits, and more the philosophical framework with which we evaluate these things – I view the world through a post-modern lens, I am comfortable with there being potentially many solutions a particular problem. I am making an inference (based on your last paragraph in the above) that perhaps that’s different for you, if so – fine, but let’s talk about the substance of that rather than continuing a quixotic conversation such as this one.

                                      1. 2

                                        What are the benefits (not familiarity) of dynamic typing over modern static type systems?

                                        Can you construct a correct program in a uni-typed language that you believe would be inexpressible in a static system?

                                        1. 6

                                          First – I am unwilling to dismiss non-technical benefits (like ease-of-learning, etc) as they do represent real business value. But we can shelve that.

                                          Can you construct a correct program in a uni-typed language that you believe would be inexpressible in a static system?

                                          No, I can construct correct programs in dynamically typed languages, but by definition I should be able to construct those same programs in statically typed languages too. The principle difference is not technical – I mean, at the end of the day, you can make something work in virtually any language (barring those esoteric joke languages, while it is theoretically possible to write a webserver in befunge, I shouldn’t want to see such a thing).

                                          You cannot examine these languages in isolation from their environment – you have to account for all the messy sociological factors that dial into the use of any tool. It’s not enough to say, “I can express that this statically typed program is correct up to the correctness of the typechecker” – you have to account for the business cost of writing that program, the peoplehours to maintain it and improve it. You also can’t treat a statically typed program in the same way as a dynamically typed one. Here is a concrete example.

                                          I have a series of scripts which maintain an existing, shoddy webserver. I inherited these scripts from a predecessor, they were primarily bash and perl, and they were messy. Because these scripts were not efficient in terms of interface-usage-time and execution time, and because I had very little bandwidth to spare, I chose to rewrite them in ruby, rather than a static language, because the time from zero to delivery was much smaller with ruby.

                                          Later, when these tools needed to scale up, I wanted to take advantage primarily of the useful data-parallelism libraries available in Haskell, so I rewrote chunks of the ruby scripts in Haskell. Though I was primarily re-implementing functionality, it took reasonably more time (though not inordinate) to get to feature parity with the existing rubyscripts. Eventually I added the Data-parallel stuff with relative ease (because of the library support), and went along my merry way.

                                          Yes, it’s an anecdote, but my claim is that we’re straining at gnats – the difference in terms of value is not technical, it’s sociological. In this messy anecdote, we see the sociological constraints influencing my decision – I didn’t have the time to try to convert from bash and perl to haskell directly. Nor do I think writing the entirety of these scripts in Haskell is strictly necessary, or even cost-effective.

                                          It is possible to overengineer a solution, and when you are optimizing to add value, overengineering causes loss. I get paid to generate value, not loss. However, when it became value-positive to use Haskell (i.e., when I wanted to do something more complicated, where I required a strong degree of correctness and wanted a reasonable time-to-delivery), then I swung that hammer.

                                          The punchline here is that I reject any attempt to ignore the messy nature of Software Engineering to make some high-falutin' argument about the ideological purity of one idea over another. The plain fact is – from here in the real world, the use of static or dynamic languages is largely irrelevant compared to the much bigger problem of delivering software that provides the desired features (note carefully that I did not specify that that software needs to be correct, just that the customer will be able to find the features they desire).

                                          To put it shortly: I don’t care about technical arguments, because they ignore the much bigger component of the problem, people.

                                          1. 2

                                            What are the benefits (not familiarity) of dynamic typing over modern static type systems?

                                            This has already been hashed out: http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages

                                            What jfredett said is good too. :-)

                                            1. 1

                                              Just for fun and to give a different answer to the other good answers:

                                              A running binary created from a decent statically typed system may be typesafe, but the information about the types is no longer reified - unless we explicitly choose to tag expressions or values with run-time tags reflecting the original compile-time types. In which case we have something strikingly similar to a ‘dynamically typed’ system. Insofar as we can then make runtime adjustments to this running binary by hotloading new code, we are doing so in a language which can only typecheck expressions (written in its syntactic representation of types) in the context of an existing set of tagged unityped values. In other words, if our program is typesafe it is only because of the tools and techniques of runtime tagging of unityped values - ie dynamic typing.

                                              1. 1

                                                Quite easily.

                                                The first program is represented in the second-order typed lambda calculus.

                                                The second program is represented in the untyped lambda calculus.

                                        2. 1

                                          They don’t, actually. That’s the false economy I’m talking about.

                                          You haven’t presented any false economy. It isn’t necessarily just time preference, trade offs can also include personal preference, ignorance, comfort level, available libraries, performance, size of program, safety, system constraints, the people you work with, etc. All of these are factors when considering static vs. dynamic typing and they all vary depending on the particular blends of static and dynamic typing being considered.

                                          You’re not here to learn, which is why I already know this is a waste of my time.

                                          Spare me the theatrics. Either speaking with me is a waste of time and you stop or just press on.

                                          Your comments are becoming vitriolic.

                                          A key difference here is that I have a track record of willingness to change my mind (I’ve explicitly stated as much) - do you?

                                          Be honest, am I wasting my time here or are you just trying to make this thread go further down and to the right? Are you up for learning something new?

                                          I’m not sure what you expect. I’m already sold on functional programming. I love Haskell and have used it for several projects. Same for Standard ML and Erlang. I just stop short of zealotry, vitriol and snobbery as if the fate of the world depended on us collectively deciding to only use languages chosen by the Enlightened Few.

                                          1. 3

                                            available libraries, performance, size of program, safety

                                            Getting warmer :)

                                            fate of the world depended on us collectively deciding to only use languages chosen by the Enlightened Few.

                                            This is where I ask again if you’ve read the post I linked, because it’s core to this misunderstanding. I’m going to quote that post so I can bring this front and center.

                                            Somebody not me said in that post: “One of the things i really love about haskell is that it makes it quite clear it isn’t the endpoint either - that there’s this whole world of dependently-typed stuff we’ll one day be able to use.”

                                            Let something I said earlier in this thread: “As an industry, we don’t keep introducing programming languages that are a massive backwards step without there being some kind of education gap.”

                                            I said in another earlier comment, “I’m not saying people should write everything in Haskell.”

                                            There’s a concept of progress being emphasized here. It’s not a decision-tree whose leaves all terminate in Haskell. What is inescapable is that progress is being made in research that industry is not leveraging.

                                            Repeating a quote from another earlier comment I made: “Do people have a right to refuse vaccination and spread the risk among an unknowing public?” with the additional thought, “Do doctors have the right to prescribe potentially harmful courses of treatment if it’s more convenient for them?”

                                            Your answer to this is an indication of whether you’re consistent in the professional standards you hold others and yourself to.

                                            If you believe professional standards (client outcomes) pale in importance to personal preference then there’s no reason for us to be at an impasse here. If you believe differently, then there’s a knot to be unraveled.

                                            Did you miss that I said we shouldn’t necessarily write everything in Haskell or are you proceeding in bad-faith? I’m going to assume the latter and call it a night now.

                                            1. 6

                                              My comments are derived crucially from this statement you made:

                                              Knowledge of the state of the art almost always means not finding uni-typed systems very interesting. At least for practical day-to-day work anyway. We’re talking about differences on the scale of arguing in favor of outhouses rather than indoor plumbing. You won’t get serious arguments for that from people with comprehensible value preferences.

                                              You’ve continued to argue this perspective in other comments by comparing this situation to the state of health care for the wider community. You’ve painted a picture of your position that basically boils down to something corresponding to these bullet points:

                                              • I know the path forward. If only everyone else could get smarter and learn what I already know, we could live in peaceful bliss.
                                              • Any other path forward is unprofessional, harmful and fatal. (Your words, not mine.)
                                              • Static typing is always superior to dynamic typing. (This is what I gather from your claims of “false economy.”)
                                              • Anyone who I think is smart but who disagrees has incomprehensible value preferences. (You’ve framed your argument such that anyone who disagrees is a cave dwelling hermit who doesn’t give a damn about anyone but himself.)
                                              • Anyone else who disagrees just doesn’t know enough.
                                              • The outliers probably aren’t “professionals.”

                                              Who exactly is commenting in bad faith here? I’m arguing from the position that all things have trade offs, even the languages blessed by you. Free lunches are hard or impossible to find, and just because there’s some new PL feature introduced that improves safety at compile time doesn’t mean it’s uniformly better than the alternatives. Additional compile time safety has an extremely important trade off: complexity. As you add more safety and approach the dependently typed languages of the world, you add more complexity to your type system. What is the right trade off? There isn’t one!

                                              It’s a balancing act. Nothing more and nothing less. This is the fundamental lesson of computer science.

                                  2. 3

                                    Why don’t you think OCaml “hits the mark”? Lack of typeclasses?

                                    1. 2

                                      I’ve talked to people that have published on augmented uni-typed systems who still didn’t know much about what writing code in more advanced languages was like, so it’s not only industrial programmers that lack exposure.

                                      I doubt that – basically everyone who publishes on gradual typing etc has substantial experience with languages like Haskell and ML. It turns out we mostly don’t agree with you, but that’s not the same thing as lacking experience.