Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

This article is a good example of why I don’t use uncommon programming languages for actual projects. I watched an Elm-based project steadily slip behind schedule while the team insisted that Elm and FP were actually going to save us a lot of time… eventually some day.

These uncommon FP frameworks and languages can be good tools in the right, experienced hands. They can also be fun for side projects and as learning exercises. But every time I’ve watched programmers try to use uncommon functional languages for real projects they end up like this article:

> More accurately, learning Functional Programming concepts used in Haskell in 3 months after having thrown out 30,000 lines of code on a project that was now monumentally behind schedule was the hardest thing I had to do in my career.

When you’ve reached the point of being severely behind schedule, throwing out mountains of code along the way, and struggling mightily just to get basic things accomplished: It’s time to stop. Don’t double down on a new language that you also have to learn from scratch. Pick something tried and true and get the work done. Revisit the functional language at a later time for an unimportant project or a side project, not something with a deadline.

If the programming language or ideology has become more important than shipping the project, we’ve lost the point.

View on HN

Also the basic pitch of functional programming is "we have better abstractions, you'll write better code". The basic pitch of something like Java is "everyone knows how to get things done in Java" and of Python "there is a right way to get the task done, and we will tell you what that way is".

There is a fundamental mindset here that the Functional languages aren't task-first. Not in the languages, mind, it is in the community. And the tasks themselves can be so simple once the abstractions are under control that people don't write tutorials about the task.

It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand.

> It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand.

This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done.

I think this plays into our tendency to view learning and education as investments rather than costs. That may be true on a personal level when using your own time, but using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

As kindly as I can put it: I’d argue that within this sentiment are the foundations of everything wrong with the ecosystem of professional software engineering.

Let’s start with, if you don’t let people learn on the job, you have to have at least 20% annual turnover to be only 5 years behind the knowledge curve.

At 10% turnover, you’re 10 years behind. Managers think people shouldn’t be learning on company time, HR tells the board lower turnover is a goal.

Inevitable next step is pausing all productive work to undertake a “Digital Transformation™” to try to replace 20 years of old tech. But the firm won’t know how.

> Let’s start with, if you don’t let people learn on the job…

Learning in the job is great, within reason.

Abandoning all of your existing experience and trying to write new projects in a completely unfamiliar language with zero prior experience is not reasonable, though.

Learning isn’t a binary yes/no feature of a job. There is ample room for learning without allowing reckless decisions like trying to use Elm for server-side code when even the Elm authors are hostile to such a use case.

>> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

> As kindly as I can put it: I’d argue that within this sentiment are the foundations of everything wrong with the ecosystem of professional software engineering.

Almost all Software Engineering, as practiced, is not a form of engineering in any way. Many times Software Engineering is really a bunch of commodity workers, who are learning, assembling commodity components that don't really work, under the oversight of a more senior developer who helps everything not fall apart.

You might be interested to read Hillel Wayne's crossover project, where he interviewed a number of people who had worked in traditional engineering roles as well as in software development.

https://www.hillelwayne.com/post/are-we-really-engineers/

The upshot is that "engineering" isn't the paragon of excellence we like to think it is. Whether or not you agree, it's a good read!

Thanks!

It’s pretty clear that these numbers are made up. Software engineering is an incredibly multi-dimensional field, and it is not a fact that learning on the job is beneficial to anyone let alone employers. And you assume so many things that will not always be true, like the fact that everything will always be changing in the field.

You may feel different, which is ok, but don’t bring made up numbers into it.

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

It's in fact very cool. I get to take those skills with me when I leave in a few years :)

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

To defend the counterpoint, artificial scarcity is abundant in the industry. Deadlines always approach, projects are already late. If employees don’t learn and improve on the job, employers will be happy to replace them.

I think this problem is specific to the Haskell community. No one's going to tell a brand-new Clojurist that they need to learn about reducers.

Agreed. Clojure is the most productive language I've ever used.

> This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done.

Well... if you learn them on this project, they don't count for the next project. So in that sense, if it levels up your group, then you only pay the price once, but you reap the benefit for a long time.

For purposes of any one project, though... the time counts as overhead. It needs to pay off, or it's a waste.

>using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

Boss makes a dollar, I make a dime, that's why I learn zygohistomorphic prepromorphisms on company time.

Every community does that though. Try to do something in Java and there will be hordes of people who tell you you need to learn a wall of jargon from Spring or Hibernate or JAX-whateveritis. Try to do something in Python and there will be people telling you you need to learn a bunch of Django stuff.

