Suffers from much the same problem as every rewrite story. They failed, I succeeded, therefore some random decision I made is responsible. I will tell you which decision you should think it was, but not provide sufficient information to verify my assessment. In particular, I will tell you about the stupid decisions made by those other morons, but not explain their reasoning.

Experience inspires more confidence in my heart than theorems do, though of course the author could be making everything up. It’d be nice to have more detail, though.

For example, by “purely functional” Prolog, do they just mean that they didn’t use assert and retract (making it stateless), or did they additionally restrict their use of Prolog predicates to a functional pattern, where backtracking was banned and one of the arguments of each predicate was used as a “return value”, and the others were always bound? If backtracking wasn’t banned, was cut banned? How about negation?

In its current form, this article simply says, “Wakalixes actually do matter. They actually do allow you to program better, faster and more cleanly.” Reading it will probably not help you to be a better programmer, unless you happen to be committing one of the beginner’s blunders the author calls out in the article, and even in that case it doesn’t tell you what you should be doing instead.

A problem with the credibility of the author’s claims for the wakalixes is that it’s hard to separate claims for the effectiveness of a language, or even a programming paradigm, from the effectiveness of the programmers who were programming in it, and especially the effectiveness of the social environment they’re embedded in.

Presumably if the 250 Java programmers working for the big-six firm couldn’t figure out how to reimplement a neural-network image classifier that one person implemented “on spec” after ten years, it’s not because they weren’t programming functionally — as the author pointed out, you can program functionally in Java; it’s because they weren’t making progress, probably because of mismanagement. (Or it might be because the author was just extremely lucky and chanced on such a great set of system parameters that 2500 person-years wasn’t sufficient to chance on it again, but I doubt it.) In ten years you can learn a lot about neural networks and image processing, and you can try a lot of different things. With a reasonable neural-network toolkit, which should take less than a year to build, you should be able to try about five or six million carefully-thought-out programming experiments.

A more likely culprit there is that they tried to plan out the solution of a problem that they didn’t know how to solve, which is a mistake the people often make even when they know better. As our own michaelochurch said, “Industrial management has a 200-year history of successfully adding value by reducing variance, because in a concave world, low variance and high output go together. In a convex world (as in software) it’s the opposite: the least variance is in the territory where you don’t want to be anyway. Convexity is a massive game-changer. It renders the old, control-based, management regime worse than useless; in fact, it becomes counterproductive.”

What would that kind of mismanagement look like in this case? Mismanagement by variance reduction here would probably involve optimizing the process to improve the chance that any given attempt would succeed, by putting lots of programmers on it and giving them lots of time, with the consequence that maybe in ten years they investigated three or four things that didn’t work, instead of five million.

Trying five million experiments isn’t enough, of course. You have to focus your efforts on things that might work, and learn as much as possible from each experiment. But speeding up the process of trial and error is a huge advantage, not just because you get more trials in, but because, due to hyperbolic discounting, the lessons of a quick experiment are much more memorable than the lessons of a slow one, in more or less direct proportion to their speed.

Also, if most of your experiments are going to fail — as they should, to maximize variance and the chance of netting a unicorn — experiments that fail quickly are much less demoralizing than experiments that take a long time to fail. (And of course you want to minimize people’s incentive to whitewash the results. Especially people with high prestige. For example, failed experiments often drag on for years because managers are afraid of losing headcount.)

As this process continues, how do you prefer to focus resources to the more promising exploration directions, while continuing to devote substantial effort to the dark horses? In a sense, the traditional CYA management approach errs in the direction of overfocusing on the most promising candidates. It turns out there is actually a bunch of applicable research, some of which, like multi-armed bandit algorithms, actually is being applied at some companies to the problem of managing R&D and has a robust management research literature, while other parts, like A* search, is overlooked, as far as I can tell.

And all of this has only a limited amount to do with your programming paradigm. You can iterate quickly in Java, you can iterate quickly in assembly, and you can iterate quickly in Haskell. The obstacles are different in each case, but you can do it.

I agree with kragen: I’m fine with this sort of argument being based on experience; what else could it possibly be based on?

I have another problem with it. The author claims to have been working in computing for… well, I don’t feel like trying to track down their LinkedIn as they suggest, especially since their name doesn’t appear to be anywhere on the site itself, but presumably “longer than you’ve been alive” is supposed to mean several decades at least. I resent both the assumption and the ageism there, but I suppose that’s irrelevant.

