Hacker News Reader

Comment by kjksf | Hacker News Reader

Apparently, the author of this blog post had a change of heart:

https://memo.barrucadu.co.uk/blub-crisis.html

> I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are obviously too limited to get any real work done in, and languages with more advanced features than Haskell (like dependent types) are really just weird and not actually solving a problem I would ever face.

> The arrogance! Such a know-it-all!

> I have decided to call such a realisation a “Blub Crisis”. Haskell is my Blub. The only solution is to become proficient—actually proficient—in a different language, and once again learn a new way of thinking.

View on HN

I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.

It did to me.

He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code).

This is not how you approach new things

That is a single dubious point amongst some serious and in my opinion legitimate issues with the language.

Complaining about strict evaluation, the std lib not doing what he wants it to, the type system, the lack of heap profiler/threadscape, and .... demanding Golang handle zero values in his preferred way is basically him whining it ain't Haskell. I could blubber about it not having power conjunctions or self intervals or whatever if I wanted Golang to be J, which would be a similarly moronic roster of complaints. In reality golang is a basket of compromises like any other programming language. There's vastly more good stuff built in it than Haskell, despite Haskell being older and more theoretically amazing, so they must be doing something right.

His only criticism that resonated with me was go get defaulting to head, which befuddled me when I first saw it, but that's a compromise too; one oriented to the large codebases that golang is designed for. It's actually a pretty good compromise compared to the propeller head Haskell dork "Things break backwards compatibility in Haskell, and the users just update their code because they know the library author did it for a reason." -aka this appears to be a statement from an academic wanker who obviously never had to ship on a timeline in his entire fucking life.

The type system complaints are somewhat in the area of "it should be more like Haskell", but the debugger, heap profiler and thread debugger ones are certainly not.

Golang has extremely basic tools for anything beyond formatting/compiling compared to most modern languages. This is just a limitation of the current ecosystem, not something you can say has tradeoffs (except of course for the Go team's time/prioritization of features).

Delve is getting better, but it has a LOT of ground to cover before it is half as useful as gdb or a java/C# debugger. Same goes for the profiling tools, especially on the CPU side.

I've never really done Haskell, but I have Erlang, Java, C#, JS, TS and Erlang under my belt.

I agree with everything the author said after having spend some time with Go.

> He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code).

Heck, I come from a C background, and that's a complaint I have about Go. Sometimes you want to have a function accept a pointer to a large structure to avoid copying, but have the compiler prevent you from making any changes. In C you'd write "const"; in Go there's no way to do that.

Sure, const is great to have.

But Haskells view on this topic is far far more opinionated than just supporting 'const'.

I've never written Haskell or another pure functional language more than a couple of lines, but the more I write code the more convinced I become that the ability to reason about mutability and side effects is a major force multiplier in writing robust software.

I agree that being able to reason about mutability and other effects is useful. However, that doesn’t necessarily imply an all-or-nothing approach where either you’re in a pure function or you can do anything with anything. In a sibling comment, gwd mentioned const in C, which is one example of something in between. Rust’s ownership semantics and borrow checker are another.

> However, that doesn’t necessarily imply an all-or-nothing approach where either you’re in a pure function or you can do anything with anything.

To elaborate this point I'd say that the most important practical use of all that "monad mumbo-jumbo" in Haskell is that you can tag your functions with what they can and can't do and then the type system tracks this for you:

  -- pure function
  f1 :: Text -> Int

  -- can fail
  f2 :: Text -> Maybe Int

  -- can read from some MyEnv record
  f3 :: Text -> Reader MyEnv Int 

  -- can keep a set of bool as state around
  f4 :: Text -> State (Set Bool) Int

etc... and of course to go nuclear:

  -- can do anything
  f5 :: Text -> IO Int

The tracking part is that you can't call f5 from within f1, the type checker says no. It enforces separation between all these various effect boundaries.

Also we don't have to stop here. A natural next step is defining exact effects one is after. For example say I want my function to be able to get some entity from a DB:

  -- any type that is an instance of Entity can identify itself by uuid
  class Entity e where
    identify :: e -> UUID

  -- The effect we want, ie. get an entity via its uuid
  class (Monad m, Entity e) => GetEntity e m where
    getEntityById :: UUID -> m (Maybe e)

now we can say things like:

  data User = MkUser {uId :: UUID, uName :: Text}

  -- a User can identify itself
  instance Entity User where
    identify = uId

  -- as User is an Entity so we can get it via its uuid (if it exists)
  getUserById :: (GetEntity User m) => UUID -> m (Maybe User)
  getUserById = getEntityById