A lot of people put the cart before the horse - the whole point of using a monad or whatever is to let you write clear, straight-through code with plain functions and values, if you can do that without using a monad then that's even better. But I don't think that's an FP problem per se so much as a hammer-nail mentality or, worse, a mentality where if someone's spent a lot of time and effort learning something then they want to prove that it was worthwhile by forcing everyone else to put the same effort in.

I'll say this though: functional techniques really can save a lot of time. I'm not sure I'd recommend Scala for a new project if you don't have Scala experts already, but I apply ideas I got from my experience using it to projects all the time.

The question then is whether it was functional programming that actually made the difference, or the people who had enough perseverance and skill to actually learn Scala in the first place running the project.

I've found that people who go out of their way to learn things like that would be more productive regardless of the language itself.

>The question then is whether it was functional programming that actually made the difference, or the people who had enough perseverance and skill to actually learn Scala in the first place running the project.

Oof, it may indeed be the second, but what do they get out of the deal?

A lot of FP programmers refuse to go back, simply because it feels nicer.

It's a hell of a lot easier to "persevere" on a project when your language doesn't make you want to dig your eyes out with a spoon.

I agree, but then you should focus on hiring people with these specific predispositions, and not trying to teach your developers FP from scratch.

Depends on the project, that is exactly what feels to me sbt or scalaz.