But anyone with that much experience is going to be able to solve much harder problems than people with dramatically less. Even the author themself would have to do serious introspection to have any confidence that their efficacy is due to the choice of paradigm rather than to the experience. And, frankly, I don’t believe it - I’m confident that, all else being equal and apart from any difficulty caused by being annoyed about it, the author could do these dramatic rewrites in any paradigm.

Also, of course, they don’t say anything about how maintainable people found their rewrites, after they’d moved on to the next one. The reduction in number of lines is suggestive, but it seems like we’re supposed to take it for granted that these were substantial improvements, when all that’s really being claimed is that they were successful replacements.

I’m a big fan of functional programming, and actually for a lot of the reasons the author alludes to. They just haven’t demonstrated a connection.

I agree with your statement. Is such way of promoting functional programming really needed nowadays? Let’s all consider that no matter how many valid and provable arguments you will provide to an established (imperative OO C++ community toxicity) status quo, the only way you are really going to sway them to your side, is by producing code that outperforms their solutions, both in terms of developer scalability and actual execution of the resulting binaries. And it is proven that this can happen, so why are we going again over this through personal viewpoints?

The problem we are having with modern functional programming languages is that because legacy companies base their success on legacy code written in legacy languages, they need to maintain the counterproductive rhetorics around. This is a very twisted side-effect of inertia, we should not feel compelled to reply each time, anymore.

edit: typos, more clarity :)

Unfortunately, I find that language/approach evangelism is hard to do in a principled, scientific way, because it fundamentally isn’t science in most cases. It’s business. And if you stick to conservative arguments supported by evidence (evidence from experiments that you’ll almost never be allowed the time necessary to perform, so you’ll have to use what’s already on the ground) then you’re often going to lose against an opposition inclined to dishonest arguments (e.g. “if we use Haskell instead of Java, we won’t be able to hire anyone!!!!111”) and phony existential risk.

The OP, at least, can convincingly tell a personal story of success that he owes to functional programming. Is it scientific proof of the “superiority” of FP? No, of course not. It’s still much more useful than a lot of what pops up in the discourse around PL choice.

Hello and thanks for the interest. One of the applications of such a feature would be in the field of template metaprogramming generating code for parsers. See things like PEGTL. Another application is in things like type-safe printf, DSL embedding etc, see Sincovics’s academic work on such string use. It is true I need to make a better readme, but I wasn’t expecting the interest it got in certain grounds, I mostly authored this because I needed the standalone functionality for my own work in a very tight package. Technical analysis is available inside the header.

In essence, it takes a string literal or an array with constant expression semantics representing a string literal and transforms it into a single type through the instantiation of a template whose char-typed non-type template parameters in the template parameter list are the characters of the string. Now imagine being able to parse that compile-time and generate code according to a “language” you yourself designed through TMP.

@bitemyapp

I didn’t want to post anything like that into the blog post, but since you’ve started going personal, I have to defend myself.

a) when I have started, I was searching for help. But since the most basic concepts were rather clear for me, I was left all by myself in majority of times. I can bring up all the occurrences of myself asking questions about things like thunk leaks, about monadic order swapping. How many times they were answered? Correct, zero.

Once a very kind person helped me to understand Monadic Transformers. I will never forget his kindness.

b) I refuse to try posting things to the mailing lists because there were multiple times when people from Haskell community were responding my questions with simple “this is Functorial, everyone should know that”, or “you should be smart enough to figure that out” and other humbling things.

c) There is a false assumption that I am having problems with Haskell. I do not have any problems with Haskell. Assuming that if other people do not like something, they automatically do not know something is false and misleading. I’m saying that Haskell will take a long time to learn. I did learn it (read several books, and caught up on theory), and I have no problem programming it.

I have to wonder if modern civilization (bridges, video games, clean water) would exist if everybody had that attitude.

This is exactly the point I had. You say that Haskell is “next level”. I say no. There’s absolutely nothing special about Haskell. And we all should live with it.

It’s very easy to say what I’ve done was a recipe for failure: https://twitter.com/bitemyapp/status/541962675488452608 Although I can’t say it’s a failure due to two reasons:

• I’m still writing the DB, and in Haskell
• I’ve learned a bunch of stuff, including how to profile Haskell apps, hunting thunk-leaks, crafted FFI tutorial that has already helped a lot of people, and contributed 2 patches to GHC.

As for me, even if I had to drop the DB itself it was a success.

I think that his tone is positive in the sense that one has to know how an algorithm works in order to be able to implement it in any language for example.

I do not think that he disagrees that learning the language itself is important since there are languages that allow certain algorithms to be implemented nicely and others that do not. However the true beauty of functional languages is how closely they are related to the abstract concepts behind commonplace constructs we use in different (even imperative) languages.