Also notice how getUserById does not say anything about IO or a DB. All it states is that whatever context it will run in that context must know how to get a user via its uuid. You can then plug in whatever actual context you want, say:

  newtype Prod a = MkProd {unProd :: ReaderT ProdDB IO a}
    deriving newtype (Functor, Applicative, Monad, MonadReader ProdDB, MonadIO)

  -- get a user from a DB for real
  instance GetEntity User Prod where
    getEntityById :: UUID -> Prod (Maybe User)
    getEntityById eid = do
      ProdDB {..} <- ask
      -- query the DB, etc...

  newtype Mock a = MkMock {unMock :: State (Map UUID User) a}
    deriving newtype (Functor, Applicative, Monad, MonadState (Map UUID User))

  -- get a user from a mock DB
  instance GetEntity User Mock where
    getEntityById :: UUID -> Mock (Maybe User)
    getEntityById eid = gets (Map.lookup eid)

All in all the programmer have fine-grained control over what various parts of their code can or can't do.

The trick seems to be how to implement this kind of idea in a composable way, so we can still have a clear, modular design and write generic, reusable code even in the presence of several different types of effect. IMHO, the research into type and effect systems in recent years has been promising, but also shows that this is not an easy problem to solve. I’m hoping that in a few more years we might see a new generation of programming languages that incorporate this kind of “effect safety” as easily and naturally as many developers use const and qualifiers and resource management idioms today.

Unison's ability system (an implementation of algebraic effects) is looking promising as an ergonomic method of tracking effects.

I haven't yet looked much into effect systems so can't really talk about them but I think even with something like MTL you can achieve a decent level composability/modularity where you build up a library of capabilities that you can then use to pick and choose effects from, eg.:

  type FooContext m = (GetTime m, GenUUID m, Log m, Auth m, ReadDB m, WriteS3 m, BarApi m, etc...)

  foo :: (FooContext m) => UUID -> m Foo

The main downside is ergonomics, ie. the amount of boilerplate needed, but personally I don't think that's a high price to pay.

I tend to agree, but, even then, one doesn't necessarily have to take things quite as far as Haskell does.

In Rust, for example, mutable data is allowed, but, when the owner of mutable data shares a reference to it, it gets to decide whether the borrower is also allowed to mutate the data. This doesn't eliminate the more challenging things you can do with shared mutable variables, but it does mean that enabling them requires mutual consent.

Nim does an interesting thing, too. It has a two-color function mechanism where "procedures" are allowed to have side effects, and "functions" are not. But even functions are allowed to use mutable variables behind closed doors. That can arguably be an ergonomic win. Many people find that, within a sufficiently bounded context, an implementation that uses mutable variables might be more maintainable than a purely functional implementation.

The main reason Haskell goes even further, and bans mutable variables from the insides of functions as well, was never really about maintainability, per se. It was done that way because Haskell, as a lazy language, couldn't allow anything that might require statements to be evaluated in a particular order. That design decision turned out to lead to an impressive bounty of interesting and useful discoveries. But there also seems to be something of a tendency to swaddle the bathwater with the baby.

It's worth noting that Haskell allows mutable variables in IO actions - a type used to model computations that are not referentially transparent. It's just that using this facility is not super ergonomic.

My Blub language has been PHP. While the language has been getting better over the years, especially with the introduction of types, I still felt at one point that I wasn't growing. I had a try at Haskell, and failed miserably. I tried OCaml, but still something felt unnatural to me, although what really intrigued me was the sound type system and the guarantee that if it compiles, then it's probably going to run well. I then tried Elixir, and I love it. I think Elixir is a wonderful transition language, but something that I wouldn't mind keeping close in my toolstack. The Actor model, immutability, pattern matching, meta programming, these are all concepts that uppended my way of thinking. PHP/JavaScript array sort functions feel so weird to me now for doing the sorting directly on the variable. But to be honest, I wish Elixir had types. I don't trust myself writing functions that can return different things.

Erlang has some type annotations. Not sure whether they made it over to Elixir?

Dialyzer is fully integrated into Elixir, yes. But again, it’s optional typing.

I know how to use Dialyzer and am quite proficient with it. I cannot say, however, that it helps me in any way. I think strong typing is a crutch for bad programmers and I've yet to encounter anything in my 30+ years of programming to change my mind.

