Haskell is our first choice for building production software systems(foxhound.systems) |
Haskell is our first choice for building production software systems(foxhound.systems) |
I recently tried to compile haskell-language-server and stack from sources. 157 and 168 (or something) dependencies, full of redundant esoteric bullshit, compat packages, lifted crap, etc. It is even worse than J2EE where it was the same redundant wrapping and indirection, but brain-dead straightforward verbose crap.
To use Haskell correctly, like the classic xmonad and similar projects, requires discipline, knowledge and good taste for just right abstractions, like Go stdlib or Scala3 standard library.
Yes, it doubles development time, which must be spent on understanding anyway, but fast food fp code, full of redundant abstractions, is a worst nightmare to maintain.
This comment reads like someone seeing the worst of J2EE, and going back to C++. I'd characterize haskell as having the type system that Java wishes it did.
Why are you trying to judge how haskell should be written for your use case by looking at haskell-language-server, stack, and xmonad? Those are the domains of haskell experts -- one is a language server, the other is one of the pre-eminent build tools, and the other is tiling manager.... Are any of those your use-case?
There are real problems with haskell, and forcing you into complexity is not one of them -- a steep learning curve (for certain concepts), hard to debug space leaks, and a relatively small ecosystem are the biggest issues.
These kinds of arguments are particularly lazy. Of course, Haskell's ecosystem is not so large that it's trivial to find a well-maintained, high-quality version of a library that meets one's other criteria. Programmers of a particular language are at the mercy of that language's ecosystem.
This line of reasoning reminds me of how C++ programmers would deflect criticisms of problematic features by arguing that one could use only the features that one wanted (thereby effectually creating or curating their own sub-language) and only choosing dependencies that were equally written in that sub-language. So easy!
Hum... Knowledge and an acquired taste, yes. You'll need those. Discipline not. Discipline is exactly what Haskell doesn't require.
Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers rarely doing in practice.
Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.
To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell.
>The presence of monads does not necessarily mean side effects
The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own.
For example let's say I have a maybe monad that will never produce "Nothing."
b :: int -> Maybe Int
b x = Just x
Nothing >>= b
This is overlooking the cost of developers, which greatly outweights the hardware's unless you are Facebook.
The "overlooking" part you filled in yourself in bad faith and bad reading comprehension, as the author actually does acknowledge that the observed hardware savings are small compared to the cost of hiring programmers.
The commenter was railing against the abstractions the codebases used, not the underlying packages actually. I don't want to get into explaining it, but it is very easy to write production-ready simple haskell, but also very easy to spend hours building abstractions in the type system (normally) to build yourself a straight jacket. OK so if I explain it a little bit, there are at least three ways that have surfaced in recent time (lets say the last 5 years) on ways to structure large effectful haskell codebases (which is most software you'd want to write).
- Everything in IO (just do everything in the IO monad)
- monad stacks & transformers
- The ReaderT pattern
- Effects (free/freer, polysemy, fused-effects, etc)
All of these approaches have high quality libraries to support their use, but you could stay at that first one (everything in simple IO) and be very happy for a very long time.
I'd argue that C++'s problematic features are of a different nature -- when one of them goes wrong you normally have a much more disastrous outcome (whether at runtime or when you're trying to grok the code). For example compare C++'s templating system to haskell's support of generics for example, one is infinitely safer to approach and easier to understand than the other for the simple case, due to how the languages are built (i.e. no inheritance). Haskell it's more up to you to strangle yourself with the complexity -- the necessary abstractions are pretty simple (typeclasses, monads are simple in use, if not in concept), but the unnecessary abstractions basically scale to PhD.
I will absolutely concede that Haskell does encourage you to reach for higher and higher levels of abstraction for diminishing returns. But I will take Haskell's abstractions over Java's abstractions any day of the week, even though Haskell's can be more inscrutable.
Let's see if FoxHound is around in 1-3 years :)
Never implied anything was bad or good. Just saying that Haskell style programming does not push side effects to the edge.
>I don't think you can expect to push everything out to the edges, for example partiality.
Of course you can't push everything to the edge, but haskell style programming doesn't attempt to do this. It embraces the side effects and no one actually pushes anything to the edge. Partiality was just an example, the point is the bind operator will have a side effect on b so you can no longer treat the output of b as a pure black box. People who use haskell use the bind operator all the time indicating that their code is littered with side effects. Which again isn't necessarily bad, it just is what it is.
>However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.
But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation.
Again if you avoid using monads as much as possible in haskell you are pushing side effects to the edge. If you don't do this, which is basically what most haskell programmers end up doing, then you are not pushing side effects to the edge.
Yeah, "functional core/imperative shell" or "pushing IO to the edges" is a weird myth. Really the strength of Haskell is "functional core/IO code carefully threaded through functional core".
What's a good descriptive slogan for that? "Functional pipework/imperative reactants", invoking chemical engineering?
To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell.
Yeah agreed, it's just a style of programming within the functional paradigm. Not necessarily bad or good.
the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1!
In contrast Haskell is often self-taught which gives a very different set of incentives and motivations.
As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.
Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.
For what it's worth, I believe modern C++ compilers give much better error messages than older ones.
In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher.
But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)
how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.
Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.
For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soon, one in python and one in ocaml. Perhaps that will provide a datapoint about learning the languages but maybe there will just be a lot of selection bias or library or environment or teacher differences. And how easy it is to learn a language probably isn’t the main datapoint to care about anyway.
You cannot get mad at errors you don't know about.
Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object"
Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
But I've worked with people who saw all compiler errors as things of the devil and wanted to defer as much as possible to runtime.
When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria:
0) checked static typing
1) ADTs (that are reasonably easy to use, read and write)
2) pattern matching (no way I'll get all the if/else right)
3) reasonably easy to write static const (pure functional) code
4) memory-safe
I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4).
While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone.
Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.
I know not much of Java, but my sentiments concerning C++ are even worse.
I do not regularly program in Haskell and far more often in Rust.
For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...
It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.
Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).
Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".
Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster).
Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types.
Bypassing it by casting always causes headaches.
This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time
Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows
What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?
The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits.
There's absolutely nothing wrong with that. It's a bit emotional, but those exist for a reason. If you consider that idea libellous, you can always cite PR motives for plausible deniability and point at this HN story as evidence.
[0]: Elm, by the way, strikes me as borderline with regards to the bounds of reasonableness, considering the state that community is in. As such, it's more evidence your left (right?) metaphorical hemisphere may have had a finger on the scale.
Here, I've fixed the title
Haskell has the type system Java wishes it did, and half of the reason languages like Rust are interesting is because they've learned from Haskell (which is the point of Haskell, a research langage, though it happens to also be a pretty darn good language for building practical things). Simple basic data types like `Maybe t` and `Either l r` are such a revelation that you wonder how you lived without them.
I've shared this anecdote before, but Option<T> in Java is an example of the blub paradox[0], and discovering Haskell and finding out about Algebraic Data Types (ADTs) and the Maybe type cured my blub. The crux was this: Option<T>s seems to "infect" any codebase you use it on, because you realize that anything can fail and be null -- living in java land made it seem like it was out of place it's actually Option<T> that is right -- if you allow nullable types in your code base, or you do operations that can fail, properly representing that failure is the right decision.
Without over stating some of the best features of Haskell are:
- Compile time type checking (this cannot be understated) and non-nullable types
- Expressive and simple data type creation via `data`, `type`
- An excellent system for attaching functionality and composing functionality to data types via `typeclass`es and `Constraint`s.
- An emphasis on errors as values (unfortunately exceptions are in the language too, but you can't really stop them from existing)
- Forced delineation between code with side-effects and code without (this results in some complexity if you come from a world with side-effects everywhere and no control)
- Fantastic runtime system with good support for concurrency, parallelism and shared memory management.
- Very easy refactoring (if you're not adding any complexity/abstraction) because you can just change what you want and let the compiler guide you the rest of the way.
Haskell has it's warts (hard to debug space leaks, relatively small ecosystem, the ability to drown yourself and your team in abstraction), but it's just about the most production-ready research language I've seen.
Whether or not you like it, the likelihood it's already improved your life in whatever language you're using is very high.
[0] http://paulgraham.com/avg.html
(Scroll to "The Blub Paradox", about a third of the way down.)
Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit.
Writing servant handlers can also feel mostly imperative depending on how much you use `do`.
Sure, Haskell's type system is nicer, and the error messages are, I'm sure, more helpful (although the Java/C++ ones make sense when you learn what they mean).
There is an example of domain modelling in Haskell:
type Dollars = Int
data CustomerInvoice = CustomerInvoice
{ invoiceNumber :: Int
, amountDue :: Dollars
, tax :: Dollars
, billableItems :: [String]
, status :: InvoiceStatus
, createdAt :: UTCTime
, dueDate :: Day
}
data InvoiceStatus
= Issued
| Paid
| Canceled
Quote:
Modeling domain rules in the type system like this (e.g. the status of an invoice is either Issued, Paid, or Canceled) results in these rules getting enforced at compile time, as described in the earlier section on static typing. This is a much stronger set of guarantees than encoding similar rules in class methods, as one might do in an object oriented language that does not have sum types. With the type above, it becomes impossible to define CustomerInvoice that doesn’t have an amount due, for example. It’s also impossible to define a InvoiceStatus that is anything other than one of the three aforementioned values.
Other brief rebuttals:
Haskell has a large number of mature, high-quality libraries
Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate
Haskell has a large community filled with smart and friendly people
Of course there are other parts of Scala, Haskell and similar that require more mental gymnastics than I'd like, such as composing asynchronous operations; flatMap and monad transformers may be "elegant" once you really understand them but damn is async/await easier to just write and move on with your life.
In the end the insecurities and failures of snarky commentators don't matter to others who are in the arena solving real problems in production with an unsexy language.
Really? You comparing apples with oranges? Why not, if you're at the step of comparing compiled versus interpreted languages, compare it with Java too?
Now, do the same comparison versus C++, let's see who wins when talking about speed.
Sounds a lot like Haskell with Prolog...
“ Curry is a declarative multi-paradigm programming language which combines in a seamless way features from functional programming (nested expressions, higher-order functions, strong typing, lazy evaluation) and logic programming (non-determinism, built-in search, free variables, partial data structures). Compared to the single programming paradigms, Curry provides additional features, like optimal evaluation for logic-oriented computations and flexible, non-deterministic pattern matching with user-defined functions.”
http://chriswarbo.net/git/warbo-packages/git/branches/master...
You might like the Mercury language too: https://mercurylang.org/
Here is the paper by Kiselyov: http://okmij.org/ftp/papers/LogicT.pdf
And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can't say where or how it is being used because they don't know...just that at some point in the past, someone emails were exchanged between someone@bignamecompany.com and someone@haskell.org, and now there is a piece of copy on the Haskell website that disingenuously claims BigNameCompany is powered by Haskell!. Who cares how pervasivly it is used...if someone writes a config parser with Haskell, all of a sudden we can claim that BigNameCompany would fall over on its face if Haskell wasn't there protecting it.
Come on. Nobody cares that Haskell is your secret weapon if you've never overcome an opponent with it. Or built an entire profitable company on its back. All these types of posts do is fake an authority so you can jump straight to your fallacious argument by authority.
If you want to argue the merits of your favorite language, then do it. Don't make us sit through an argument about how your language makes you special when you aren't even noteworthy enough for a 10 sentence Wikipedia blurb. There are a lot of valid and powerful technical arguments in this article, but they're ruined by framing them all around the premise that we care about how it makes you and your startup special.
It requires a lot of effort to learn, development tools are scarce, and you can't easily hire a new worker simply because it's minor.
Eventually, original developer left the company for one way or other, leaving a code and half baked documents only the early developer fully understand. Good luck maintaining those software. You can't. It's either abandoned or replaced.
I would prefer a more stable platform designed for engineers , something like Clojure but with types. Ocaml has a small community and Scala brings unnecessary complexity with its support for OOP.
It looks to me like they would satisfy the same points that the article makes.
Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.
The result is that "the Haskell way" can seem a little more intimidating than the more "pragmatic" approach of MLs.
(I write this as someone who writes a lot of Haskell, and dabbles in StandardML!)
I see the corporate aspect of F#, but can you elaborate on what you mean by "special" about Haskell?
(Or with many other great options)
I've basically traded away some nice abstractions (functors, monoids etc) for the ability to debug error messages more easily, and not have to convince people to learn/support an obscure language. Good deal IMO.
> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development.
Many programmers find that Java or C++'s static type system, in conjunction with with compile-type time checking feels like an annoyance. Unlike... the very same statement about Haskell? That's... that's quite a weak claim, to say the least.
> a signature like Int -> Int -> Bool indicates that a function takes two integers and returns a boolean value... this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does. For example, one would not use the type signature above when looking for a function that manipulates strings, decodes JSON, or queries a database.
So... Type signature `Int -> Int -> Bool` can be used for a function that does any of the following things: manipulates strings, decodes JSON, or queries a database? How does that make it easier to deduce what a function does by "looking only at type signature"?
> Another feature of a pure functional programming paradigm is higher-order functions, which are functions that take functions as parameters.
As in: available in almost any language these days, and not exclusive to a "pure functional programming paradigm".
> One of the common development workflows we employ is relies on a tool called ghcid, a simple command line tool that relies on the Haskell repl to automatically watch code for changes and incrementally recompile. This allows us to see any compiler errors in our code immediately after saving changes to a file. It’s not uncommon for us to open only a terminal with a text editor and ghcid while developing applications in Haskell.
As in: Modern IDEs don't require you to run external tools to monitor your code for changes and highlight errors.
> a common refactoring workflow is to make a desired change in one location and then fix one compiler error at a time until the program compiles again.
As in: Modern IDEs let you do large-scale refactoring in one go, at a press of a button.
> The type system can protect us from making mistakes when changing the rules of our domain.
It can't. The example provided can't stop you from doing `case status of Paid -> delete invoiceNumber`. You have to invest significantly in a type-based DSL to prevent that from happening. But then, who will test your DSL?
> Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate
DSLs where all the rage 5-10 years ago. In reality, they are overhyped and are used very sparingly, for obvious reasons: DSLs are languages. They have to be designed, developed, maintained. Errors in your DSL will most likely harder to find and debug than in your regular program.
I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?
I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually:
First, such a mindset is neither possible nor would do much good. There are stroke victims that survive with full mental capabilities with regards to logical reasoning but entirely devoid of emotions. These patients can still ace the SAT, but they fail spectacularly at daily life. As it turns out, you just cannot decide on a doctor's appointment without emotions. They'll spent hours vacillating between two good choices. Emotions are incredibly well-tuned heuristics that cut down your mental load to manageable levels. As any part of being human, they are sometimes ill-fitting for modern times: there's absolutely no reason to make me flinch when I spill hot coffee over my hand. But mostly they just work.
Second, it's slightly annoying when people deny that they are subject to emotions, and it gets up to Ryanair-levels of discomfort when they announce that it makes them superior to all those emotional social science majors, illogical politicians, women "throwing a fit", superficial designers etc. If I got a KDE theme every time someone accused Apple users of being blinded by eye candy, I'd still be left with only half of what Kubuntu ships.
But Rust is cool.
It's about quality of life and picking the right tool for the job. There are some problems I can solve in Haskell, that I simply could not solve in Java, it would be too hard and too much work. Java is a simple language and therefore it's much easier to reason about the performance and space usage. There are thus many problems where Java would be a better fit.
Even if Haskell was objectively the 'best' language, it'd likely be a poor choice for most teams simply due to familiarity and developer speed.
I'd be extremely hesitant to hire the services of this company entirely because they use Haskell and it'd be a nightmare to maintain after their contract.
for(var post: postList) renderPost(post);
Or
postList.stream().map(renderPost)
This may or may not be the right business strategy, however if everyone would be going with a notion of only using popular languages because it's easier to hire for them, by now we'd be using JS as a backend language.Oh,wait...
https://iohk.io/en/team/#team=development
Now if you needed to hire 1000 developers, then you'd have more of a problem, and perhaps Haskell wouldn't be the right approach. But in my experience, Haskell engineers get a multiplier effect over the average non-Haskell engineer because the code is more concise and the average engineer skill is higher. I don't know what the multiplier is, but it's definitely non-zero and positive. This not only pays the obvious direct benefits, but also reduces the communication overhead of your team and the number of managers you need to hire.
It is quite difficult to get a first Haskell job though, because they mostly require production Haskell experience, so there's your chicken and egg problem.
I also believe that to be the case as an employee. Ie, being a generalist is probably -EV for your career but it feels safer so it's kind of a contrarian position to say "be a specialist".
Probably under 100, but not sure though.
I dont think this learning curve/hiring thing makes sense. Haskell can help attract smart dev, it makes refactoring so easy increased learning curve is off set.
I'd say it's harder to outsource, and there may not be as many libraries. Compare to Ruby/Rails for web, or Python for ML, and you have to write more by yourself in Haskell.
I didn't find the comment rude.
My experience with onboarding non-Haskellers has been pretty good, though I would certainly admit the argument that they were unusually talented individuals.
1. When your company uses esoteric language, your job offers usually have "we can teach you the language" instead of "we require x years experience in language and y, z libraries)". That is a really great filter for people you want to work with, as they have to accept they will be learning from the start.
2. There is a smaller number of engineers qualified, but the number of companies they can apply to is even more reduced. I think all in all you're winning in this equation as a hiring manager.
3. Your hiring process get cheaper, since it moves from having to filter candidates heavily to focus on matching the right person for the team. People who are interested in non-mainstream languages already fit some of the criteria you have to select for otherwise.
4. As the number of people to hire easily is smaller and onboarding even a talented person without experience in tech takes time, you get much better with selecting problems you want to tackle and grow in more reasonable pace. That has great benefits for your organisation.
I know for sure that if I am ever starting my own startup, I will use no mainstream technology. If I want JVM, I will use Clojure instead of Java, if I want web, I will use Elixir instead of Rails/Django, if I go low level, it's Rust, no C++ etc.
It's counterintuitive, but it works better. People think about size of the whole market, but they should think about percentage of candidates applying being fit for the job.
Edit: removed ` characters.
Perhaps when Java gets record types, sealed classes, pattern matching and other features. But right now, Domain Modelling in Java (and C++) is really painful compared to a higher-level language like Haskell.
To be fair, the context of that quote is:
> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance.
I think this is a fair statement, although it would also be fair to say "many Java and C++ programmers find their compiler errors useful". I'd guess these two camps would remain mostly the same when using Haskell.
You're right that most of the article is roughly comparing a good example of static types (Haskell) against a bad example of dynamic types (PHP).
> I've seen this a million times in Java, and that works fine.
My biggest problem with Java (and the JVM) is the existence of `null`: it completely undermines type signatures. In the above Haskell example we "know" (see caveat below) that a `myInvoice :: CustomerInvoice` is a `CustomerInvoice`, whilst in Java a `CustomerInvoice myInvoice` might be a `CustomerInvoice` or it might be `null`; likewise `myInvoice.billableItems` is a `[String]` in Haskell, whilst in Java it might be a `List<String>` or it might be `null`; in the former case, each element might be a `String` or it might be `null`.
Caveat: Haskell values are lazy by default, so errors may only get triggered when inspecting some deeply nested value; in that sense we might say that a Haskell expression of type `T` might be a `T` or might be an error (known as "bottom"). We certainly need to keep that in mind, but one nice thing about bottom is that it can't affect the behaviour of a pure function (we can't branch on it). In that sense returning a value containing errors, which are later triggered, is practically equivalent to triggering the error up-front (pure expressions have no inherent notion of "time", unlike imperative sequences of instructions). The interesting difference is that we can also use such values without triggering the errors, iff the erroneous part is irrelevant to our result ;)
Having all types nullable by default makes 'proper' null-checking incredibly verbose, not to mention tricky; the alternative is to cross our fingers and hope our assumptions are right. What makes this frustrating is that such checks are exactly the sort of thing that computers can help us with, and type systems are particularly well suited for! Hence the presence of `null` cripples Java's type system in a way which can't be worked around (without essentially layering a separate, null-less type system on top to check for nulls!).
Also note that the presence of null causes every domain model to collapse. Let's say we want to write a conversion method, e.g. from `CustomerInvoice` to `Document`, and we don't want to worry so much about `null`: hence we write in our javadoc that as long as the given CustomerInvoice contains no null values, this method will never return null; let's say we throw a NullPointerException in those invalid cases. Great, our users now have fewer edge-cases to worry about; they don't have to check for null, and they don't have to catch NullPointerException if their input is correct.
Except, once we start implementing our method we find it needs to call some other helper method, e.g. `statusToTable`; if that method returns a null result, we would be unable to construct the `Document` value that we promised. What can we do in that case? We promised we wouldn't return `null`, so maybe we throw a NullPointerException? If we do that, those calling our method might get a NullPointerException even if they gave valid input! We might throw a different exception instead, like AssertionError, but the effect would be the same. Hence we can't guarantee to our callers that we don't return null (or some equivalent that they must deal with, like NullPointerException or AssertionError); that, in turn, means they can't provide such guarantees to their callers, and so on. At any point, we might get a null (or equivalent exception), and the whole house of cards comes crashing down.
Maybe we trust that helper method doesn't return null, but how can we know? Maybe we check its documentation or source code to see whether it might return null; but we find that it calls other methods, so we have to check those, and so on. If we do this, we would also have to pin our requirements to the precise versions of the libraries that we checked. In case you couldn't tell, that process is essentially manual type checking (for a very simple system with two types: 'Null' and 'AnythingElse').
Of course, this is sometimes inherent to the problem, e.g. if a HashMap doesn't contain the entry we need then there's nothing we can do. However, most code doesn't have such constraints (except perhaps out-of-memory), but there's no way to tell that to Java (in mathematical language, Java weakens every statement to admit trivial proofs).
"Haskell's type system is more expressive than X and Y" is a strong claim and can be proven by showing that X and Y need to compose run-time workarounds for a given property that can be checked statically in Haskell.
"Functional Programming reduces the surface area for Bugs" is a strong claim and can be proven by showing that a single mutable reference strictly introduces a set of possible bugs that were not possible before and that these bugs cannot be checked in language X.
It is kind of annoying that these discussions often seem superficial, cultural or partisan, when in fact they could be much more rigorous.
Now, If we assume or find these claims to be true we can finally proceed with the real discussion: What are the costs and benefits of these properties in a given setting?
Is there really a formal proof or Software Engineering paper that proves this?
I was told this in my FP class in university, but it pretty much sold to me as gospel.
In practice I agree with the statement - I certainly feel there's an inherent "cleanliness" to FP.
But I also feel that the argument is not only about program correctness; many people ultimately conflate it with developer productivity. And here's where I feel that things fall apart a bit: I feel as if sometimes it's much quicker to do things with state, so maybe the time you save debugging is time you add elsewhere?
Now, the lack of skilled haskell programmers on the other hand, that's a pretty scary proposition if you're starting a company and may find yourself riding on a rocket, needing as many able hands as you can possibly find.
But occasionally it pays off in a really big way.
Like WhatsApp cashing out for $19 billion, on a product they never could have scaled with so few engineers without Erlang.
Like Viaweb and Common Lisp, where Paul Graham says the language allowed them to move much faster than their competitors. One anecdote was about talking on the phone to a customer reporting a bug, and actually fixing it on the live system and asking the customer to try again, and the customer was shocked to find it now worked.
Like ITA, who created the best in class flight search system in Lisp and then sold to Google.
Every once in a while, an unpopular but powerful technology really is the secret sauce for a winning product.
It can manipulate strings, decode JSON, but both of these are either (immutable) values from enclosing scope, or created within the function. But since they can't be output anywhere (because no IO) then they don't matter.
EDIT:
I'll just add a few more counterpoints.
Agreed that DSLs are difficult, and often not worth the trouble. But if you do want to create a DSL, then haskell is a good fit because of monads and monad transformer stacks - i.e you can make the statement mean whatever you want it to mean, and keep the effects in check with types.
The synergy between higher order functions with typed IO is great, better than in other languages.
Agreed that IDE refactoring is convenient, and also refactoring in other languages with static type checking the process is similar to what they describe in the article, so no immediate "pro" there.
It doesn't help if it's `Int -> Int -> IO Bool`, for example. Well, it does do IO, but other than that, who knows. Perhaps it reformats the disc while CPU is idle :)
My main point though is that the article does a very poor job of showing why Haskell is good at, well, anything, compared to, well, anything.
Genuinely curious, not that familiar with Haskell, just thought you could use something like parameter binding or similar to construct functions like that.
It can definitely NOT query a database(as that would be an effect which would be visible in the type).
From this quote, it's easy to see you've not spent any time actually using Haskell (others have explained what is actually going on), so why do you dislike it? I cannot fathom having an opinion either way on a language I don't know.
Limited open-source to leverage, incredibly limited and costly hiring opportunities, not that great tooling and integrations.
Any upside you can sell from a pure programming point of view (there are some very valid ones) pale in comparison to the negatives it brings to your overall business.
Disclaimer: I've only looked at the docs of IHP, but this was what it looked like it was doing.
Other than Jane Street, nobody much uses it though, so that's that.
But I would also say that you shouldn't be concerned with evaluation order when writing Haskell, in the same way you usually shouldn't be concerned with what the query optimizer is doing when writing SQL.
But that is not the only reason. Haskell does much more aggressive optimisations than Java (and Scala, OCaml, F#). A large part of Haskell's space-usage reasoning issues come from the combination of lazy evaluation and these aggressive optimisations. Java and Scala code can contain plenty of deferred evaluation too, for example iterators, but the compilers simply don't do (and cannot do) such aggressive optimisations. Of course, this also means that much pure functional Scala/Java code can be poorly performing.
«Haskell does not scale to organizations of 100+ engineers. There is a trade-off between writing and reading code, which Haskell does not fare well in. Also, given the realities of the dev hiring market, steep learning curves would be very detrimental to the success of the company»
What would have been your reaction if I had replied "look up the word condescension in the dictionary" to you? It would lead to bad discussion, regardless of whether my point about condescension was right or not.
That's why you don't optimise for it in a vacuum. You weigh the potential benefits of switching to Haskell versus the additional cost of maintaining/growing a Haskell team.
From my reading the article makes no claim that Haskell is the best language. The purpose as I read it is to explain why Haskell is their first choice while addressing an audience that has a passing knowledge of Haskell.
You being extremely hesitant to hire the services because of their technology stack is great and fine. There are many stacks and services I completely avoid in dealing with so I agree there.
"It'd be a nightmare to maintain after their contract" is something someone would likely say to any language that is not their preference.
I disagree that this is related to the original posted article about a company that has chosen as their first language Haskell. I do wonder how your responses would differ if they had chosen Elm originally and perhaps it is both you and I that should evaluate our emotions are why we even commented...
I've long-admitted that my heuristics for choosing a tech stack are very similar to what you describe. I analyze the requirements and give each technology a pass/fail grade. Then, amongst those that pass, I simply choose the one that I find the coolest.
Something needs to be a driver for action, and emotions fit the bill nicely.
> Type signature `Int -> Int -> Bool` can be used for a function that does any of the following things
[My emphasis] you meant "can't". That could be one explanation for the confusion that seems to have arisen here.
It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
Planning for that far down the road is the least of your worries. And any plans you make along those lines are not likely to be very accurate anyway. You're much better off optimizing for the near to mid term. Based on the hosting costs described by the OP they are already reaping a tangible value here.
So given the upside to paying people to using Haskell (they get to learn it for life, many join + grow the community, they enjoy working for your company more), I think it's worth that kind of harm to a corporation.
I'll keep trying to sap corporate resources into Haskell I take with me for life at least :)
It’s simple really. Functional programming is just imperative programming without one feature: mutability. Thus if functional programming is just regular programming with a reduced feature set it means it has the same error surface area as regular programming minus the surface area of errors caused by mutability. Hence by proof the error surface area is smaller.
Now think of of all the errors caused by initializing a variable as null and changing it later rather then immediately initializing an immutable variable with the correct value and you can intuit just how big the error surface area actually is.
Yes (page 7):
I wonder if there is one such formal proof as well.
Intuitively it is trivial: functions a are a subset of all procedures, state can introduce unique bugs, these bugs are not found in functions, so you're dealing with a subset of all possible bugs.
Another intuition is this: By introducing state you increase complexity. A procedure in isolation is not necessarily referentially transparent, but a function is. You cannot reduce the procedure with it's evaluation at any given point in time, because it is 'connected' to the surrounding program via that state. Now you'd have to show that increased complexity introduces unique bugs.
I'm simply not equipped (yet) to make such claims, but I'd love to hear from experts on these matters. I know that you can formally verify stateful programs, so it is likely not an issue of what is possible. But I damn sure know it is much easier to reason informally about functions than about procedures, except if the procedure merely has local state.
> And here's where I feel that things fall apart a bit: I feel as if sometimes it's much quicker to do things with state, so maybe the time you save debugging is time you add elsewhere?
I can only speak for myself here, but yes certain algorithms are more intuitive if implemented imperatively. But I found that the set of these algorithms shrink over time by getting used to FP. Vice versa there are also algorithms that are much more easily written with functions. Then there is core idiom of the language you're using. If it is imperative OO, then writing functional programs can sometimes feel cumbersome and less readable.
There are many factors that may or may not apply as well. For example functions are easier to compose and decompose, since they are by definition simpler. However imperative procedures are sometimes easier to read "from top to bottom", because they enable a more real-world-y mechanical/visual mental model.
FWIW, "Dancing Links" is a wonderful technique that would be worse than pointless in an immutable language.
We're used to avoiding complexity when it comes to logic, but maybe there's less awareness when it comes to types. Maybe what we need is to have a bigger conversation around that so people realize it's something that needs to be on their radar.
The only immediate solution I can see is to keep types simple enough that the user can fit the entire relevant type-space in their head (and in the IDE dialog!), so that they themselves can determine which part is actually "wrong" (as opposed to just contradictory).
"go play with it"
"look it up"
"google it"
"read the fudging manual"
Of course, there are many great faculty who _do_ care greatly about teaching and always help students.
Sometimes there would be some proffessors there too to help you out.
I'm not sure what your current level is, but I can give some general advice for people that happen upon this:
---
Haskellers are generally expected to understand most of the typeclassopedia (https://wiki.haskell.org/Typeclassopedia), don't worry about learning it all in one go. I had to read this page many times before I grokked most of it.
---
Avoid tutorials that overuse analogies. A Monad only adds one operation to Applicative:
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
---
It's important to be really good at using Monads that support multiple effects, to create little DSLs. If I want a component of my program to support throwing errors, creating a log, and reading an environment, (all purely), I'd use something like this:
type MyDSL
= ReaderT Environment
(WriterT [String]
(Except ErrorType))
Where I work we use free monads instead of monad transformers, but that's just an implementation detail, it's used the same as a transformer stack.
---
Create a cool project, Haskell people like languages. When I was interviewing I showed off a tiny lisp-like language implemented in Haskell (https://github.com/414owen/phage). This was my first non-trivial Haskell project so don't judge it too harshly.
---
Read Haskell Weekly (https://haskellweekly.news/newsletter.html). It's a great source of ideas and knowledge.
---
A lot of Haskell shops use, or are migrating towards using, nix (https://nixos.org/).
---
Apply! The Haskell market seems to favor the interviewee. In the end, I had more than one offer, even for my first Haskell job.
Good luck!
The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.
I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.
The point for that particular gripe was this: "this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does."
Yes, IO tells that ... the function does some side effects. And that's it. If your type signature is `Int -> Int -> IO Bool`, it's just as useless as `Int -> Int -> Bool`, and requires you to read the function to understand what it actually does.
Is it helpful to see at a glance which functions produce side effects and which don't? Yes, it is. Does it automagically "allow a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does"? No, no, it doesn't. `... -> IO Bool` may be launching nukes for all the information you glean from its type signature.
The benefit is not in `IO` -- its that its absence on a function tells you that it is heavily restricted in what it can do.
If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead of `IO`. Even if you end up implementing it using `IO`, you know it can't use more than what your model exposes.
Both of these possibilities, while not truly unique (see Agda, etc.), are absolutely rare-to-nonexistent in mainstream languages. Effect modeling is a real shift in perspective.
Secondly, IO is just one monad. You can build a more granular one where you can separate filesystem, network etc, and encode this into types (so you know at a glance). You can't do this in most other languages.
What are the types of things that are worth being hung up on for a language for you?
The talks were by Jason Turner, who has an ARM emulator implemented entirely as constexprs and a test suite that runs at compile time (so if it compiled, the tests passed). Obviously for actually interacting with it, its not running at compile time, but the logic has the ability to run at compile time, which is pretty cool.
"Old school" is asically the programming languages that originated in the 70s-80-90s. An incorrect but an illustrative way to describe error messages for them is "The programmer needs to suffer". They are any combination of cryptic, terse, complex, exposing internal machinery of the compilers and linkers etc. There are many reasons for this: computers were not powerful enough to afford better code analysis, parsing, backtracking etc; the users of the tools also knew the tools and could tinker with them etc.
"New school" is from late 2000s on. I usually say it started with Elm. Clear messages pinpointing the exact problem, solutions to problems inside error messages, error clarity as one of the priorities in language/compiler/tool design.
Category grammars were much better but more resource demanding, just like proper ASTs instead compiling as one goes.
Ironically there were already some attempts to Smalltalk like tooling for C++ back then, but again as you mention too much resource constraints.
I've never thought of it that way, but that totally makes sense.
How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?
With Haskell you just get 5 good ones. You probably don't start with Haskell as your first language but rather move into it after you are a senior in another language. If you are lousy in Java, you probably won't go and learn Haskell or some other niche language.
I would assume that:
(1) Those using niche stuff are less likely to be hiring under the impression that the main measure of skill is years of experience with a language, and
(2) those using niche stuff are, on average, doing more interesting work that attracts more intellectually curious candidates.
As a result, the mainstream firms get worse candidates, and try to compensate by asking for even more years of experience, and asking for years of experience not just with language but specific libraries and other tools, hoping that will get them more skilled candidates, at least for their specific toolchains. But doubling down on that just gets them candidates that are less capable (because even to the extent years of experience are useful, there are diminishing returns, and people who have spent a huge amount of time with the same stack also are likely to be in the “1 year of experience, repeated N times” category, rather than N years of learning and compounding knowledge. (Also, because at a certain point you start making impossible demands, increasing the degree to which the hiring process filters for dishonesty.)
Of course, there is just more of them in the first place. The other effects that you describe might also be true but keep in mind what the base rates are.
Indeed. And that's why I picked up on that particular point in the article that I'm criticising. The article chose to use those examples and those words and they don't show anything beyond what other mainstream languages have.
> If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead
Yes, you can. No, the article doesn't show that in any way. Just to remind you how I started my comment:
--- start quote ---
But this article goes out of its way to make the worst possible case for Haskell imaginable.
--- end quote ---
Does the article show "other models"? No. Does it even try and show how to reason about a function by looking at its type signature alone? Also, no. Would this article be laughed into oblivion had it been about any other language but Haskell? Yes, most likely.
> Effect modeling is a real shift in perspective.
Ah yes. Does the article talk about this? Does it show a single example of this? No.
Yup, this is probably my main issue with Python. I love writing it when I'm working on personal projects, having to read massive Python code bases at work feels unnecessarily tedious due to how much work you have to do sometimes just to find out the type of something.
I would still recommend against using Python on a big project. Funny thing, I remember talking to my boss (a mainframe programmer) in 2010, when I solved something with a script in Python, that I wouldn't use it in production, but it's great for small things. Forward to 2020, plenty people use it in products. Maybe the Haskell will be the same, you also have many people today saying "well this is good for experiments but I wouldn't write a product in it".
I've recently been back to Clojure, and it's the same old aggravation again. It seems that, oftentimes, the only way to know what arguments a function is prepared to accept is to already know what arguments a function is prepared to accept.
I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. What I really want to challenge is the idea, popular in many dynamic typing circles, that static types just get in the way. They can also serve to communicate essential information. If you aren't communicating that information through type annotations, then it's absolutely essential that you do it by some other means.
Curious, from what and why? ML?
The lack of .h files alone is a huge grievance for me - I had to scroll past definitions even to know names and arities of class methods, read constructors to know what's in class members.
SciPy was nice enough for turning data into a picture, though.
That's an interesting point... Besides C and its derivatives, and OCaml, do other languages have separate definition files? It seems like newer languages, even statically typed, normally don't.
I suspect the reason is that you have to duplicate all definitions, which seems like rote work. It also feels less necessary with IDE tooling: IDEs I know have a view for all definitions in a file.
One place I worked used to be a Python shop, but had migrated most of its services to Java. Chatting with one of the engineering leads for a large Python system that had a lot of business logic, he said where Python actually fails to scale is lines of code and developers because lack of types makes it harder to reason about and harder to make changes safely. This obviously changed now that type annotations are a thing.
Oh, I think there are great evidences, such as: dialyzer, or ruby3 and python3 shifting towards type signatures everywhere and gradual typing, or recent racket focus on typed racket. Oh, and the rise of typescript of course.
I mean, I've abandoned Python years ago, and I was quite surprised when I discovered python people are adding type annotations everywhere.
Sure, gradual typing is not a strictly enforced as in statically typed languages, but seems people are agree that modularity and abstraction without type signatures is painful in sufficiently large programs.
I don’t feel like this anecdote is evidence because I don’t think it’s inconsistent with the trend towards more static types over the last 5-10 years or so. For this anecdote to be convincing I would need to think that programming language design happens because of carefully thought out and researched decisions and quick feedback as good languages are used and bad languages are dropped, but I don’t believe this.
Yes, this is not a sound rigid empirical proof, it's an observation (i.e. unlike the case of anecdotal, you can measure the marketshare of user, how many do use dialyzer or typescript, etc etc). We can't simply ignore any observations that are not scientifically rigid, otherwise the whole edifice of philosophy or even some natural sciences should simply perish.
I don't think you can just omit that. I'm a fan of Lakatos here, if I have some observation, I think one need at least as convincing evidence or more rigid one to prove otherwise.
> because of carefully thought out and researched decisions
I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.
In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.
dynamic languages (like smalltalk) were designed for live coding where the results are immediate, when that is broken and coding is done in a "dead" environment of course dynamic typing will cause problems that arent caught until runtime... but the original idea was one shouldnt have had to wait until runtime in the first place!
Any others?
Unfortunately the same amount of effort that has been applied to static type checking has not been applied to dynamic language environments.
It would have been very interesting to see what could be possible with the more advancement.
This means that you cannot say something like this:
auto sepulka;
auto bubuka = zagizuka(sepulka);
[1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%...
[2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Mar...
[1] shows how hard it is to make right type system with inheritance. I believe these slides mention 25 years of collaborative effort. Compare that to [2] where it took 8 years to design intuitionistic type theory (1971-1979) by mostly single person.
It has a much simpler type deduction system where the type of an object is deduced from its initializing expression, i.e. deduction always flows in one direction.
It is nowhere as powerful, but it does cover a lot of use cases.
One advantage (in addition to the ease of implementation) is that, except for circular definitions, there are no undecidable cases and it is not necessary to restrict the type system to prevent them.
for example
def sepulka(zagizuga)
zagizuga.doSomething()
zagizuga.doSomethingElse()
maybe i missed something...
E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.
A culture of writing code assuming inference and structural typing is quite different than it merely being available.
Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on.
The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that direction.
If the Rust compiler can figure out what the type should be, why doesn't it just do the cross-function inference, and leave the complicated nested implications which only obscure the intent and effect out of it?
If having the programmer specify types is an important check on the correctness of the code that is written, how is blindly copying, without understanding some 60+ character type specification string from an error message going to help demonstrate correctness? All it does is make two sections "consistent". It isn't something the programmer understands or specifies as a type check.
It could! This is an explicit design choice. There are a few different reasons. They're all sort of connected...
In general, Rust takes the position that the type signature is the contract. If you inferred the types on function signatures, changing the body of your function could change the signature, which means that breaking changes are harder to detect. It also leads to "spooky action at a distance" errors; I could change a line of code in function A, but then the compiler complains about the body of some unrelated code in a totally different part of the codebase, because that changed the signature of function A, which changed the signature of function B, which is called in function C. My error shows C is wrong, but I made a mistake in the body of A. That's confusing. Much nicer to say "Hey you said the signature of A is X but the body is Y, something is wrong here."
I am gonna handwave this one slightly because I don't fully remember all of the details, but full program inference and subtyping is undecidable. Rust doesn't have subtyping in general for this and other reasons, but lifetimes do have subtyping. I am sure this would get ugly.
Speaking of getting ugly, Rust is already criticized often for compile times. Full program inference would make this much, much worse. Again with that changing signatures issue, cascading signature change would cause even more of your program to need to be recompiled, which means that bad error message is gonna take even longer to appear in the first place.
I think there might be more but those are the biggest ones off the top of my head.
Correct. Haskell is the only language I know of with globally decidable type inference, and uses the similar hindley-milner method as Rust... but no doubt some of Rust's language features can break global inference. In Haskell, many common language extensions can also break global inference.
I think if Haskell was written today they probably wouldn't pick global inference as a goal, Haskell "best practice" types the function boundaries in the same way that Rust enforces.
For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO
To be clear, this is where I disagree. I don’t want to claim that people don’t think hard about language design or that users aren’t asking for these features as I think both of those statements are true. But I strongly disagree that languages doing things (and those languages being popular) is good evidence that those things are good.
I think a lot of language design is driven by fashion (ie keeping up with what similar languages are doing) and I claim that this is a more convincing reason for python having some gradual typing.
I think large number of people is moving to/from from python for gradual typing in aggregate, and I don’t think it’s happening on the margin either. I think any wise decisions about languages are more likely to be driven by practical considerations (what do people know, what are they used to, what can people be hired for, what libraries are available, what platforms are supported, what performance is required, and so on).
Just because python has a large market share, it doesn’t mean it’s users are supporters of gradual typing, it just means that they thought python was a good idea when they first started using it and they haven’t justified the cost of changing to something else. The users didn’t choose gradual typing they just chose “upgrade the language to the next version”
Even if I agreed with your claim that many users asked for gradual typing, I don’t agree that in aggregate users ask for things that will be good for them or good in general. Maybe users are just trying to figure out a way to say “we want our programs to be less buggy” and think this might help. I think there are better examples in programming language design of what can happen if you keep giving users what they are asking for.
for example, in swift you cant even inherit from two protocols that have default implementations... and i think in c++ you also cant call the method without specifying namespace...
so, i suppose, if you wanted to go all the way, you could even do namespace inference
def sepulka(zagizuga)
zagizuga::Something.doSomething()
zagisuga.doSomethingElse()
though that seems getting a bit fragile irl maybe...
A lot of the "weirder" parts of Haskell are there because early on Haskell was pretty much "LazyML" and then it started growing into something different.
String foo = "bar"; String baz = foo;
The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.
or auto&&. Did you really intend to make a copy?
I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.
But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
Type inference doesn't make these errors go away.
And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.
Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time.
C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.
The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.
> I can have an array of T, but I can't specify that T is Numeric?
Sure you can. If you have C++20 concepts:
template<class T>
concept Numeric = std::integral<T> || std::floating_point<T>;
template<Numeric T>
T twice(T x)
{ return x + x; }
template<class T>
typename std::enable_if<
std::is_arithmetic<T>::value,
T>::type twice(T x)
{ return x + x; }> I can have an array of T, but I can't specify that T is Numeric?
This is what type-traits and 'concepts' are for, right?
> The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.
This is what std::is_integral gives you.
I'm used to Boost.Bind and similar, so was thinking a scenario where you bind the database connection parameter and pass the resulting function to something else.
As the sibling pointed out though, I now get that the result would be "tainted" so to speak.
In this case you can think of a monad a bit like a computational context. If one is not present, you simply cannot[^1] instruct a Haskell program to perform those operations in a type safe way even if you give it a valid database connection identifier.
[1] Well, you can, but if you do you're explicitly taking away all the safeguards that Haskell introduces, and it would never pass code review.
Int -> Int -> IO Bool
(btw Haskell's `IO Bool` would be spelled `IO<Bool>` in C++/Java syntax)
edit: So at work, just about every value depends directly or indirectly on stuff that comes from files or from the database. So would they all have to be wrapped by IO?
The core logic of a program often doesn't need to care deeply about state or system resources. Pure functional programming is about writing as much as you can in this "functional core", and then lifting the assembled pieces of pipeline into the "imperative shell" (such as the IO monad).
Its argument is a function of type `String -> String` and it returns an `IO ()`, i.e. an i/o action with a trivial result. That action will call the given function on contents of stdin, and writes its result to stdout. Or, equivalently, we can think of `interact f` as transforming a pure string-processing function `f` into a stdio CLI.
Note that laziness (specifically "lazy IO") causes stdin to be read 'on demand', giving us a streaming computation without any extra work. Here's an example implementation of 'wc':
module Main where
import System.IO
main :: IO ()
main = interact count
count :: String -> String
count input = show (length (unwords input))
count = show . length . unwords[handwavy analogy alert]
people often call it "side-effects" as a shorthand. in reality an expression being of type `IO Foo` mostly just tells the compiler that order of execution matters (which isn't the case with pure functions):
do print "a"
print "b"
-- obviously not the same as
do print "b"
print "a"
do a <- readBytes file 100
b <- readBytes file 100
doStuff a b
-- obviously not the same as
do x <- readBytes file 100
doStuff x x
Only that the types can be analysed structurally (ie., pattern matched).
In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.
Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespaces shouldn't be a big obstacle to understanding either.
It was also crystal clear that, like C++, Rust puts many barriers to true abstraction. You have to know many, many details of how a specific type is implemented, sometimes several levels deep, to correctly use it at a high level. The cognitive overhead is enormous.
Hiding them basically amounts to targeting a different domain. This is very different from being irrelevant and noisy.
If it was instead
String foo = "bar";
auto baz = foo;
I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it.
void foo(MyType mt, const MyOtherType& mot);
However, it maybe doesn't work that well with things like class member names. YMMV
using B64String = std::string;
B64String encode(const std::string& text);
std::string decode(const B64String b64);In our case, almost all core code depends on various parameters, which come from the database.
For example, GB recently left the EU so everything involving GB is now processed under different rules, except old stuff which has to be processed under the old rules. Thus being part of EU or not is a date-dependent database query (it already was, not the first time a country's EU status has changed).
So if I get your explanation correctly, I'd code the core logic as if these parameters were pure, side-effect free, which would make the core logic side-effect free. In the case above, I'd pass a function which maps a (pure) date and string into a (pure) bool, to test for EU membership.
I'd then turn that whole thing dirty via the IO thingy, passing "IO parameters" and receiving "IO results", so I can pass it my EU test function which does a database query.
edit: And I presume my "dirty" database-connecting function can also mutate things, so it can do caching. Don't want to hit that database too often.
i doubt you could make (or really, even want to make) `checkEUMembership` pure, I'm guessing it'd involve a DB lookup of some kind.
in general, you can't always "pull out all the IO" into an only-pure-logic "core"; like if you want to look up one thing and then look up another thing based on the result of the first lookup. and that's okay!
i'm not going to write a whole monad tutorial, but using an `IO Foo` is kind of like using a `Promise<Foo>`¹; you do stuff like this (in JS syntax):
getX(...).then((x) =>
getYForX(x).then((y) =>
foo(x, y)
// note - nested lambdas/closures, `x` is closed-over
)
)
---
¹ Unfortunately, JS's Promise#then mixes two things:
• "dirtying" a pure function:
getNumberFromDB().then((x) => x*2)
fmap :: (a -> b) -> IO a -> IO
getNumberFromDB().then((x) =>
getNameForNumberFromDB(x)
)
(>>=) :: IO a -> (a -> IO b) -> IO bWell that was kinda the root of my question. The core logic doesn't really care as such, as long as it could determine EU membership somehow, but actual code would have to use a DB lookup[1].
That of course spirals back to what would that really buy you. You'd write code pretending it's pure while it really isn't. I can see part of the appeal, but I can do that in my current language.
Of course I don't get an error if I do something silly in the middle of some otherwise "pure" module, so there's that.
Anyway, illuminating. I enjoy thinking about these things and challenging my self-taught ways. Thank you all for your contributions, much appreciated!
[1]: An aside but, due to an error on the government side, GB is part of EU today as far as one of their validation checks is concerned. So today only we have to pretend along, for just that one field. This stuff is fun!
And imagine what would happen when you get a few more 'auto' variables in the return expression. Suddenly your return type will depend on the implementation of your callees. And the code can then quickly become impossible to understand.
auto is overused.
Why would that be a problem ? It's super common in templates and has never troubled me the least
1. "My return type is whatever I happen to return" circumvents the ability of the type checker to ensure correctness.
2. More generally, the purpose of a specification (a function declaration in this case) is to declare what is required of a compliant implementation, and to provide a way to check the validity of that implementation. But when you make the types all become auto-deduced, you're basically reducing the specification to a ~ shoulder shrug "it does whatever it does" ~.
3. Moreover, as I alluded to in the comment, it quickly becomes near-impossible to meaningfully separate the definition from the declaration, whether that's because you want to hide it or because you want to compile it separately. Simply put, you lose modularity. It seems like a minor thing when (as in the example) the return value doesn't depend on types inferred from other callees' return values, but as soon as that ceases to be true, you suddenly tie together the implementations of multiple functions. At that point, your functions lose much of their power to abstract away anything, since as soon as you change the return expression for one function, it has the potential to break code (up to and including causing compilation errors) in the the entire chain of callers. (!)
4. Templates end up getting re-instantiated far more often than they need to be (which can slow down both the compilation and the runtime efficiency). You almost certainly don't want '0' and '(size_t)0' to result in duplicate instantiations when dealing with sizes, for instance.
5. Issue #4 can also result warnings/errors/bugs, since now you have a function that returns a different concrete type than you likely intended, which can result in everything from spurious warnings (signed/unsigned casts, for instance) to actual bugs (later truncation of other variables whose types were inferred incorrectly as a result).
6. The code becomes difficult for a human to read too. You now no longer have any idea what types some variables are supposed to be. Not only does this hamper your ability to cross-check the correctness of the implementation itself (just as with the declarations, in #1) but unless your function is trivial, this quickly makes it harder to even understand what the code is doing in the first place, never mind what it's supposed to do.
7. Proxy types become impossible to implement, since they won't undergo the intended conversions anymore.
All this just to reduce keystrokes might be a common trade-off, but a poor one. I can come up with more reasons, but hopefully this gets the point across.
in a way, it's the opposite! the point is you can't pretend, you have to make impurity painfully explicit:
getTradeTax :: CountryId -> CountryId -> IO Float
-- ^ sirens blaring, side-effect alert
getTradeTax ca cb = do
aInEu <- lookupEUMemberDB ca
bInEu <- lookupEUMemberDB cb
if (aInEu && bInEu)
then (pure 15.00) -- made up value
else getNonEUTradeTax ca cb -- another impure operation
> I can see part of the appeal, but I can do that in my current language.
true, and i've seen IO-monad-alikes for Python and JS, but most of the benefits come when every library you use has to be explicit about impurity and there's a typechecker enforcing it.