In that case, languages like Haskell are in an advantage respect to languages that are more clumsy in their functional characteristics, so yes, the language is important in that respect. But the notions behind what you do are more important in order to use it efficiently.

Correct, I missed that!

I don’t know about a concrete article, but I’ve seen a couple of posts especially from around the Linux Kernel about the bad atmosphere and environment. Personally I have a little “treasure” chest of comments from Linus that are extremely poisonous and dismissive.

Personally I never had to encounter many of these incidents, as the communities I’m involved in are mostly extremely nice and helpful. New members mimic the behavior they see. I think it has a lot to do with leadership - leaders get the community they create through their own behavior and the behavior they choose to tolerate.

For what concerns me, I begin to think that focusing on F# for a while has been a good investment in view of these developments.

I don’t know why this person is leaving, but as a Debian user, I like that nothing “exciting” is happening. That’s why I use it.

If I wanted bleeding edge, breaking changes, and incompatibility, I wouldn’t be using Debian. There are plenty of distros for that, but I appreciate that Debian is more stable.

I do not think that asking in our small niche of the internet would be a bad idea. Programmers are by nature of their trade a creative work force and most of us have been ripped off at least once in our career. It is how you deal with it that matters and what you do after.

You are correct that he should know the full story before hand. Most of the times it only makes you angrier though, regardless of who is actually responsible and why. I would move away from an environment where ‘credit’ issues pop up due to ‘misunderstandings’. There are no misunderstandings and there are no coincidences in credit matters.

Since the comments mention the Socratic method, that’s something that resonates with me: the only time I went to #haskell IRC with a question, the attempt to use the method didn’t sound like treating me like an educated adult capable of taking initiative, so it felt condescending, and really, it was a waste of everybody’s time. Of course, I can understand if the person made wrong assumptions about my question, but what’s wrong with a straight answer? As an adult, I’m perfectly capable of looking for, say “blargher co-types conjecture”, and I don’t need hand-holding. My main takeaway was to not ask more questions in #haskell :)

It’s the combination of being unable to convey the tone of your message with the brevity that removes all possibility of explaining the nuances or the context.

For what it’s worth, I did find this interesting. I upvoted the list of links from the Haskell wiki so I can dig into the meaning behind the post.

The succinctness of the explanation is certainly helpful for people already familiar with Haskell and the concept of Control.Lens.Fold. That should not discredit, of course, any effort to explain perhaps difficult concepts to a wider audience. This is just a general observation, I know that was not your intent.

I did not downvote your post. I also did not upvote it. If you had posted a comment on another thread discussing transducers and mentioned the similarity to Control.Lens.Fold in Haskell and provided a link, I would have certainly upvoted it. You are right, it is helpful to realize there is a relationship to existing concepts when you are trying to understand something.

Thank you for bringing this to my attention.

I seriously do not understand the downvote here, since this is neither trolling nor off-topic. I think that the “off-topic” and “troll” downvotes are simply from people ignoring computer science theory of the last 2 decades (to say the least). And you can do things like this in Rust by the way. So this is just seriously rude for the sake of being so. If you do not understand error and exception handling using monads it is your problem.

requires doing it twice

More the case when you’re first learning. You learn to anticipate what you’ll want with experience and the laziness is a non-issue for most Haskell code out there. Much like how you learn patterns, anticipate the application of approaches in the languages you know.

Whole-heartedly worth it for me, the complexity management (able to scale to larger projects), runtime efficiency, compiled binaries, Best-of-our-industry concurrency kit, best type system that isn’t costly time wise, etc etc

I came to Haskell from Clojure. I spent more time futzing around with perf and laziness in Clojure than I do Haskell :)

I’ve sunk my teeth in to Haskell and, coming from Common Lisp, my biggest hurdle so far is: syntax :-)

But I guess it’ll grow on me. It does make picking up the language quite a bit harder though, having to look up every other symbol, so I hope it is worth it in the end.

If they ever think of expanding it without those design limitations, perhaps a woefully designed language for such things as C++ will become slightly better. I am amused that they started doing these things at a language feature level. Until then they are only introducing a shortcut to std::accumulate, in my eyes.

I think that they are eventually going to be dealing with function identifiers and lambdas being allowed in place of the operators, given that in C++14 they have introduced polymorphic lambdas. There seems also to not be a syntactic collision with either using a function identifier or a lambda for doing the fold. Unless they get “scared” of complicating the language by getting into more practical functional programming territory with such an obvious addition to this.