
Haskell in Production - allenleein
http://felixmulder.com/writing/2019/10/05/Haskell-in-Production.html
======
Mathnerd314
All the interesting code is in the next post,
[http://felixmulder.com/writing/2019/10/05/Designing-
testable...](http://felixmulder.com/writing/2019/10/05/Designing-testable-
components.html).

I'm not sure why they use a generic monad rather than ST, they don't need
continuations for this.

The Reader monad with a big record is standard Haskell, it's basically what
GHC uses:
[https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea7682232...](https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea76822322b746a632778/compiler/utils/IOEnv.hs#L55)

data-has is less standard, it only seems to have been used seriously by one
project, which has a bug on file to stop using it:
[https://github.com/myfreeweb/magicbane/issues/20](https://github.com/myfreeweb/magicbane/issues/20)

But overall it's interesting, we'll see where the series goes.

~~~
microtherion
It's always good to see examples of how a language is actually used, rather
than just assertions of its superiority.

That said, if Haskell programmers truly consider this a superior and readable
way to write code would tend to reinforce my preconception of them as an
insular community elevating arcane jargon to a virtue (not unlike the APL
programmers of yore).

~~~
jeremyjh
Its strange how code written in unfamiliar languages is ... unfamiliar? The
Haskell in that post is bog-standard. The definition of "arcane" is not "I
don't know it".

~~~
microtherion
I've worked in a pretty wide range of languages. I think I know "unfamiliar"
and I can tell it apart from "arcane".

OP claims that "this article will emphasize writing easy to grok, maintainable
code". The definition of "easy to grok" is not "once you've bought into the
entire mindset, this will be obvious to you".

~~~
mbrodersen
> I've worked in a pretty wide range of languages

Which languages are those? If the answer is "N flavours of imperative/OO
languages" (like C/C++/Java/C#/Ruby/Javascript) then you really haven't worked
in languages _different_ enough for you to truly learn anything new. The rule
is simple: if learning a new language is easy, then there isn't much new in
the language for you to learn (except a different flavour of syntax or
whatever).

~~~
microtherion
True, most of my work was in imperative/OO languages, though the
imperativeness ranged from "global variables for everything" to "No global
state, predominantly immutable objects, predominantly single assignment".

But I've also worked in Prolog and SQL, and dabbled in languages like UNITY:
[https://en.wikipedia.org/wiki/UNITY_(programming_language)](https://en.wikipedia.org/wiki/UNITY_\(programming_language\)),
so I have some degree of openness to different paradigms.

~~~
mbrodersen
> so I have some degree of openness to different paradigms.

That's great! I truly believe that learning new hard stuff is how a software
developer goes from average to great. If you learn a little bit every day then
after 5 years you will be SO much better than the average guy/gal sitting next
to you.

------
gip
> Haskell is great for business and great in production

I disagree. It's a beautiful language but it lacks a lot of features to make
it useable at scale. And in my experience Haskell engineers are extremely
smart but the environment/culture they create makes it difficult to foster
team spirit.

I've been in 2 companies in the last 4 years who initially used Haskell in
production. One has transitioned to Go and the other is rewriting the codebase
in Rust.

~~~
maximente
in my (limited) experience, Haskell projects (and to a slightly lesser extent,
functional programming projects) work best when thoroughly planned out in
thorough whiteboard/spec sessions and are then implemented by a couple of
gurus responsible for the code, who work almost exclusively in functional
languages in their day to day. there seems to be a need for way more thought-
per-line-of-code in Haskell/FP projects.

many engineers (and businesses!), culturally, come from the opposite angle
(legions of generally pluggable engineers on java/python/golang plowing
through tickets/features). that's fine, but it isn't super amenable to the
Haskell world, because IME non-imperative setups require different mode of
thinking about design, so harder to drop in and crush a ticket. i wish i could
explain this more, but i'm struggling to articulate with examples.

i think the thorough types really help you get up to speed on data structures,
but unless you are in a functional mindset pretty much exclusively, your (my?)
brain spends a lot of time un-imperative-ing itself. also, laziness can be a
factor, so need some expertise there.

it also helps to have conventions e.g. old school java (are we point free, or
not? etc. etc.)

all in all i think it requires a lot of discipline that can easily break down,
whereas some of the popular imperative languages you can still sort of plug
along (=> punt the technical debt) despite that.

~~~
dukerutledge
> all in all i think it requires a lot of discipline that can easily break
> down, whereas some of the popular imperative languages you can still sort of
> plug along (=> punt the technical debt) despite that.

Interestingly I have the exact opposite perspective. Writing imperative or OOP
code requires me to be excessively disciplined. It is extremely easy to build
un-maintainable spaghetti. There is a whole cottage industry of methods for
your discipline of choice: Clean, SOLID, TDD, etc. All these disciplines seem
to boil down to the same systemic result, push effects to the edges of you
program so you can more easily test, evolve and maintain. Functional
programming (of the typed variety) tends to allow me to write garbage code,
that is testable and can be easily evolved and maintained because the paradigm
encourages me to be a good actor.

I've refactored production code in imperative languages and typed functional
languages and only one of them allowed me to make HUGE sweeping changes with
ease and high confidence.

~~~
weberc2
> There is a whole cottage industry of methods for your discipline of choice:
> Clean, SOLID, TDD, etc.

I'm not a big OOP fan, but I'm pretty sure Clean and SOLID are principles (or
sets of principles), while TDD alone is a practice. I'm also not very familiar
with Clean or SOLID, but I'm pretty sure they apply to Haskell as well, and I
would expect that Haskell enthusiasts would ordinarily boast that Haskell
allows (or encourages) them to write code that is more SOLID with less effort
than other languages.

My criticism of Haskell is that there tends to be an obsession with writing
the most SOLID/DRY/etc code possible at the expense of productivity. It's a
code golf / ego culture.

Yes, this is cultural and not "built into the language" (quotes because I
doubt there's a clear distinction between a programming language's culture and
the language itself, but that's a debate for another time), but you can't
unplug from the culture, because you need the ecosystem to solve any
nontrivial problem (so you still have to interface with overly clever code).

Further, even if you could unplug from the culture (perhaps by writing
everything in-house under your own improved culture), there are still no
'rails' that encourage naive, flat-footed, dumb code, and that's the kind of
code you want 99% of the time. As far as I'm aware, there isn't even a clear
standard for writing clear, naive code in Haskell.

~~~
ulucs
SOLID applies only to OOP. Not using classes trivially satisfies the
requirements of every letter. Hell, most design patters are trivial if you use
functional programming.

------
seddona
We are a YC company doing very well, all our back end code is written in
Haskell. We have produced a lot of functionality with a relatively small team.
I would say we are existence proof that Haskell is good for business.

~~~
StreamBright
For the problem you are solving and at your scale. Things start to change when
you need to hire n+1 teams or engineers quickly.

~~~
dllthomas
They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy.
But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.

~~~
StreamBright
I think so.

[https://insights.stackoverflow.com/survey/2019#technology](https://insights.stackoverflow.com/survey/2019#technology)

~~~
dllthomas
That doesn't speak to Haskell. You can say that's because there's not a lot of
Haskell and that's likely _at least_ partly true. But the difficulty hiring
for a position depends on the number of people qualified _and_ the number of
other roles competing for those people. The fact that _both_ of those numbers
are smaller for Haskell than (say) Java doesn't tell us whether it'll be
easier to hire for Haskell or Java.

~~~
StreamBright
True. Lets check the numbers. 90,000 developers took the survey.

Java: 41.1% 36990 developers

JavaScript: 67.8% 61020 developers

Haskell: 0% 0 developers

Jobs:

Java: 73,447 jobs

JavaScript: 59,647 jobs

Haskell: 492 jobs

[https://www.indeed.com](https://www.indeed.com)

Given the numbers, as a hiring manager, I will never ever suggest to any
company to try to use Haskell or hire Haskell devs. I know many developers who
use it though. They sucessful with what they are doing, turning business
problems into Haskell problems and solving those. Sometimes patch the
compiler, sometimes write a completely new one. As a tech leader I do not want
to have these problems, even if I could hire enough people for projects (which
I can't). I always like to read blogs about what is going on though. It
satisfies my scientific curiosity but that is it.

~~~
dllthomas
Those are numbers. I'm not sure what they say, ultimately. If we believe them,
then we can conclude: there are substantially more Java programmers, but
substantially more unfilled Java positions, but a much bigger (... infinite)
ratio of Haskell job to Haskell programmer, etc, etc. I'm not sure which of
those wind up being most important.

I _can_ say what I've said - that my experience of trying to hire the next
couple Haskell programmers has not been harder than my experience of trying to
hire the next couple JavaScript programmers.

There's also a big question of the quality of the survey, and how
representative it's likely to be of your company's overall hiring pool - you
say you have many Haskell programmers in your network, and your network is
probably substantially fewer than 90k individuals, so something seems amiss.

I'm not interested in getting drawn into the rest of your ranting.

------
KirinDave
This is a great guide and sound advice. And hopefully in a year we'll see the
community converge on Polysemy (or fused-effects for performance) to make this
strategy even more natural.

~~~
runeks
Polysemy still appears mysterious to me.

I would absolutely _love_ an article that translates the “Designing Testable
Components”[1] part of this article into its Polysemy equivalent.

[1] [http://felixmulder.com/writing/2019/10/05/Designing-
testable...](http://felixmulder.com/writing/2019/10/05/Designing-testable-
components.html)

------
MisterOctober
Always nice to see Haskell at work. I haven't learned the language myself yet,
but I absolutely love postgREST, which is implemented in Haskell.

------
leshow
I'm not sure why this post is getting so much hate, it's well written and I
really enjoyed reading it. Thanks!

~~~
rawburt
People seem to hate Haskell because it's not [popular-language-that-they-use].
To think that Haskell is used, liked, and works, seems to upset people who
don't like, use, or understand Haskell. Or, so it seems.

------
whalabi
How is such an obscure language - with associated difficulty in finding
talented engineers - ever going to be a better choice than a more mainstream
language, which probably has many of the same features?

~~~
mbrodersen
> with associated difficulty in finding talented engineers

This is a myth. There are now _many_ experienced developers who currently
can't use Haskell in their day job but would love to. If I decided to start
another business, picking Haskell would give me access to a lot of top talent
who would otherwise not be interested.

------
dmitriid
How long does it take the “new programmers who have not worked with Haskell
before” to learn and understand all the ASCII-art in the example code? How $
differs from <$ differs from & differs from .

On top of trying to remember that <> is string concatenation and >>= and <\-
have something to do with monads.

~~~
shantly
I still can't understand why Perl is easily dismissed as "LOL line noise" but
Haskell's apparently fine. At least dipping into Perl you can take on the line
noise slowly so you have time to absorb each new technique, and you _can_
write it just fine with hardly any of that if you want, and it won't hurt a
thing—Haskell seems to dump all that on you up front, and it seems to require
it, idiomatically. It's very off-putting.

~~~
tome
It's because Haskell's type system at least helps you avoid getting the line
noise _wrong_. If you have to refactor some complicated line noise then the
compiler holds your hand.

~~~
dmitriid
What would an error look like if I misused $ or &?

And yes, compilers hold a user’s hand in most languages (including PHP with
type hints :) ).

~~~
lalaithion

        • Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’
                      with actual type ‘[Integer]’
        • Possible cause: ‘map’ is applied to too many arguments
          In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’
          In the second argument of ‘($)’, namely
            ‘map (+ 2) & map (* 2) [1, 2, 3]’
          In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

~~~
dmitriid
In my opinion this doesn’t help much.

~~~
mbrodersen
Of course not. You have to learn how the type system works to get it.

------
slaymaker1907
I really wish Java had associated types and static methods as parts of
interfaces (i.e. constructors as part of the interface). Those two features
make complex architectures much easier to design and use.

~~~
chrisseaton
Interfaces can have static methods.

~~~
james-mcelwain
I believe they mean static methods as part of the interface signature, e.g. to
define constructor/factory methods.

AFAIK there are issues with how Java handles dynamic dispatch that prevent
this.

~~~
chrisseaton
What would calling such a method look like?

~~~
TheCoelacanth
Imagine that Collection had a static method `empty` that created an empty
collection of the appropriate type depending on the type you are assigning it
to, e.g. `List list = Collection.empty();` would create a list, `Set set =
Collection.empty();` would create a set, and so on. This would be fairly
similar to how things work in Haskell.

~~~
chrisseaton
If you know you’re creating a List (it’s there on the LHS) why not write
List.empty()?

~~~
james-mcelwain
Here's how it works in Rust. You can imagine this working in Java with reified
generics: [https://gist.github.com/rust-
play/214adf5bd15b18ec2d5c63d97f...](https://gist.github.com/rust-
play/214adf5bd15b18ec2d5c63d97ff8ba2c).

~~~
verdagon
Fascinating! What are the uses of something like this? Is this at all related
to concepts or metaprogramming?

------
digb
If I remember correctly, Co-Star, the horoscope app, runs Haskell on the
backend.

~~~
senderista
Boy those guys must be laughing at their customers.

------
verttii
This is an incredibly good series. Just what I've been looking for. I'm
writing a Servant API myself and this really explains a lot of the fundamental
concepts in plain English.

------
dmix
> We tried a lot of different patterns - readers, handlers, MTL, and tagless
> final.

Is there any books or long form articles digging into these different
approaches? I know basic Haskell and heard of these different patterns a few
times. I'm curious how it looks in a larger Haskell project and what the
pros/cons are of each, and general popularity.

Edit: I see the next article in the series has more real code examples

------
rpmisms
The more I see it in use, the more I want to learn Haskell, but I can't think
of a practical reason to do so.

~~~
mbrodersen
Learning things is how you keep your brain sharp.

~~~
rpmisms
I need to get halfway fluent in JS first, but good point.

~~~
mbrodersen
Once you get there I recommend then learning Typescript (Javascript with
types) and compare the experience with Javascript.

------
axilmar
The amount of knowledge required just to have a clean design o the simplest of
things, i.e. a few functions that add and delete users is very big; almost all
of Haskell's important parts need to be known.

Is that good? for me, it's an obstacle. I can't expect all the developers that
come and go to have a perfect understanding of monads in order to
use/debug/extend such code.

And what did Haskell actually buys us here? my apologies for being skeptical,
but it doesn't seem to buy us anything...in other languages, such things as
creating a user, deleting a user, logging actions requires a lot less
boilerplate and complexity.

------
c3534l
Everyone in the comments either doesn't like Haskell, because it's hard and
different or niche or whatever, so they think Haskell is bad for production
even though they don't code in it and haven't worked at a place that used it
extensively.

The other group of people in the comments are people who love Haskell and are
happy to have validation from the OP.

But I'm not really any wiser. I like Haskell, but I work in DevOps and the
language simply isn't relevant there.

~~~
platinumrad
Everyone... except for the top comment?

------
mcmayer
It's interesting to watch the wonderfully meandering train of thought(s)
triggered by a success report of using a non-mainstream programming language.
So let's meander some more...

The strong reactions are understandable. New programming languages are added
to the zoo faster than ever before. And within each language there's a steady
influx of new frameworks (angular1, angular2, react, vue, ...) each with a
learning curve. It's a challenging environment, and it feels like it's getting
exponentially harder as time progresses. One must resist the trap of following
every silly new idea.

So why bother spending even an afternoon with Haskell? Spend an afternoon
playing with Python and you'll be writing code the next morning. Spend a day
with Haskell and you'll have more questions than answers.

The fundamental problem is, most likely, the new paradigm. Functional
programming takes some time getting used to. Sure, the functional style is
creeping into mainstream languages, so most of us have seen and used it
already. But _pure_ functional programming is another level. Broadly speaking,
everything is a function, a function in the mathematical sense: Same input,
same output. Everything is immutable, it's all about chaining pure functions.
Crazy, right? Why would you subject yourself to such rigour?

I'll argue that pure functional programming has something to offer that is
more relevant than ever. 1\. Pure functions are easy to test. Same input, same
output, that is a strong guarantee. It'll still be a challenge to thoroughly
test every single function, but at least each test is meaningful because there
are no interactions with anything outside the function. 2\. Pure functions are
easy to compose and parallelize. Single-thread performance is hardly ever a
relevant benchmark anymore. Sure, C is faster, but good luck trying to
parallelize a complex C program. (The worst thing I can imagine is having to
debug messed-up, multi-threaded C++ code.) 3\. There is structure in how to
compose pure functions, and it's structure in the mathematical sense, not in
the fuzzy Gang of Four pattern sense. Much of the 'arcane', 'academic' jibber
jabber is exactly about these mathematical structures. The power of having a
rigorous method for structuring programs is immense. It really is. The hurdle
is not a high as it may seem (unless you have a low affinity to maths - im
which case you probably shouldn't be programming computers anyway). 4\. Pure
functions are easy to refactor. (See below.)

I'll also argue that strong typing has a lot to offer and will become more
mainstream. 1\. Make the compiler your friend, not your enemy. Strong types
glue the functions together in just the right way and prevent me from making
silly mistakes. 2\. Business logic can be encoded in a compact and transparent
way. Changes to the business logic (and it always does change, doesn't it?)
are also compact and transparent. 3\. Refactoring is just ... wonderful.
Strong types combined with pure functions, that is a magical combination.
Change the type and let the compiler tell you what the implacations are. As
there are no side effects code can be refactored with confidence. It is a
vastly different experience from any OO language.

Now, finally, to Haskell: It can be characterized as a strongly typed, lazy-
evaluated, garbage-collected, pure functional programming language. (Lazy
evaluation hasn't been mentioned, yet. It's something that needs to be
understood and considered in order to write efficient code.) In "language
design space", something like Haskell must exist and will always exist. (I say
'always' because maths has something eternal about it and pure functional
programming and strong typing have solid mathematical underpinnings.) And in
this "language design space" Haskell dominates. Contrast this with the
compiled, weakly typed, imperative, low-level languages like C, C++, Golang,
Rust. I have a hard time picking amongst those, but I believe everyone should
know at least one of them.

So is it worth learning Haskell? I tried to argue that it's not a fad and the
concepts are fundamental and increasingly important. To me, personally, it
looks like a an investment I can benefit from for decades to come.

As a business, do the advantages outweigh the costs and risks? We all know
that corporate culture often stands in the way of change. One root cause is
the asymmetric payoff: A thank you if it goes well, and job-loss if it goes
badly. In such an environment inertia is the rational choice. - But if your
company truly believes to be an innovator, or leader in the field, or seeks to
gain an edge over the competition, then Haskell should be on the list of
things to try.

------
jonny383
Advice for people using Haskell in "production": Don't. Save not only yourself
the disappoint, but every other stakeholder around you. Use something tried
and tested.

~~~
mbrodersen
Let me guess: you have never programmed in Haskell?

~~~
jonny383
I have programmed in Haskell. I have programmed in assembly. I have programmed
in just about every language in-between. Haskell is at best, a sophisticated
toy suited to a small subdomain of problems.

Have you ever tried to roll Haskell into production, when compared with
something like C# or Java?

~~~
g_delgado14
What was your experience like rolling Haskell into production?

~~~
jonny383
Cabal is probably the most unsuited packaging system for production software.
It has no useful test integration nor freezing ability. Tried to change
profiling? You're in for a bad time. What about deployment. Want git? Nope.
You can't. Want to build artifacts? What is this, TypeScript?

------
MuffinFlavored
> Haskell is great for business and great in production.

Hot take: no it isn't. It is extremely hard to learn, has an extremely
confusing + needlessly complicated syntax and I question the payoff immensely.
I question the well-being of anybody who subjects themselves to the pain and
torture that is Haskell.

If I stood up in a corporate business boardroom meeting for tech analysis on a
new project and said "I want to write it in Haskell", I'd get laughed + kicked
out.

~~~
rifung
> It is extremely hard to learn, has an extremely confusing + needlessly
> complicated syntax and

I agree with your other points but what's wrong with the syntax? I actually
really like the syntax for the most part

~~~
olah_1
>but what's wrong with the syntax?

I'll just link to this blog about readable Haskell. If everyone followed his
advise, it would be much better.

[http://www.haskellforall.com/2015/09/how-to-make-your-
haskel...](http://www.haskellforall.com/2015/09/how-to-make-your-haskell-code-
more.html)

~~~
PeCaN
Note that this is to make Haskell more readable _to non-Haskell programmers_
(which is a bit of a weird goal IMO). It is not for readable Haskell in
general. Advice like "not using $" just makes code _less_ readable if you're
familiar with Haskell and is quite frankly just bizarre. I do not think you'll
find many programmers, Haskell or otherwise, who find lots of nested
parenthesis to be the paragon of readability.¹

If the goal is to show snippets of cool Haskell code to other people this
article is… fine I guess? But I don't think it's good for much more. Not even
for teaching Haskell, since people should probably learn the language as it is
used instead of some arbitrary "more readable to non-Haskell programmers"
version. Using do-notation is probably even counterproductive for teaching
since it obscures what's actually going on.

Honestly this sentiment from the Haskell community that Haskell is somehow
bizarre and impenetrable to outsiders and needs to be somehow watered down so
that normal people can understand it just feels extremely elitist and if
anything only scares people away from Haskell.

―

¹ Lisp programmers aside, but even then in Lisp you're basically just drawing
a tree and so the parenthesis kind of fade away, but in languages with infix
syntax and operator precedence you can't ignore them.

~~~
empath75
> Honestly this sentiment from the Haskell community that Haskell is somehow
> bizarre and impenetrable to outsiders

They’re not inventing that from thin air. I can understand Haskell with a
great deal of effort, but it certainly requires a great deal of effort.

My wife is a non-programmer. She knows nothing about code. I could explain
what the go code I write does in a few minutes and she could follow it with a
minimum of hand waving. I don’t think I could explain any non trivial Haskell
code in hours to even professional programmers

~~~
mbrodersen
I have explained Haskell code in a few minuts to professional programmers and
they got it. It took a bit longer to explain monads but it wasn't hours.

------
wellpast
I will probably get stomped on for this but to me it's a giant elephant in the
room.

When that one purist on the team proposes mandating having 100%, 80%, or _any_
hard number of unit test coverage, most sane people tend to disagree and
understand its wild impracticality and counter-productivity.

However - when one (ie, a Haskeller) says that the code must universally pass
100% _strong static type verification_ coverage -- arguably SO MUCH worse
cost/benefit than unit testing -- and you say "no that's impractical" it's
suddenly a different game.

The elephant in the room is this. Haskell and strongly typed languages are
highly impractical, academic pursuits. They do not at all respect the dynamism
of the real world. You can certainly build production systems in any language
including Haskell but by picking Haskell you are throwing sticks between your
legs unnecessarily.

~~~
astuary
Just because an expressive static type system is available, doesn't mean you
have to use all of its expressive power. There's nothing stopping you from
writing your system using little more than String, Int, lists, IO etc. Of
course, you probably have a higher chance of bugs, but that might be the right
tradeoff for your usecase.

I agree that haskellers have a tendency to disregard the cost of using
sophisticated type machinery. Which is unfortunate because haskell's greatest
strength (IMO) is its ability to opt in to strong static verification for the
10% of code where it provides the most value.

~~~
wellpast
> Just because an expressive static type system is available, doesn't mean you
> have to use all of its expressive power. There's nothing stopping you from
> writing your system using little more than String, Int, lists, IO etc. Of
> course, you probably have a higher chance of bugs, but that might be the
> right tradeoff for your usecase.

This is not accurate or prove me wrong. Opting out of Haskell's type system
may be "do-able" but only in a sense. And even so the programming ergonomics
will be terrible vs. a language designed with typelessness in mind.

~~~
rawburt
This is opinion. Haskellers have opinions too. Whatever you like and whatever
gets the job done: bravo

~~~
wellpast
Nope. Not everything is "every way is just as good as the other".

>Whatever you like and whatever gets the job done: bravo

"The job" is this: it's an optimization problem of maximizing development
throughput. That's the job in the business world, at least.

There can and should be a conversation about doing this job well.

Mandating strong static typing across the board is exactly what Haskell does.
My claim is this is death to productivity/throughput when you compare it to
alternatives. The death part can be argued --the best leg Haskellers can stand
on afaict is that _overall_ throughput is increased due to decreased attention
to the kinds of bugs prevented by strong typing. This needs to be proven by
them.

Otherwise -- by definition -- strong type systems are asking you to take
special care to meet a type proof that is not necessary to do to implement
correctness in other PLs.

Every time I've implemented a solution in a strongly typed system I always run
into the type prover complaining about something that _Might_ be but that I
can prove is not the case. Here is the limit of the type checker - it is
simply not aware enough to understand what we're doing. So it puts needless
requirements left & right. This is hostile to productivity.

Now you go.

~~~
hderms
I believe you're exaggerating the frequency that the compiler rejects valid
programs. It happens, but no more frequently than random runtime type errors
occur in dynamic code.

In any case, one can just as easily argue that the value of static types come
not just when the code is first written, but under the legion of modifications
that need to occur. Not to mention how self documenting it is which also aids
modification.

Some people just don't like static typing, which is fine, but making the
statement that it's categorically worse is hard to defend.

~~~
wellpast
This is not an opinion thing. If you’re saying that type checkers _can_ reject
code at no worse than the same rate as dynamic runtimes then you are just
plain wrong. In any case the burden is on you to show this with the slightest
sketch of a proof to how this is possible. And what is this magic type system
that can do this, bc it sounds like some super AI.

The reason I’m confident in my objections is because this is what I get from
static typing fundamentalists: never a concession as to its cons and costs. Is
it that static typers can’t _see_ the relative costs bc they are not using the
full power of dynamic languages?

~~~
mbrodersen
> the full power of dynamic languages?

There is nothing you can do in a dynamic language you can't do in a typed
language. There is no "special power" that only dynamic languages have. If you
truly believe that dynamic languages have "special powers" that typed
languages can't have then I recommend studying a bit of basic computer
science. Starting with the Turing Machine or Lambda Calculus.

~~~
wellpast
> There is nothing you can do in a dynamic language you can't do in a typed
> language.

There is nothing one can't do in assembly that you can't do it in a higher-
level PL.

The argument is not what one can or can't do.

The argument is that one world (dynamism) _allows for_ higher throughput than
a static-checked environment. This can be discussed but the "can do" argument
is of no interest.

You "can do" anything given enough time. One doesn't even need a programming
language. You can manually execute instructions by hand. But this is not the
discussion.

~~~
mbrodersen
> The argument is that one world (dynamism) allows for higher throughput than
> a static-checked environment.

I have programmed in both dynamic languages and typed languages for 35+ years.
And I am most definitely more productive using a typed language. Otherwise I
wouldn't. So I wonder why our experiences are so different?