Well, the ideas I liked, stuff like deferring side effects and avoiding state, were functional ideas. You see a lot of functional concepts and constructs bleeding out into mainstream languages (just look at the last few C# releases, for instance, which look like a list of features borrowed from Scala), which I think will be their legacy more than widespread adoption.

  > stuff like deferring side effects and avoiding state

is that really "functional programming" or just good practice?

To the extent it’s considered good practice now I think FP deserves a lot of credit.

i see, thanks for the reply

one reason i asked is because while i don't really come from an FP background (as a student, i started with c/obj-c), after working in the field it was always appaling at how many variables and global state people would put in their code and how many side-effects were present... its just something that seemed so obvious even in "oop-land" but maybe im just an outlier...

I think that's been recognized for global state for a long time, but I think that mutating local or instance variables/collections wasn't really thought of the same way as much when I started doing this like 8 years ago.

Functional programming has the same problem as "AI" - as soon as something's adopted by the mainstream, it's "not really functional programming, just common sense". Ten years ago lambdas and map/reduce/filter were "functional programming"; now every language has them. Fifteen years ago having interfaces rather than just classes was "functional programming". Five years ago pattern matching was "functional programming"...

I argued recently that the core to functional programming is composition, rather than specific language features. This goes many ways, such as functional composition (using currying, higher order functions etc) and type composition (using algebraic types). Functional polymorphism using HKT's and typeclasses are also compositional.

Pattern matching, for example, is not itself 'functional programming', and never has been. It's a feature common in functional languages because it compliments algebraic types.

OO/Imperative languages (C# and Rust) getting pattern matching is useful but doesn't make them functional languages. C# and Rust are compositional in the sense types may implement interfaces (or traits), but with varying degrees of power. However, C# can't have HKT's until some work on the CLR is done, Rust is much closer.

Programmers (particularly web programmers) these days don't really consider the computational cost of their actions, so pure functions with immutable data types are now possible, despite the unnecessary allocation. Almost all popular OO architectures now are some variant of 'functional core, imperative shell'. There is definitely a 'functional shift'.

It makes me a little sad tbh, to see OO languages embrace FP principles. I just like writing tiny functions and types, gluing them together somehow (not how Haskell does it*), and building up to a bigger system. You can follow that approach in F# or OCaml, but it's not really possible in an OO language, regardless of how 'functional' it now is.

* Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful.

>Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful.

For those who aren't familiar, I'll explain:

First of all, these are all infix operators, meaning they take two parameters: one before the symbol, and one after. You already know many infix operators: +, -, %, etc. I'll be surrounding them in parentheses, as that's idiomatic when they're not being used in the infix position.

(.) is compose: run one function, then feed its result into the other.

($) is just a tool for avoiding parentheses. It means "wrap everything after this in a set of parens".

(<|>) is alternative. Try one computation that can fail. If it doesn't work, try the other.

(|>) is either snoc (the opposite of cons) or pipe--as in bash--depending on what you have imported.

(<$>) is the general form of map, called fmap in Haskell (since map is just for lists). Given a function and a value inside a container, return the function applied to the value, inside the container.

(>>=) ah, bind. One half of the interface to the famously difficult monad. It's really not that hard, conceptually: run a computation, then use the result of that to run another computation. You might say "that sounds like compose!" and you'd be right. The difference is that a "computation" (or "action", or whatever your local monad tutorial calls it) is a function in a context. That context can be "it might not exist", which is called Maybe, or "there are a lot of values in order", which is called List, or "it can do side effectful IO", which is called, well, IO. If you want to compose those kinds of computations, you need to also "compose" their contexts as well. The implentation of that composition varies from context to context, but the interace is the same: (>>=), or bind.

Of course, conceptually is the easy part. This is the one operator in your list that can be a little difficult to gain an intuition for.

It's both. You can defer side effects, and avoid state in most other languages; but it's not enforced, or encouraged; and might even be tedious. The difference with functional languages, is that they encourage or enforce deference of side effects, and avoidance of state.

That’s certainly a big part. The other one is less obvious, but is one that shines through this article as well. Once you learned a functional language or any language that is well designed (for me that typically incorporates functional and possibly logic and relational paradigms) then you’ll be more confident and productive than before and will have a hard time to justify using a tool that is inferior other than adherence to the lowest common denominator.

I’m sure this can be observed with any profession. A good cook can work with a cheap knife and mediocre ingredients, but give them a nice set of professional kitchen tools and fresh, tasty vegetables and they will happily cook you a meal that makes your evening.

a good language would allow you to express thoughts that are difficult in another language. But this presumes that you have those thoughts to express in the first place. If you don't, the language isn't gonna magically be able to give you the ability to have those thoughts.

So learning functional languages is both learning the language, but to also improve your cognitive capabilities to have more thoughts.

I wouldn't say the used an uncommon language. They build some kind of tool to run on top of Elm which wasn't inline with the goals of the Elm project (unlcear how). Seems like something that should've been investigated before commiting

It is inevitable that someone will use a language in the way the developers didn't intend, but this is the only time I've heard of the developers specifically setting out to break their language for some users.

that seems to be the angle presented by the author but that doesn't mean that is what happened

Elm author is quite vocal about wanting people to only be able to do things one way. It's the reason people choose Elm.

The Elm guy is infamous for this kind of thing

That's not functional programming at fault; that's a case of hostility toward users.

I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. Just know what you're doing or don't do it.

> I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is.

These two points are closely related, though.

Common tools will always have more available programmers, more documentation, more tutorials, more help, more libraries, more maturity.

We had a server written in a functional language at a company I worked at. It was fine, but when the two people who wrote it left the company it became a huge pain point to even hire someone to work on it. Consultants knew this and demanded exorbitant fees for basic work on the project.

Eventually we just rewrote it from scratch in a common language and saved a huge amount of time and money compared to trying to build teams and schedules around this obscure language.

which language?

> more documentation, more tutorials, more help, more libraries, more maturity.

Haskell's got all that but I can't argue with it needing more programmers.

What if I told you that common languages are rapidly adopting futures from functional languages? Go being a notable exception.

> What if I told you that common languages are rapidly adopting futures from functional languages?

I use functional paradigms in mainstream languages. No need to be snarky or sarcastic.

That’s not what this article is about, though. Using Elm and Haskell for projects is not mainstream.

id tell you duh, and go actually has (or will have soon) the pieces for the majority of the daily useful functional programming concepts. namely first class and polymorphic functions.

As far as I know, the Future concept for async/await started with Twisted's Deferred, which is a framework for Python. It's not really from functional land.

Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing". [0]

Applicative programming is an older term for functional programming[1], but note this isn't pure functional programming like in Haskell; it's functional programming like in Scheme and Javascript.

[0] I can't find a pdf of the book, but it was mentioned here https://en.wikipedia.org/wiki/Futures_and_promises - the book calls it promises

[1] https://en.wikipedia.org/wiki/Applicative_programming_langua...

> Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing".

According to Wikipedia, Promises were, Futures (which are similar but not identical) were proposed in a 1977 paper. All of the closely related concepts of promises, futures, logic variables, and dataflow variables were used in functional languages first, and long before their use in, or the existence of, Twisted.

I don't think python invited a single thing tbh.

futures have been around since the 80s afaik

lol I meant to say "features", not futures. Sorry

Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.

> Really I think the mistake there was not forking Elm.

Forking a framework and trying to maintain a new, separate open source project is a huge burden. There is no way that would have fixed their problems of being behind schedule, but it definitely would have permanently worsened their maintenance overhead.

They needed to scrap the alternate language/framework plans and return to something safe and proven as soon as it became obvious that they were too far off track. Continuing to double down on commitments to unpopular frameworks (or worse, creating your own niche fork to maintain) would only worsen the problem.

Rather than forking elm, there's purescript, which is unlike elm in all the restrictive ways. It seems to have regular releases and plenty of packages as well.

https://www.purescript.org/

https://pursuit.purescript.org/

Or port over to bucklescript-tea (a port of the Elm architecture to the OCaml-to-JS compiler BuckleScript) using the Philip2 migration tool, which was announced almost a year before OP was published: https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...

I agree. Assuming this article is about the author’s experiences in early 2019, Elm has only had one release since then. They wouldn’t have missed out on much at all by shipping with a forked compiler but would have gained a lot of time to migrate.

The fork wouldn’t necessarily need to be public either.

Yeah I was literally expecting the next paragraph to be "and that's how elixir was born!"

I mostly agree. However you could use the same argument to dismiss any programming language the moment any team is failing using the language. No programming language has a zero fail track record. Because success depends on context and team much more than programming language.

FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is probably not a good idea though.

> FP is absolutely way more time-efficient for most kinds of projects

I absolutely do not agree.

FP binds your particular choice of implementation to the code architecture. FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult.

A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time".

This is painful.

An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life.

Now, if I'm trying to manage a high-complexity codebase, I will probably eat the FP penalty. Having complete determinism, decoupling, and visibility in, say, a network stack makes debugging possible that will be very difficult with sorta-state smeared across a bunch of variables at various level of hierarchy.

However, I accept and acknowledge that I am making a tradeoff.

> An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life.

Which actually destroys the ability to refactor in the large. You have no idea what might use that global time variable from where or why. Choosing to use FP is choosing to ban yourself from taking on that kind of tech debt (although we should note that most FP languages have an "escape hatch" if you need it - even in Haskell you can always unsafePerformIO). There are definitely times where you want to do that, but I don't think it's right to frame that as the non-functional language making things easier to refactor in the large - rather the non-functional language makes it easier to not refactor in the large because you don't fully decouple things in the large in the first place.

> FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult

This is not at all my experience, in fact I'd say I encountered the opposite. Large scale refactoring in C++ and python were nightmarish and are a breeze in Julia and Elixir.

>A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time".

A sufficiently complicated FP codebase almost certainly has some form of effects management in place (monad transformers or algebraic effects, for instance), so adding a timeout is as simple as adding the effect to the type signature at the top level and then letting the compiler tell you all the places you need to wire it up. I've done this in many codebases. It's actually a dream, as the type system won't allow you to make a mistake.

> A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time".

I mean, 'FP' is so broad a term that a lot of languages fall under that, almost all of which can introduce the concept of a timeout quite easily. E.g. OCaml's Lwt, or Scala's ZIO are two that quickly come to mind.

This somewhat annoys me. "Knowing what you are doing" is time efficient. Regardless of what tooling you have.

The flip side is maintainability, which gets much simpler long term with FP.

This is a statement that requires some sort of citation. Extraordinary claims and all that.

20 years experience with OO code. Over time, OO always leads to entanglement due to inheritance based solutions that seemed like a good idea at the time. Eventually, these become the basis for many other parts of the system.

You combine the potential for side effects in the code with a tree that can't easily be changed because of how many other things it will negatively affect and you end up with a code base that is harder and harder to change the larger it gets.

In a FP approach, this is a class of problems that you can't easily replicate. Yes there's a learning curve to operating in a FP style, but once you're able to move quickly with it the long term rewards are a byproduct.

The OO solution to avoiding this problem is to build with microservices instead, which forces different parts of the system to be isolated and minimizes the negative effects from entanglement...but microservices come with their own maintenance and speed of development headaches as well.

35 years of OO experience here. Maintaining very large C++ code bases. I never have OO entanglement problems due to inheritance based solutions. Why? Because I only use inheritance for interfaces. Nothing else.

Do you have evidence showing this? The few long term maintained programs I am aware of are decidedly not what one would call modern functional.

(Granted, the most ported and maintained software I know of is either Linux or SCUMM.)

I know what I’m doing in many languages, and I’m uniformly more productive with the FP ones. The only time I’ll reach for a non-FP language is if I’m forced to for work or if I’m working on an embedded system with no allocator.

Is this confirmation/survivor bias, though?

I would love to know that there is a panacea that automatically improves productivity. Unfortunately, I haven't seen one in my career, as yet.

I am certainly more happy in many functional languages. And I can see happiness contributing to some. But I can't count that as data, without RCTs or something similar.

I'm not going to go so far as to claim that computer science isn't science. But I do fear that there are more claims than there are checks in our industry.

>I would love to know that there is a panacea that automatically improves productivity. Unfortunately, I haven't seen one in my career, as yet.

I suspect you've seen many of them. They're just the ones that are so normal you don't notice anymore. For instance, no one does pure waterfall-style project management anymore. "goto" programming has completely dissappeared. Etc.

What are your criteria for qualifying as automatic productivity improvement? Would garbage collection vs manual memory management count?

I wouldn’t say it “automatically improves productivity” - I suspect it might be limited to more intelligent and/or mathematically inclined programmers. That said, I think for many programmers not using it is a huge and pointless missed opportunity. This is one of those visibly high-return arbitrages that it pains me to see go unexploited.

I certainly don't want my criticism to be a call to avoid functional programming. I just get an uneasy feeling when I see it over sold, as well.

"mathematically inclined programmers." This kind of programmers are literally the worst I met in 25 years of carreer. They are underperforming very badly compared to others.

Based on your username I’m guessing you’re a web dev programmer of some kind? I wouldn’t expect that to match well with math-oriented people.

In fact I worked mainly with java and .NET C# in the past 2 decades ... Now I'm more into Node and Javascript ... I worked mainly in finance, banks and insurances. This is where I met all those underperforming math-oriented peoples. Most of the time they where not able to find a job in their field and went to programming as a way to earn money, not by passion like ALL the best engineers I met.

That's the problem with "uncommon": how do you obtain that background and how do you learn what you're doing? (of course, not just you - you, the entire team, and future hires)

The same way you learn anything else that is difficult: time and practice, and start with fundamentals. You can't put it on any work-related critical path until you have it down solid.

I mean in the context of an existing company / team of nontrivial size. Most cases I know of, the uncommon language was there from the days of it being a personal or 1-person project. For other types of tech (e.g. infrastructure) sometimes the new/different capabilities are such a defining feature that the lack of familiarity is not as scary. But in programming languages, you can fundamentally do pretty much anything in existing and well known ones.

Have fun writing a web app in assembly language ;). Yes it's been done, but not often, and for good reason. Haskell is sort of a special case: it's best suited for writing compilers, but has been pressed into just about everything else because people are into it for its own sake.

Yes if you're running a C++ shop and someone leaves behind a small program in Haskell, you're probably better off reimplementing it than becoming or hiring a Haskell guru just to maintain that thing. That's a question of whether to learn Haskell, not how to learn it. In the case of the linked article, the author was the one who decided to get the company involved with FP, and gave his thoughts on whether it was worth it.

I can certainly support the idea that someone juggling all the plates required to keep a company running, has no time to embark on a deep and nerdy self-education project in something as abstruse as FP. Better to keep it at the level of a side interest or hobby until you're comfortable with it, before even thinking of doing anything important with it.

a good attitude and some elbow grease

most "failed" FP projects I've seen mostly lack the former - often due to managers or engineers that come on the project after it first hits prod

then comes the rewrite to add a notch in said managers' and engineers' belts

then the original FPers leave and now there's systems in prod with little to no people who can work on it. that rewrite suddenly got a lot more business-critical!

the original FPers weren't as PM-savvy, so the rewrite is successful despite having less functionality and still taking a year or more. doesn't matter - the savvier managers and engineers know how to set goals & milestones that they know they'll hit and can say that they hit when evaluating the project's success

This is just a summary of my years of experience as an FP professional. I've seen this happen 3+ times across 3+ companies.

---

Haskell is by far the most worth-it skill I've cultivated. It wasn't easy but I really do do a 10x job on my personal projects in large part due to it. It's just not a good language to use in a corporate setting. It's better to get paid big bucks to be less productive. Save the technical brainpower for things you yourself find valuable :)

(and I sneak Haskell in all my jobs anyways - scripting, for instance - so I still develop my Haskell knowledge on company time & dime, despite the language being all-but-banned by the higher-ups)

My previous employer would teach new employees to use a functional language from scratch and people would be productive in 2-3 weeks. I don’t think it’s actually that difficult in reality.

You have to put a bit of time and effort into deliberate training, like most companies used to do for most positions.

> FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing.

That may or may not be true, but most programmers don't and aren't really all that interested in learning. Most know what they are doing in a handful of Algol-derived mostly-imperative OO-ish languages and aren't comfortable goony much afield from that.

"knowing what you're doing" is extremely hard in FP, as per the experience of many many productive imperative/OO programmers who tried.

Know when you have met your nemesis.

Switching fresh to FP: Now you have two nemeses.

viva jwz

Reply on news.ycombinator.com