There's two sides to it:

First, there's only so much I can hold in my brain at once. If the computer can do some of the tedious busy work, let it.

Second, the first perspective talks about catching errors and oversights. A sufficiently non-bad programmer could make do without. But static typing also allows for some programming techniques that wouldn't work without.

As a silly example, Haskell makes heavy use of overloading-by-return-type. You just don't the information about what return-type is expected available dynamically, it needs to be static.

There's also lots of optimizations that are safe only when the compiler knows more about your code. (Of course, a sufficiently non-bad programmer could write directly in the machine language of every processor she's writing code for..)

In practice, typing helps me a lot with eg exhaustiveness checking for my pattern matches.

The type system that dialyzer exposes is pretty weak. So not a good standard to measure all of typing against.

Dialyzer solves certain problems for me that still exist in many "typed" languages. A great example is pos_integer(). In something like Typescript I can use "number", but that doesn't assert I can't receive a negative number, or a zero.

In general, you'd need something like dependent types for solving this properly. Like eg Agda has.

Ada has this without general dependent types AFAIK

Yes and no. The definitions are in the type system, but the checks are done at runtime, just like you would do manually. You don't really get the benefit of typing.

The reason I can say that: you don't have to provide proofs that a value has to be positive to get things to compile.

Checks at runtime are also a good idea, but yes, very different from static dependent types.

There's some interesting work on making such contracts work well in a lazy language with higher-order functions.

Strong typing can be a crutch for bad programmers in the same way that a prosthetic leg can be a crutch for an amputee.

The world record 100m men's sprint for double-leg-below-the-knee amputees is now frozen at 10.57s (record set in 2013); omitting Usain Bolt who is clearly freakishly good even among world-class sprinters, the 100m world record is 9.74s.

I am very happy to use strong static type systems.

There are type systems out there that allow you to model more than "is a string, is a float, is an int".

There are CVEs for use-after-free bugs in Firefox, IE, the Linux kernel and more. Rust's type system helps prevent those. There are CVEs for double-free bugs in OpenSSH, OpenSSL, and Kerberos. Again, Rust's type system helps prevent those. There are CVEs for null dereferencing in the Linux kernel, CUPS, and OpenSSL. Many languages have type systems that help preventing those.

There's many more classes of bugs that can be prevented by judicious use of robust type systems. Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong.

All of this, of course, assumes the only use for static types is preventing issues. Algebraic data types actually allow you to write simpler, more concise code in languages that support them. Typeclasses make for a whole model of polymorphism that's just incredibly painful to implement in languages that don't support them.

> Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong.

No, it's correct. The problem is that innocentoldguy doesn't realize that he is a bad programmer. (That's not an attack on him - we all are bad programmers.)

So here we are, bad programmers. Here's this crutch - or, less negatively put, here's a tool that can help. Maybe we can be somewhat better bad programmers if we use it.

I get your point, but if we're all bad then "bad" loses its meaning. I'm definitely a better programmer than many of my peers, and worse than a whole bunch of others.

We're bad, not in comparison with each other, but in comparison to the external standard of "good enough that we don't need a crutch".

In fact, if you want to be a better (less bad) programmer, learn to use the available crutches more effectively.

Well, it's a bit like saying that computers of the electronic kind are a crutch for bad computers of the human kind.

Or that planes are a crutch for bad travelers who can't fly under their own power.

That depends on what kind of software you have worked on. I also got quite far with dynamic languages in the last 10 years but at one point the static strong typing helps you a lot in making invalid state impossible at compile time.

Growing complexity kind of mandates a static strong typing at one point. Sure, complexity can be managed and reduced -- and distributed among smaller projects (i.e. splitting big projects) -- but even that has a limit.

Dialyzer also takes a while to get used to and for several teams I've been in the initial cost of learning turned out to not outweigh the theoretical savings won by it.

There are other more modern libraries that defer the errors to runtime but also make them much more clear (like `norm`). Libraries like `boundaries` can also help you enforce, a-hem, boundaries in your code and making sure that you write less spaghetti code.

I personally stick to Dialyzer in personal projects but it's an uphill battle to constantly keep it happy while OCaml / Rust / Haskell will just immediately yell at you with a well-described error (well, Rust anyway, the other two can be vague sometimes).

Yep, there's `dialyxir` which is a very heroic wrapper effort to translate Dialyzer's messages to something more readable and manageable. Even with that though sometimes you get real head scratchers no matter which of both you use.

I personally believe that Elixir is an excellent 'gateway' functional programming language because it is dynamically typed.

Learning OCaml and especially Haskell (I've done some of both) requires understanding a complex type system and learning how to encode what you want in it. On top of that you have to learn to code in the 'functional' way - representing your data, pure code, recursion (or reduces), higher order functions etc.

When you write Elixir you eliminate most of the type system stuff, and you just have to learn to code in a functional way. There is surprisingly little 'language' to learn - functions, tuples, lists, maps, modules and that's about it. There is then the OTP (processes and supervisors) side of it, but that's separate (and if you're writing a web backend in Phoenix, mostly ignorable).

We're just (hopefully) wrapping up a 9 month project with a team of about 8, none of which had written much Elixir before the start (a background of mostly C). It has been a very smooth process, and definitely the right choice of language.

I sorely lack Elixir's easy entry experience while I am getting better and better at Rust. :(

And I'll look for ways to use it at my $dayjob. Rust is an excellent language but I feel that for some pieces of our stack Rust is kind of a bazooka in a scenario where a 9mm pistol would do.

I could see an argument where Rust is performant and low level enough that you can use it at the bottom of the stack, and has good enough abstractions that it's productive to use higher in the stack. There are certainly benefits to using one language for everything, but this logic reasoning relies on you having a team that is very familiar with it, and having your bits of tooling and libraries worked out for your setup.

Yep, exactly. Lower-level languages however also give you much more foot-guns.

These days my ideal app is written in Elixir for almost everything due to the insane parallelisation and fault-tolerance that it offers (and the copy semantics that make shared memory bugs impossible) with Rust sprinkled at the critically important-to-be-fast places -- like working with sqlite3 for example.

All of that could be achieved with Rust or any other language really. But it requires tons of tooling, CI/CD jobs, Git hooks, static analyzers, linters, formatters etc. And a good chunk of all that doesn't even exist for many languages.

So I prefer to make my own blend that has the important advantages at the right places.

While I think there's some sense in the analogy and you get real insights using new languages, I do find that 'beating the averages' article really unconvincing.

Firstly there's the obvious observation that Y Combinator companies very rarely use lisp, but there's also really a lack of any solid evidence of any kind anywhere that language choice has such a big impact.

I am a fan of exploring languages and making a good choice for the problem at hand and always remaining open-minded but I can't stand the religious flame war side of it and I really do not think that article helps, at all.

To me languages are always a trade-off between abstraction and control, to which each problem has an appropriate range of languages to apply.

I also think the concept doesn't apply here as go is certainly less powerful and has fewer abstractions than Haskell (by design) - so if anything it is the 'blub' language* according to the article here (my point being not to criticise go but rather to point out how silly the beating the averages concept is).

I don't think his original piece was arrogant, I think this is something of an overreaction and a problem with assessing any language - adherents meeting criticism with 'you just have to use it more' can use that excuse indefinitely. Better to address individual points.

* I love go and contributed to the core compiler back in 2011/12 so this isn't an attack on it.

Such a weird thing to frame this in terms of the Blub Paradox. Regardless of what you think about the paradox, this is what it states:

> But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

It's very, very hard to argue Go is "up the power continuum" from Haskell, or that Haskell is a Blub language compared to Go. Everything else can be debatable, but surely not this.

He could have simply said "I was arrogant about Go, and need to look at it from a fresh perspective instead of comparing it to a language I'm more familiar with", no appeals to Blub needed.

I think he's not saying Golang is up the power continuum, but that languages like Idris and Coq are up the power continuum. He doesn't bother learning those because he's "stuck".

I think you're right! I misread it.

Also interesting: it's his only article tagged Go, from 2017. He never mentions Go again. Since he has several more articles about Haskell, I wonder if he eventually quit his job, or whether he simply didn't have anything else to say about Go.

The Blub Paradox is flat-out wrong. To see why, just look at Haskell and Lisp.

When a Lisp user looks at Haskell, they are sure they're looking down, because Haskell doesn't have macros. But when a Haskell type (pun intended) looks at Lisp, they are also sure that they're looking down, because Lisp doesn't have a decent (Hindley-Milner) type system.

This situation - two languages, each sure that they're above the other - shows the problem. You cannot rank languages on a one-dimensional axis called power.

Another way of getting there is to ask: Power? Power for what? For writing programs. What kind of programs? General programs? I've never written a general program in my life. I've written a bunch of specific ones, though. What I care about is power to write this program - the one I'm currently trying to write. (Why do I care about a language's power to write a program that I'm not trying to write?)

Instead, think in terms of yak shaving. What are the yak shaving aspects of the program I'm trying to write? Think of that as a vector in a multi-dimensional space. Think of languages as branches on a tree. Which branch extends farthest in the direction of the yak-shaving vector? Use that language.

But you have to have kind of an expanded idea of what "yak shaving" means. In particular, if you pick a "non standard" language, training your team becomes part of the yak shaving.

Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)

Well, if your alternative was 90s style Java or C++ static typing, Python-style dynamic typing looks comparatively less insane.

As soon as you have algebraic data types and parametric polymorphism, static typing is less onerous, so dynamic typing is less appealing.

And especially type inference.

Yes. Ideally something as powerful as Hindley-Milner or similar. But even the weak sauce versions in Go (or recent Java or C++) are a boon to developer ergonomics.

Java's is particularly weaksauce, and has problems chaining inferences within even the same expression, but it's definitely way better than not having it at all.

I liked 90s Java at the time. ;-) well the alternative seemed to be c++ or vb or Perl and I didn’t know about python.

> I couldn't get my head around why people like untyped languages

What do you mean exactly with "liking" untyped languages?

I personally program mainly in both a ("cognitively demanding") typed and an untyped languages, and they have different use cases.

For relatively small programs, untyped languages are much faster to develop. A program I wrote yesterday in a few hours would have taken 2 to 4 times as much in a typed language.

On large libraries (I consider gaming engines as so), common wisdom suggests that typed languages make the project easier to manage (modify and so on).

There's obviously a wide range of use cases in between.

By like I mean prefer. So they’d pick Ruby instead of Java for most tasks for example.

Is that true? A simple program that isn't going to see long term use means I don't have to worry about anything but the happy path, either typed or untyped. And something where I have to nail down the edge cases is easier in a typed language.

True? I personally have no doubt (of course, programs vary a lot, so there are certainly cases where the effort is comparable).

Besides the unstructured trees, another example, although more high-level, is interfaces. They're a concept required in statically typed languages (some languages they have a simpler design than others), but not in dynamically typed languages (which have duck typing).

If you have a couple of types that you need to abstract, in a S.T. you'll need to define an interface, the method signatures, which include the return types, and maybe (in lower level languages) the generic types and the super interfaces. Even something as (relatively) simple as generalizing a tuple and a matrix types will require some design.

In D.T. languages, zero effort is required. As long as an object responds to a method (name), it's game.

I think it's not realistic to assume that the concepts that need to be taken care of in a S.T. language are comparable to the ones in a D.T. language. And more concepts imply more cognitive load. And cognitive resources are limited :-)

I joked with a friend that as people get older they start to prefer static typing. I personally don't have a preference, it depends on the application. I think it's obvious what are the advantages of static typing so let me rant about what is for me the main disadvantage: as soon as you have an advanced type system people will try to get creative writing code in the most abstract possible way. It's inevitable. It's the typed equivalent of premature optimization. Why restrict ourselves to implement matrix multiplication for floats? Why not rational numbers? Why not over arbitrary fields? This specially true when people write libraries. And yes, you can encode a lot of things in the type system but maybe it's not such a great metalanguage when taken outside of the well known uses. It's similar of how people get crazy with macros or even worse template metaprogramming.

I don't use go so I don't have an opinion if they made the right choice but I sympathize. I suppose you have to be Ken Thompson to not give a crap and say I'm going to create a language without support for generic programming in 2009. The closest thing would be a tenured professor but they wouldn't dare unless under a pseudonym.

as a counterpoint, genericness can actually serve as a form of documentation. you can often infer a lot from just a signature, e.g:

  any :: (Functor f, Foldable f) => (a -> Bool) -> f a -> Bool

tells me that `any` has to work across the whole collection `f a` (list/tree/whatever), because that's how folding works, and that it will get the answer by calling the function on the collection's elements (the collection is a Functor, and the only thing you can do with one is `map` a function over it).

[of course this is assuming that `any` isn't implemented as `any _ _ = True`]

This advantage can be overstated and give a false sense of security, though. It’s true that for entirely generic functions, you can sometimes infer useful properties just from the type signature, but once you start getting any more specific types in there, all bets may be off. You said

[of course this is assuming that `any` isn't implemented as `any _ _ = True`]

but actually there are many more possibilities. For example, this function might return True if the provided data structure has exactly 5 elements, never using the provided (a -> Bool) function or mapping over anything.

you're right! but i think under normal circumstances it's fair to assume that the function actually uses all of its arguments. and i mean "uses" in a general handwavy sense, e.g. that it doesn't do `any f xs = length (fmap f xs)`, where `f` is technically used, but the results of applying `f` are instantly dropped.

For some, it is “as developers get more mature they start to prefer static typing”.

Almost all of your “whys” have sensible, practical, answers. The practical bit is the sticky bit that gets set when you get “older”.

"I joked with a friend that as people get older they start to prefer static typing."

I don't think you can tell that right now. Statically-typed languages have gotten much, much better over the past 30 years (progressively), and over the last 20 years we've all aged, you know, 30 years, so right now I think there's a lot of correlation there rather than necessarily causation. I have also switched to static typing as I've "gotten older", but I would still totally rate things in the order "1990 static < 2010 dynamic < 2020 static", even if I had to choose right now. Static was a real mess in the past.

It also isn't even necessarily big jumps that make that true as much as a steady development of innovations, since obviously it's not like all modern static languages are Hindley-Milner or anything. But a slow dribble of both little features and improvements in understanding of how to use everything over the years, like type deduction (getting rid of the usually-redundant specification of type on both sides of "="), getting away from the idea that OO === matching physical models, libraries that have learned to take more interfaces instead of concrete types, languages like Go that privilege composition over inheritance instead of the other way around and the general trend towards composition, getting iterators embedded more deeply into languages like C#, control flow improvements like usable threading methodologies ("share memory by communicating, don't communicate by sharing memory", and even as much as I dislike it vs. the alternatives, having async/await is better than not having any options even though I prefer Go-style threading by a mile), and so on and so on... a steady dribble of little improvements that one step at a time changed the cost/benefit tradeoffs of a static vs. dynamic language from clearly dynamic circa 2000 to fairly clearly (IMHO) static for any non-trivial code base in 2020. And that's before we talk about Rust or anything like that.

I agree and disagree. I love how you can do abstraction in Haskell based on the minimal interface. If it's "ring-like" or whatever you can define matrix multiplication. That can often come up useful, extending the power of existing functions.

But it means your web scraping code, crud app, {some other boring everyday app} or whatever is now adorned with all this deep mathematical complexity that if you just used nodejs or something it would be easier to understand.

Premature optimization is probably a good term for it, because the good think about haskell is it is easy to make refactoring. Make things specific now and more general later, and it should be backwards compatible for the most part.

But making things into "arrows" is part of the sport I think.

Prototyping or gluing components together is definitely faster without static typing.

I think this is a fault of language ergonomics rather than static typing.

If you are gluing components together, then surely the components have a common interface that uses compatible types. And surely you need to tell the runtime what those types are in some way, even if that is simply by writing them to return appropriate values.

In theory, a statically typed language with ideal ergonomics would make that as easy to specify as a dynamic language, but would have the benefit of warning you of mistakes as early as possible.

Of course, many statically-typed languages trade-off some amount of ergonomics for other features.

> If you are gluing components together, then surely the components have a common interface that uses compatible types

This is not guaranteed; for example, the representation of a JSON object is trivial in dynamically typed languages, because there are no type bounds.

Ease of metaprogramming is another. Possibly also debugging - I don't get powerful REPLs in the statically typed languages I've used, as much as those in the the dynamically typed language I use.

Concepts like these don't represent best practices for sure at large scale, but they do make things easier at least at small scale, and they don't need to be necessarily supported.

Taken to the extreme, Perl variable autoinitialization and context sensitivity are very convenient for 3-statement programs, but they'd be horror above that. It doesn't make sense for any language to try to support that.

In my experience when gluing things one needs at the very least dependent types to properly express relations. Without that the best hope is a good integration test, but with that in place static types for things that can be expressed in mainstream languages do not bring much extra value while contributing to the cost.

Recently I've become a bit jaded, because I see flaws and the like in every language I've used; I (like to think I) don't have a "blub" language.

Mind you I've never gotten along with pure functional languages. I've mostly done CRUD applications and I'm not sure functional languages are appropriate for that use case.

FP languages like Elixir are perfect for CRUD apps IMO (Clojure too but it lacks the runtime guarantees of Erlang's BEAM VM so to me that's a no-go).

Reason being: they are immutable in general but allow you escape hatches that you can relatively easily identify in your code if you need to troubleshoot.

Reply on news.ycombinator.com