Learning Haskell is no harder than learning any other programming language - <AUTHOR> https://williamyaoh.com/posts/2019-10-05-you-are-already-smart-enough.html <comment><USER2> The biggest lie about Haskell is that it's easy to learn. No it's not, and I do use it at work. Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects.

But, even if you finish the Haskell Book([http://haskellbook.com](http://haskellbook.com)), which is like 1300 pages, you're still going to be unable to contribute to a serious code base. Anyone who says otherwise is lying. Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. Now you have to understand how to really structure a program as either a stack of monad transformers, or free monads or anything else. Then you get into concurrency and to do that you have to understand how Haskell actually works, what non-strict computation does etc. etc. Otherwise you're going to get some nasty behaviour.

You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens.

Don't get me wrong, Haskell has spoiled me, and I don't really want to touch any other language (I still like Clojure, Rust, Python, Erlang). Once you get past that the language is a joy to use.

<comment><USER3> You don't need to understand the internals of a thing to use the thing.

<comment><USER4> This has not been my experience of using technology effectively. Without an understanding of the implementation details, you inevitably use something inefficiently or for not quite the right purpose.

I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. Get to a certain scale and it's not enough to know about indexes; you need to understand the structure of b-trees, disk I/O performance, how CPU cache performance affects b-tree navigation even when index is cached in memory, how to use compound indexes effectively to reduce random access through the index, etc.

The constraints of CPU and memory never go away, and if you're trying to scale something, you're going to be limited on either or both of those resources. That in turn forces you to understand execution and memory behaviour of the abstractions you're working with. All abstractions leak when pushed.

<comment><USER5> > I cannot imagine anyone using a database effectively on any significant > amount of data without understanding indexes, how different joins work, why > join order is important, what effect join orders have on performance, etc.

But conversely you probably didn't have to understand what filesystem the database runs on, whether it is in a RAID array, whether the network connection was over Ethernet or T1, etc.

All abstractions leak. The question is _how_ leaky they are. In my experience Haskell abstractions are much less leaky than most.

<comment><USER4> I did and do; when performance at the database level isn't right, you need to look into OS stats, I/O stats, disk stats (the SAN is an area ripe for unexpected contention, RAID5/6 act like a single spindle and inhibit random access in ways that RAID1 or RAID10 don't, stripe length in RAID5/6 bloats the size of small writes, etc.), but I had to stop somewhere :)

<comment><USER3> > but I had to stop somewhere

Why? You seem unsatisfied with any of the previous layers of abstraction, so where does it end? When can I truly call myself a user of a database?

<comment><USER6> When you don't have to fix it when it stops servicing requests, or worry about scaling workloads.

When you treat it as a black-to-grey box, not a grey-to-white box.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Coincidentally: it's also the only programming language I know of where someone has written a lengthy blog post about how I'm in fact, _not_ too dumb to comprehend it.

<comment><USER8> I didnt think about how hard Haskell is because I never forced myself to learn it. It just didnt interest me. With Java or C# I can make so many things with minimal friction. The other language that people talk about being hard is Rust. I am going to assume theres blog posts about it not being hard.

I like that with Go or Erlang everything I learned 5 or more years ago has still stuck to me. With D I can be effective quickly. With Rust I struggle a bit. Rust is probably great for building a web browser but doing backend web development feels way more work than Go or even Python (CherryPy). Haskell I dont even remember a darn thing anymore.

</comment></comment><comment><USER9> Haskell was used in the first programming class at university and that was excellent. Some people that already know how to program had to throw their preconceptions out the window. So everyone was either a novice at programming entirely or at least a novice at functional programming. It wasn't problem at all. I'd argue most students wrote better code in that class than they did in the imperative/OO classes that followed. _Especially_ the students that weren't (and likely never did become) programmers.

The thing about imperative and OO programming is that it's hard to do _well_. I honestly havent seen more than 1/10 developers write "good" OO code even after 10 or 15 years as professionals. Large scale OO is a cognitive load that requires extreme focus, skill and talent. I prefer functional (or OO using an extreme functional discipline like all immutable types etc) because _I don't have that talent, focus and skill_.

My point isn't that Haskell should be the language of choice. I think it's a great language but I think e.g laziness makes it too hard to reason about performance and behavior. Today I'd recommend F# I think.

<comment><USER10> And how many people dropped out of CS because of that first Haskell course? I saw plenty of people struggling with Python initially and I know exactly how they felt later when we had to learn Haskell.

I think if I had to learn Haskell first, then I would've just given up at the start.

<comment><USER11> Where I did my CS degree (Imperial College London) , Haskell is the first language taught (before Java and C).

To my knowledge across 4 years there, nobody ever dropped out because of the Haskell.

People usually struggled with the maths instead.

People also did not have more problems getting Haskell concepts right than linked list modification in Java.

<comment><USER10> They might not drop out specifically because of Haskell, but I don't see how it wouldn't be a contributing factor. The Haskell course here was pretty much just a struggle for almost everyone that took it.

<comment><USER12> Mind the opposite: finishing a bachelor's without ever having to deal with a functional language.

I've met a lot of people (at work and post-grad) who have graduated from colleges without an idea of what a functional language is or the concepts behind them. I don't blame them, but its a pity to find so many workarounds in legacy code which could have benefited from functions as parameters and less state in general.

</comment></comment></comment></comment></comment><comment><USER13> That just reads as:

"You are already smart enough to write Haskell"... if you accept that you are too dumb for most of Haskell and are therefore okay with being cut off from most of its ecosystem.

Digging into a dependency due to a bug or custom feature is something that usually happens on any bigger project of mine. If I have to expect that I won't be able to work in a dependencies codebase because it will most likely contain (multiple) concepts that I won't be able to understand, then that's a big no-no.

<comment><USER14> I have only done Haskell during college and my friend is doing Haskell in web backend in production so I'd say I have a pretty good feeling about the skill gap in Haskell. There are many concepts that he tries to explain to me which I don't get 100% but it really does feel like all I need is more time. It was like that at first with monads and then phantom types, row types, hkt etc. I'd say the biggest detractor for people is that it takes more than 1 blog post and 1 hobby project to comprehend everything. It may take 1-2 years to learn all the concepts. To me the beautiful thing is that the concepts learned aren't some language quirks but instead general programming/math concepts which you simply cannot think about in simpler languages like C#. With all that, I'm still heavily put off from Haskell by all the tooling and I just can't let go of the comfort of working in Visual Studio. In 10 years I hope either C# gets some of my favorite things from Haskell like HKT and better inferrence or Haskell gets better tooling and broader ecosystem. My bet is on the former but gafter keeps postponing HKTs spec after spec.

<comment><USER15> If you feel like messing around with Haskell again for an afternoon then install VSCode with ghcide (and a syntax highlighting plugin ofc). You might get surprised ;)

<comment><USER16> Are you using that? Doing Haskell on vscode has been a painful experience for me.

<comment><USER15> Yep, all my team has switched to VSCode+ghcide and so far we're in love with it. Mind you ghcide is brand new, so this luxury of having a 21st century Haskell IDE did not exists even just a few months ago. Before we used ghcid with whichever editor (eg. Vim/Emacs/VSCode).

<comment><USER16> Thanks, I'll switch to it now based on your recommendation. Desperately want a decent Haskell editing setup, the bad tooling is killing my productivity and making me consider quitting Haskell.

Edit: Ok so I tried it. Template Haskell seems to break it, which my projects use heavily. And does not even report syntax errors in some files. Seems like yet another dead end for me as an editor setup, unfortunately.

<comment><USER15> Ah yes TH. That's imho the last biggie in the way of total awesomeness. See this ticket: [https://github.com/digital- asset/ghcide/issues/34](https://github.com/digital-asset/ghcide/issues/34)

<comment><USER16> Got it, I'll keep an eye on this. Thanks for this recommendation!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> No one has ever been able to explain to me why I should use Haskell instead of something else. I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

I know Carmack has presented a case to code in a pure functional style here [https://www.gamasutra.com/view/news/169296/Indepth_Functiona...](https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php) but that somewhat precludes the necessity of switching to another language from C++. Further, he advocates for a new keyword 'pure' to assist the compiler like const does, perhaps not knowing that const doesn't actually help the compiler out in practice.

<comment><USER18> > but I never get the sense that they fit into an overarching strategy for how > my life will be made easier by using Haskell.

I would add that the elitist signaling that is rampant in functional programming in general and the Haskell community in particular is also not helpful.

<comment><USER19> I guess that's the main problem.

And look, defining a problem functionally works great on 10% of the cases, but it complicates some 40% of other cases (very imprecise numbers).

The world is not functional, as it turns out. And a lot of those cases where you can write functionally don't gain much from a performance or correctness perspective compared to the procedural version

<comment><USER3> > The world is not functional

What does this even mean? If the world is not functional, then what is it? Is the world procedural? And what world are we talking about? Our planet, physically? Are you then discounting the worlds of mathematics and logic? You don't gain performance? What performance? Program execution speed? Development pace and time to market?

Compared to the procedural version? Is your view that procedural programming is inherently better — for any definition of the word — regardless of context? Would SQL queries be easier to write if we told the query planner what to do? Is the entire field of logic programming — and by extension expert systems and AI — just a big waste of time?

So many vague aphorisms which do nothing to further the debate. And Haskellers are the ones getting called "elitist"!

<comment><USER19> It's not vague, processors are still procedural. Network, disk, terminals, they all have side effects. Memory and disk are limited.

SQL queries are exactly one of those cases where functional expression of a problem outperforms the procedural expression, and that's why they're used where it matters.

<comment><USER5> > processors are still procedural

Exactly. I don't know why Haskell fanboys insist on abstracting us so far from the machine. Declarative programming is really unhelpful because it says nothing about the order in which code executes.

We live in a mutable physical universe that corresponds to a procedural program. One thing happens after another according to the laws of physics (which are the procedural program for our universe). Electrons move one after another around circuits. Instructions in the CPU happen one after another according to the procedural machine code.

The universe would never consider running 2020 before 2019 and a CPU will never execute later instructions before earlier instructions.

Haskell fanboys talk about immutable data structures like it's beneficial to go back in time and try again. But it's a bad fit for the CPU. The CPU would never run some code and then decide it wants to go back and have another go.

<comment><USER20> You're saying a lot of wrong things about CPUs. CPUs do execute instructions "out-of-order", and they do speculative execution and rollback and have another go. Branch prediction is an example.

All of this is possible only with careful bookkeeping of the microarchitectural state. I agree the CPU is a stateful object. But even at the lowest level of interface we have with the CPU, machine code, there are massive gains from moving away from a strict procedural execution to something slightly more declarative. The hardware looks at a window of, say, 10 instructions, deduces the intent, and executes the 10 instructions in a better order, which has the same effect. (And yes, it's hard for me to wrap my head around it, but there is a benefit from doing this dynamically at runtime in addition to whatever compile-time analysis.) In short, it is beneficial to go back and have another go.

This was demonstrated also in [https://snr.stanford.edu/salsify/](https://snr.stanford.edu/salsify/). If you encode a frame of video, but your network is all of the sudden to slow, you might desire to encode that frame at a lower quality. Because these codecs are extremely stateful (that's now temporal compression works), you have to be very careful about managing the state so for can "go back and have another go".

I am less confident about it, but what you say about the universe also seems wrong. What physical laws do you know take the form of specifying the next state in terms of the preceding state? And literally many of them are time- reversible.

<comment><USER5> Thanks. It was an attempt at parody but apparently I didn't lay it on thick enough. I'll try to up my false-statements-per-paragraph count next time.

<comment><USER20> What you wrote about CPUs many people believe, and many simpler CPUs operate like that. So it was difficult for me to detect as parody. Sorry that I missed it! It's funny in hindsight.

Not sure what the parody was in computing 2020 before 2019.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Imagine you spent a career learning the piano. Would you expect to pick up the violin as if you were an expert?

Would it be reasonable to declare violin sucks! I've played piano for 30 years, vibrato is so hard it must be wrong, tell me why I should learn the violin?

Actually probably a lot will come with you, your dexterity and music theory will be quite useful, as will your ear.

But really, the instruments are very different and if you want to level up your sense of pitch or really learn how to _sing_ a melody, the violin can be great for that...

<comment><USER22> Are you replying to the wrong link? The link is about programming fyi

<comment><USER21> I'm trying to draw analogy to maybe something less inflammatory.

Most of us here are programmers, a lot of us professionals.

Music is the output of musicians, as perhaps code is the output of programmers.

But music comes in all kinds of flavours: classical vs jazz vs pop

Performance vs composition

Recital vs improvisation

And then choice of instrument within any of those areas.

I feel a lot of people misplace their aversion to Haskell because they fail to recognize how _different_ Haskell is.

It's a bit like when English speakers think Chinese is a "hard" language. It's not, linguistically it's actually a pretty simple language (whether the script is easy/hard is up for grabs...)

Actually Chinese is just _different_ to English so you have few anchors and familiar friends to base things off so it feels hard cos you're starting afresh, like a child. And yet children of a china manage quite fine learning chinese....

Meanwhile, ask a Spanish speaker about their experiences learning Portuguese...

</comment></comment></comment><comment><USER23> There is some utility in carving out a subset of a language to make the remaining part easy to comprehend and easy to contribute to. C++ is a large and complicated language but every team seems to be using a different subset of it. The same thing would happen with Haskell. Every one might have a different idea of where to draw the line for restricting advanced features. The author might decide that Haskell 98 plus OverloadedStrings is good enough. That's a valid stylistic choice. I would have drawn the line further; I personally think features to simulate dependent types aren't worth it (think singletons or DataKinds or TypeInType) but lens is absolutely necessary even though it is difficult for beginners to understand. But ask a colleague of mine, and you might receive a response that we should embrace complicated type-level programming like the kind seen in Servant, but instead restrict TemplateHaskell. All these are valid stylistic choices but they fragment the community. And eventually debugging other people's code bases (say dependencies) you would sooner or later have to face features you don't use.

Let us not forget the roots of Haskell as a research language where ideas in functional programming are to be tried out. When it emerged in the 1980s it was literally because a committee wanted a solid foundation to replace a disparate mélange of functional programming languages. It succeeded in that, and immediately introduced new features then considered highly novel (e.g. type classes). In this sense, Haskell will never be as practical and pragmatic as Go, where moderately modern language features aren't even in the language. Choosing a language like Go could be a valid choice, and so is choosing a language like Haskell.

</comment><comment><USER24> Haskell is no doubt an interesting language. I have yet to work on a project where it was the obvious choice but I've played around with it enough to like it.

What I don't like are some (not all) of the people who use Haskell and talk about it online. They can be incredibly obnoxious. Haskell is not a tool they work with, it's their entrance to a _class_ of software engineers that you're not capable of being part of.

Just for the record: Anyone can learn Haskell. If you're struggling with it that's because of a tooling / literature issue. Haskell people (even the nice ones) are bad at explaining the language. The tooling isn't very friendly and the language is a shit sandwich to debug.

The concepts therein are no more difficult to grasp than any other in programming. Is a Monad a box or a burrito? Please stop. It's a language feature that allows you to do certain things more concisely than the alternative. Stop pretending it's magic and show people how to use it and _why_ they should. Stop drawing pictures.

No, algebraic data types are not hard to understand. You just make a big deal out of them because you think the word algebraic sounds cool.

I could keep going but I think I've made my point.

Dear Haskell people: Get over yourselves. Do not mistake the larger software community's disinterest in your pet language for their inability to use it. That's simply not the case. If people _had_ to use it even 'lowly js devs' would master it.

Everyone else: If you haven't used it already it is a very cool language and worth learning even if just for personal edification. Don't let the self appointed high priests turn you off. Don't expect their help either.

<comment><USER5> Sorry you've experienced this obnoxious behaviour. I've been in the community for years and never seen it. Maybe I'm not hanging out in the same places as you or I have some sort of unconscious bias that means I don't notice it.

Could you link me to an example? I have some measure of authority in the community and would like to help decrease the amount of obnoxiousness but I can't unless I know where it happens.

> Dear Haskell people: Get over yourselves. Do not mistake the larger software > community's disinterest in your pet language for their inability to use it. > That's simply not the case. If people had to use it even 'lowly js devs' > would master it.

This is really interesting because the Haskell community I hang out with (mostly on Reddit) would _love_ it if "lowly js devs" would master it. In fact we all too often get told by non-Haskellers that "Haskell will never succeed because it's too hard for most programmers to learn"!

<comment><USER25> Well, what about this article? It claims I just have to understand 4 basic concepts to replace java, python and Ruby.

Great, so using those simple properties let's reimplement Eclipse. Let me use tensor flow. Replace my Ruby on rail website.

<comment><USER5> I can see how (certain interpretations of) it could be considered _wrong_. I'm failing to see condescension.

<comment><USER25> The condescension is the authors assumption that this is right, and a tiny fraction of haskell can replace all uses of other major programming languages.

This to me (as a non haskell user) implies other languages can't have anything interesting to offer, as they can be so trivially replaced. That is the type of attitude I see from haskell programmers.

<comment><USER5> I see. Interpretations of that particular passage range from all the way from trivially true (Turing completeness) to trivially false (I can't build anything that uses Ruby on Rails in Haskell). Certainly there are some intermediate interpretations, like the one you suggest, by which it is condescending.

</comment></comment></comment></comment></comment></comment><comment><USER26> I remember Rob Pike unveiling Go at a Google talk years ago and some Googler got up and said "why would Go be better than Haskel?" and Rob said "Because I can't understand Haskel source code and I'm pretty sure you could understand Go source code right now."

<comment><USER27> I think this is still one of the strongest selling points for Go. It is a pretty solid language with a few basic concepts which are repeated constantly. Sure, it doesn't have generics, error handling is a mess and the language design isn't as consistent as it should be.

But what it does, is pushing everybody to write simple code which is easy to understand. So many times I found the documentation (of some library) to be incomplete, but jumping right into the code answered the questions I had. I can't say that about every language.

<comment><USER26> Totally agree. When I first encountered Go, I kinda hated it for its lugubrious combination of being rather "braindead" and opinionated about being braindead at the same time. Typing it every day gave me flashbacks of programming Java circa JDK 1.4 (before the compiler-only based generics were introduced in 1.5, which I still believe didn't solve enough problems for the complexity it added). In short, it felt like a step backward.

But after seeing its gc performance sitting at the single-digit ms timeframes with huge heaps (60 gigabytes!) I realized I needed to hold my nose.

What helped me make peace with it is its automated testing story. It's baked into the language in a way I've rarely seen in any other runtime.

</comment></comment></comment><comment><USER28> Blog post that explains Functors, Applicatives, And Monads in pictures [http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html)

<comment><USER29> Condescending tutorials seem to be an integrated part of Haskell culture. The rationale might be that people who don't already know Haskell should to talked to like kids. "Don't be scared, a monad is just like a Burrito!" and so on.

I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available.

I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.

<comment><USER30> The only condescension I see in Haskell-related discussion is condescension towards Haskell _ers_ , claiming that Haskellers are condescending and say condescending things like writing condescending tutorials.

As I see it it's actually not very nice.

With the utmost respect, truly, humbly: I am against this custom that it's just fine to call well-meaning people for condescending. As it appears to me, claiming condescendence is more of a statement of the claimant, but this is still an unfortunate custom. Who are we _really_ to claim condescension? Really?

The article linked to in the post starts off with quotes from people who directly state that they feel like they would need to be smarter to use Haskell. It's a common thing. The article addresses that. It is literally the opposite of condescension.

Then there's the burrito tutorials with pictures. I for one actually think in weird abstract sloppy metaphors and colors. My head really is full of burritos and inaccuracies. I was helped enormously by the burrito concept. Textbooks generally don't speak in burritos. I work with people to whom the burrito class of analogies is not helpful. They think in a more direct and crystalline way. I wish I were more like them. And I try try to be. And I can. And it makes me better. And I really do think I also bring something to the table by spraying flaming burrito concepts and lateral jumps into the team zeitgeist.

<comment><USER29> > I was helped enormously by the burrito concept.

OK fair enough, I can only speak for myself and the way I learn concepts. The way I learn a new language or platform is always to try to write a real program that does something. I am only able to lean concepts when I can see their usefulness. But I should recognize that other people learn in different ways.

<comment><USER30> I want to add that I actually do see how it comes across as condescending. After this exchange and thinking about what you wrote. idk, like, "Here, look at these kiddie pictures, those are suitable for you, and then I'll withhold the real work ok?"

</comment></comment></comment></comment></comment><comment><USER31> If learning it is no harder than any other programming language that presumes that every other programming language is equally easy to learn. Furthermore it assumes that people have an equally easy job learning whatever language they learn.

Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.

Also I did try learning Haskell at one point and I found it harder than some other languages, I would say I found it Erlang level hard which I tried at about the same time( about 2009) but I think Erlang has a little more inclusiveness to their community IMHO

<comment><USER3> > Neither one of these conditions are remotely indicated by research on the > subject, therefore the statement is false.

What is the standard unit of measurement for quantifying just how difficult a language is to learn? Is there a standard unit of measurement for quantifying the competence of a person learning a programming language?

<comment><USER31> I'm pretty sure the field is too young to have developed a standard unit of measurement of either of these things, if there were such units their creation would be one of the stunning intellectual achievements of mankind in recent history and would have such obvious benefits to many other parts of human endeavor that I would expect it would be a field more investment heavy than machine learning at the moment.

However it has been shown that there are people who seem more attuned to different learning styles, styles of programming, there are differences in difficulty between first language acquisition and later (dependent on language similarity, language domain), and many other studies regarding programming language learning that it can be said not everyone learns equally well every language, and not every language is equally as learnable.

<comment><USER3> > it can be said not everyone learns equally well every language, and not > every language is equally as learnable.

I think that's reasonable, but the question is then at what point does a language become sufficiently difficult that it no longer provides a good return on investment? And to what degree of proficiency must one achieve in a language in order to productively use it?

It doesn't take a long time to learn all of Elm, and you can be productive in it quickly.

It takes a _very_ long time to learn all of Haskell, but it does not take a very long time to be productive with it.

<comment><USER31> totally agreed, and I suppose in Paul Graham's concept of a Blub programming language there might be a language that is difficult to become proficient in but allows you to achieve things that would not be reasonably achievable in other languages.

</comment></comment></comment></comment></comment><comment><USER32> The company I work for defaults to F# when choosing tech for a specific project.

We defaulted to PHP and C# in the past.

We have quite some experience training people who just graduated and even people with backgrounds outside of tech.

Training someone from zero to autonomously writing production code is a lot easier in F# compared to PHP and C#.

We educate people in Elm and Haskell and switch over to F# when they're ready to try building the first real thing end to end.

<comment><USER33> F# is really a very nice pragmatic language. C# keeps cannibalizing features from it, which is both good and bad...

<comment><USER34> As a die-hard .NET/C# developer, I would be curious what you perceive to be the 'bad' side of that coin. I assume something like LINQ would be classified as 'good'?

<comment><USER35> What he meant by bad is probably the fear that MS will abandon F# once C# has borrowed enough features from it.

<comment><USER33> The other unfortunate is that as C# accretes features, the old still hangs around. Eventually you end up with too many valid ways of doing things, and cruft that either can't be worked around or was never updated.

It's been over a decade since generics were introduced, but I still encounter code using ArrayList today...

</comment></comment></comment></comment></comment><comment><USER36> Maybe I missed it, but what's the best way to learn basic Haskell? I was expecting a tutorial. Or link to one.

<comment><USER37> [http://learnyouahaskell.com/chapters](http://learnyouahaskell.com/chapters)

<comment><USER38> NO. Not that one. It explains the easy parts at (boring, pseudo-funny) length and expects you to understand the hard parts after a few sentences.

<comment><USER39> It's good at explaining those easy parts, though. It also encourages experimentation in the REPL. For a more complete understanding, I agree that it must be accompanied by some more reference-style material.

</comment></comment></comment></comment><comment><USER40> I always wondered whether imperative languages feel more intuitive to most programmers because they are:

a) Inherently simpler and require no prior advanced knowledge of math.

b) They are the default in every curriculum and once your brain is wired that way everything else seems counter-intuitive.

I remember in the first grade of my elementary school we were taught basic algebra and how sets work (union, intersection etc). I understood both concepts but I couldn't relate sets to the outside world. Like why do I even need this. Maybe new programmers feel this way about functional languages and Haskell.

<comment><USER41> Try:

c) That's the way microprocessors actually work. Machine language is just imperative commands and branch instructions.

</comment></comment><comment><USER42> I am a skilled Scala developer with knowledge of FP sufficient enough to make two contributions to the Typelevel cats/kittens ecosystem. Yet I was not even able to start a hobby project in Haskell. I always start and fall back to Python shortly after. Is it just me?

<comment><USER43> That's actually interesting. Was it the base prelude typeclasses that are too different ? AFAIK scala uses monadic code too .. I expected not too much difficulties using haskell. Maybe that's the syntax ?

<comment><USER42> Scala has an awesome IDE support, familiar rich JVM ecosystem, familiar syntax, ability to ignore the fact that logging is a side effect...

I had a hard time understanding the Haskell ecosystem, plus the syntax is just way too different and restrictive.

For example the last tutorial I tried to follow recommend using nix package manager to install Haskell. I failled missereably, it just did not work out of the box.

<comment><USER43> I see, I had more luck using stack but I understand it was a matter of luck.

someone should make a haskell fiddle for newcomers

ps: I wouldn't think that syntax would matter that much, was Scala your first FP language ?

</comment></comment></comment></comment><comment><USER43> I'd argue that it's not as simple. But there's a relativity factor here.

1) Haskell is much like math. You look at some concepts and ideas and fail to see what it is about, until 20 years down the road you finally click that "maaan" discrete mathematics was already encompassing 90% of computation it just wrapped it in counting instead of concrete computer instructions. Mathematicians have this culture of going too far, too concise, too fast for most of the population.

2) Mainstream culture imposes a negative toll on this because when you're fed Java or PHP (let's say you learned in the 2000s when they were peak fad) you'll interpret Haskell through them, brain already set on a belief, and it will make it twice harder. And it's really hard to disentangle the weird bliss of being able to manipulate elements through an interface (here it would be the syntax its idioms) from "objective reality". I too was enamored by PHP associative array syntax (so fun compared to C or Java lack thereof) and F5 to see a website change before my eyes. Haskell feels like a punishment compared to this. Not even counting the social aspect of it .. wordpress made people have colleagues and money.

Anyway, keep learning haskell (and FP, and logic, and math).

</comment><comment><USER16> The real question is is it worth the time & effort.

<comment><USER34> From my perspective, it isn't cut-and-dry. The quick response I give is:

If you are developing a business application and no one dies if something goes wrong for a few hours, the answer is "hell no". Productivity takes a hit for no strong upside to the biz.

If you are developing a safety-critical system, the answer is "maybe". This one is more obvious.

The more complex reasoning is that ultimately, almost every software system has to interface with the outside world in some way. Putting your functional programming layer as your principal interface between your internal and external domains is an extremely high-cost endeavor due to the complexity of handling things you can't predict. If your system is safety-critical, and you have extensive control over the external domain (e.g. dedicated, redundant sensor networks), you might be able to justify this added complexity because you can control many more variables than you would be able to otherwise.

An alternative approach that seems ideal to me at this time is to use imperative techniques as the principal architecture, and then use functional within that domain in the specific cases where it can be justified. Good examples of this would be C#/LINQ, or even invocation of F# from C# (e.g. rules engine). Imperative is extremely good at handling side-effects and managing exceptions. Functional is deterministic if you can keep it on rails. Using both where most suitable w/ interop between seems to be the most productive approach.

A quick corollary could be: "If you are _exclusively_ using functional techniques to build your application, you are probably making a mistake".

<comment><USER16> I'm writing most of my apps in Elixir which is also functional. I got no problems wiring side effects with it despite it being less imperative than some C#/Java/friends. In fact, I'd write high availability apps on Elixir any day over C# or other OOP/imperative lang. I don't ever want to touch any safety-critical systems though, but I do care about correctness of the business logic. Somehow I have zero interest in Microsoft langs/runtimes in general.

That said, Haskell just feels like a different beast. I also don't know how interop would actually work with these different solutions, would feel like unnecessary complexity if anything. Only to end up losing the benefits of Haskell's strong typing.

I've been struggling to justify spending more time & effort on concepts mostly exclusive to Haskell, only to be able to be productive on it. I keep thinking I should brush up my Elixir skills instead.

</comment></comment></comment><comment> pi-victor i've learned rust in a month of coding sparsely. in fact, i'm as comfortable today at writing rust as i am at writing go. i've been struggling to learn haskell for over half a year. i think it's an amazing language, don't get me wrong. but the fact that haskell is not harder to learn than any other programming languages is false. after taking a few online course, tutorials and so on, i still believe it's one of the most interesting (if not the most interesting) programming language in existence and also the hardest.

<comment><USER5> Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's _actual_ title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone actually believes.

(See also [https://news.ycombinator.com/item?id=21171360](https://news.ycombinator.com/item?id=21171360))

</comment></comment><comment><USER44> >What do you need to write real Haskell? The core of the language is extremely simple. If you understand how to write and use

>pure functions and values >pattern matching >sum and product types >how to glue together IO to make side effects

You can do pure functions, pattern matching, and sum and product languages in plenty of other languages that have much more user-friendly syntax, community, and documentation. Also doesn't hurt that they have impure IO so you don't have to jury-rig impure IO using a monad.

<comment><USER5> I don't think what you say contradicts anything in the article ...

<comment><USER44> It does. Haskell is harder to learn than other languages because it has a difficult syntax, navel-gazing community, and complex documentation.

<comment><USER5> You're right! Turns out it's me that hasn't read the article. Anyway, remove the sentence about it not being harder to learn than any other language (which I think is unfortunate) and _then_ I don't think what you say contradicts it. Haskell can be very hard to learn yet still within reach of most programmers.

</comment></comment></comment></comment><comment><USER45> I took a Haskell class couple of years back (Functional Programming) as reference I worked for 12 years before as Software Engineer using Pascal, C, C++, Java, Perl, Shell, Python, Visual Basic, and I felt like I was learning Chinese, I really put extra effort, but Monads, Applicatives, etc were complicated and way above my head. I really never found a reason to continue that punishment, I admire the teacher and the community who work on it, maybe not for me. But not easy

</comment><comment><USER46> Haskell basics are easy to learn. Nobody learns Haskell to linger on the basics. Haskell is a useful tool for express a deep ideas which aren't basic and require time, effort, focus and guidance to learn properly. You can still do quite a bit with the basics. I solved many Euler problems using Haskell and prefer it over Python.

</comment><comment><USER47> I mostly agree with the article, but not with the HN title (which doesn't match the article's title). The article itself has a nice statement:

> If you've already learned another language, you can learn Haskell. And even > if you haven't, learning Haskell is no harder than learning any other > programming language.

But most of the programmers are familiar with imperative languages, and can quite easily switch between them (possibly writing non-idiomatic and awkward code, but without having to really learn the language from scratch to do so). While a purely functional language with unfamiliar syntax doesn't let one to do it as easily. So indeed, if you haven't learned other languages, probably it's not harder, and if you have, you still can learn it, but likely it would be harder to learn than other imperative languages if you are already familiar with a few imperative languages.

<comment><USER5> > I mostly agree with the article, but not with the HN title (which doesn't > match the article's title).

I think the HN title used to be correct. Perhaps the mods changed it. I can't imagine why. It's a completely different claim from the article!

</comment></comment><comment><USER48> As a Haskell n00b, I'd like to mention something I can do in about 20 other languages but not in Haskell:

( UPDATE: I stand corrected, in a reply by tome. )

I'm writing and debugging some functional code - in Clojure. There's a function I've smoke-tested on its own but that's failing me with "real" data. Lacking a decent debugger for Clojure and being too lazy to isolate my problem into a test setup, my tool of choice is the lowly "debug print."

In Clojure, the body of a function is essentially imperative, and I can insert a `(println "label:" value)`. To do the same thing in Haskell, I'd have to restructure my whole damn program.

I understand the rationale for purity in Haskell, but sometimes I see it as badly standing in my way of accomplishing what I want to do.

<comment><USER5> Have you heard of Debug.Trace? It gives you exactly what you are looking for.

[https://hackage.haskell.org/package/base-18.104.22.168/docs/Debug...](https://hackage.haskell.org/package/base-18.104.22.168/docs/Debug- Trace.html)

<comment><USER48> Wow, cool! Thanks. I hope to do more with Haskell once I retire, and this may stand me in good stead.

I think my point is still supported to some extent by the fact that this is knowledge from outside of the language that I'd need to know to accomplish. It's something I need someone helpful like yourself to tell me about. Also something that only works because this library deliberately breaks Haskell's rules.

<comment><USER5> > Wow, cool! Thanks. I hope to do more with Haskell once I retire, and this > may stand me in good stead.

I'm glad it was helpful.

> It's something I need someone helpful like yourself to tell me about.

In general we're happy to help but it does annoy us when people make assumptions about what it's like to program in Haskell without actually trying it. If you'd like help I can suggest Haskell Reddit [https://www.reddit.com/r/haskell/](https://www.reddit.com/r/haskell/) or emailing me personally [http://web.jaguarpaw.co.uk/~tom/contact](http://web.jaguarpaw.co.uk/~tom/contact)

> something that only works because this library deliberately breaks Haskell's > rules.

Only if you have very punitive assumptions about what Haskell's rules are, like those who have never used the language often do. People who actually write Haskell programs have other ideas.

</comment></comment></comment></comment><comment><USER49> When I tried to learn Haskell, I tried doing the kind of stuff I usually do in Ruby: parsing log files, converting text formats, etc. It seemed hopeless. I'm curious to hear about the experience of someone who uses Haskell for everyday tasks. Does anyone do that?

</comment><comment><USER50> There are languages that attract people who want to get things done (mostly multi paradigm languages these days) and there are languages that attract people who want to feel special (languages oriented on one true way or obsessed with a particular purity).

</comment><comment><USER51> Yeah, ok, let's say it's true that it's no more difficult to learn Haskell as opposed to any other... with a mindshare of 0.29% ( according to something like this: [http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html) ) isn't that like saying that it's no more difficult to learn "Upper Egyptian Arabic" ( see: [http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html) ) rather than something a little more esoteric? ... i.e. WHY would you want to learn it unless you have a very specific use-case, i.e. moving to Egypt

(edited for a word)

<comment><USER5> Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's actual title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone actually believes.

(See also [https://news.ycombinator.com/item?id=21171487](https://news.ycombinator.com/item?id=21171487))

<comment><USER51>
      My point was/is that even if it IS easy to learn, relatively speaking, WHY would you want to learn it when it's obviously a niche language... I mean a REALLY small niche at that...

</comment></comment></comment><comment><USER52> Mirroring some of the comments here, just because you don't understand the internals does not mean you can't pick it up and be productive with it. This is what you do with any other language, but it just seems more natural to you (even though they are really just as complicated).

Hence I feel like one of the big issues is that people learn to program in a non declarative/imperative way. When you first pick up python / c / c++ etc, there are plenty of details you don't necessarily understand (who here has absorbed all of the c++ spec?).

At most Haskell is just different and I don't think it requires more mental effort than anything else.

</comment><comment><USER53> Everyone is smart enough to write Haskell. Almost no one is smart enough to read Haskell.

There is a reason loops are easier to read and maintain compared to a fold(map(filter(zip(...)))).

<comment><USER15> To give you a counter example: when i write code in an imperative language i always first write the logic out as fold/map/filter and then translate that into an imperative loop.

<comment><USER53> That's not a counter example. I stated map/fold/filter is difficult to read. You said they are easier to write.

These are not opposite, and I happen to agree with you.

<comment><USER15> Fair comment. I do find reading it much easier as well, which I guess boils down to familiarity, but when reading i don't need to translate it hence my comment re writing.

</comment></comment></comment></comment><comment><USER54> Learning Chinese is no harder than learning any other language. Unless there's a language you already know that is unlike Chinese and more like other languages.

<comment><USER33> Learning Chinese is objectively more difficult than learning alphabetic languages. Although learning Chinese really would be more like learning APL.

<comment><USER55> That's written Chinese. Learning _spoken_ Chinese is more difficult if you're not used to a tonal language, though.

</comment></comment></comment><comment><USER56> Can anyone recommend an intro to Haskell for me? ~4 years of Python experience and a math background. Ideally something online/interactive ...

<comment><USER5> The canonical source for Haskell introductions is the following, I believe

[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

</comment></comment><comment><USER57> Maybe things have changed since 2005 when I first used it but Haskell was certainly harder for me and the people I knew to learn than other languages. For languages of a _similar power_ I can see Haskell being similar difficulty to learn. But compared with something like Python the amount of effort needed to go from zero knowledge to being able to write some sort of program that produces some useful real world results is much higher in Haskell.

I say this as someone who quite likes Haskell, when you have a problem that fits well with Haskell it's really amazing.

<comment><USER3> Things have changed significantly in the last _four_ years, so they definitely will have changed a huge amount in the last 14 years.

</comment></comment><comment><USER58> I've struggled with Haskell for a long time. Surprisingly, learning Clojure made many Haskell concepts clear and more approachable for me.

</comment><comment><USER59> I would expect to get paid more though and that is not happening (except niche places). Same story with F# and Scala. Not worth it.

<comment><USER60> Scala software engineers are some of the best paid out there.

<comment><USER59> What are the examples? There is no requirement for specific domain experience?

<comment><USER61> Well, I was hired into dev at a quant finance shop (you may draw your own inferences about pay), using F#, with no experience of quant finance.

<comment><USER59> Niche. Wouldn't be surprised if it's G-Research or Jane Street or one of those very few places.

<comment><USER61> Could you give an example of something that's not niche? If quant finance is niche, it's quite a big niche.

</comment></comment></comment></comment></comment></comment><comment><USER62> It's not the language that's frustrating to learn, it's the tooling.

</comment><comment><USER63> Honestly I think Haskellers should spend less time writing blogs and more time writing code that does something interesting/useful. When the language you claim being so superior comes with such bad tooling and usability your claim instantly looses any substance.

<comment><USER3> Strange. I spend the vast majority of my time writing code that does something interesting/useful. In fact, it puts food on the table and a roof over the heads of several families.

The reason why I've given up my own time to write some blog posts (apart from it just being an occasional pastime), is that everyone complains that Haskell doesn't have enough documentation or tutorials.

Damned if we do; damned if we don't.

<comment><USER16> We absolutely need more hands-on Haskell tutorials and blogs. I've been massively more productive with Haskell with the help of just a few well written blogs that are full of tutorial posts.

We got a lot of books detailing various type theories, algorithmic nuances and so on in Haskell, but very little resources to actually help anyone get off the ground with practical web development.

<comment><USER5> > I've been massively more productive with Haskell with the help of just a few > well written blogs that are full of tutorial posts.

Could you share some examples? It's probably a good idea to promote useful content!

<comment><USER16> The best resource for me has been Matt Parsons' blog: [https://www.parsonsmatt.org/](https://www.parsonsmatt.org/)

</comment></comment></comment></comment></comment><comment><USER64> haskell is easy to learn if you want to ignore a bunch of floofy high level math concepts and just paste how to parse a json library.

lets be real, software engineering that brings results is i/o. i see the appeal in pure functions and guarding that out but the shit that matters is going to be the nasty mess of stuff that saves business logic that was hacked together over 10 years of rnd, interns and crunches

<comment> UK-Al05 Algebaric data types and monadic types are perfect for business logic.

Read the book domain modelling made functional.

<comment><USER65> This too, eh? "Domain Modeling Made Functional" \- Scott Wlaschin

[https://www.youtube.com/watch?v=Up7LcbGZFuo](https://www.youtube.com/watch?v=Up7LcbGZFuo)

</comment></comment></comment><comment><USER66> I'm not sure the idea of a "beginner" language should be a design goal, and I don't think Haskell being a hard langauge to learn means it's a bad langauge.

Easy as a design goal has led to many languages like AppleScript that try to ape natural language, or to visual languages, and those consistently seem to be bad choices.

Haskell is probably not as hard as many people who haven't made the jump think it is. But it is hard.

> What do you need to write real Haskell? The core of the language is > extremely simple. If you understand how to write and use [four items broken > out below] then you already have everything you need to write useful > programs that solve real-world problems.

The core is admirably simple, but simple doesn't mean easy. Easy to learn is when you have intuition and existing skill that readily map to the core constructs used in a language.

> pattern matching

There are cases where pattern matching is obvious, but this is not how most people have learned to structure a problem.

People aren't naturally good at breaking problems into parts, that's a skill you have to develop over two or three years, which is my guess from observing myself and peers.

> sum and product types

Explicit types are already hard; you're already excluding many people who have trouble making the leap from Javascript to Java.

But Haskell's type system is _heavily_ generic. And its support for container types is not so great. Making them easy was a major reason Perl, Python and Ruby grew quickly, and landed us a ton of horrible code.

To understand how Haskell makes these container types hard, compare the API for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather pathetic facilities for FP entirely because you don't need them.

The Haskell version has functions to do lookup, union, intersection and various predicates. In Java, they're trivial to implement with a loop.

> pure functions and values

The intuitive way to change a thing is... well, to change a thing. I can express it directly in plain language. To express the pure way, I have to describe it as "construct a new value such that all properties are the same except for the changed properties."

I've seen a meme that shows Common Core multiplication in a pedagogical context, and contrasts it with the traditional long-form multiplication. It completely misses what CC is trying to do, but it's useful in showing what people are comfortable with: they grok procedures much better than abstractions.

Functions are the part of math where most people who were okay with algebra nevertheless started tuning out. First-class functions are weirder still. Haskell also mandates currying, and being strongly typed every function gets a confusing type signature.

All that said, keeping track of state changed by mutation is deceptively hard. It's a case where your intuition routinely leads you to build things you can't maintain. But sticking strictly to the claim in the OP, it's easy to _learn_ to mutate state but hard to _do_.

> how to glue together IO to make side effects

This shows that monads are core to the language, and they have all the difficulties of generic types as well.

Everyone has jumped on how hard monads are already so I won't belabor the point, just to say that except for concurrency / parallelism, I don't think there are any core language features as hard to understand as monads.

(And I'm not sure exactly what the "core language" is, but I think anything in the Prelude is fair game.)

Haskell does make them dramatically easier with "do" notation, but I think you really do need to grok monads for your learning to progress beyond simple examples.

[1]: [https://hackage.haskell.org/package/containers-0.6.2.1/docs/...](https://hackage.haskell.org/package/containers-0.6.2.1/docs/Data- Map-Lazy.html) [2]: [https://docs.oracle.com/en/java/javase/12/docs/api/java.base...](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/Map.html)

<comment><USER5> > To understand how Haskell makes these container types hard, compare the API > for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather > pathetic facilities for FP entirely because you don't need them.

> The Haskell version has functions to do lookup, union, intersection and > various predicates. In Java, they're trivial to implement with a loop.

I don't get it. I don't see how you do lookup with a loop at all. As for union and intersection, are you sure you write them in Java with a loop? The way that's obvious to me would be quadratic. Is there a better way?

</comment></comment><comment><USER67> ...but have no reason to.

</comment><comment><USER68> Not la. Clojure.</comment>


The Great Ruby Shootout (July 2010) - <AUTHOR> http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/ <comment><USER2> I can comment on the JRuby results.

For the base perf numbers, I'm not surprised. We've known that we're roughly on par with 1.9.2 for some time, and many of the benchmarks in question have started to reach a point of irreducible complexity (e.g. you can only slice and dice strings so fast). It's good to see JRuby remains at or near the front of the pack as far as performance, especially considering we've made no major performance-related changes in almost two years.

The Linux versus Windows numbers are a bit surprising to me. If I were to make a guess, I'd guess that the JVMs used were not identical (perhaps like Isaac Gouy mentions, one platform was 64-bit and the other wasn't) or some other detail altered the performance characteristics of the test. But the performance drop does seem to be in line with other implementations, so perhaps Windows really does suck and there's not much we can do about it.

On the memory issue, I have a few recommendations.

JRuby by default allows the JVM to use up to a 512MB heap (the default is usually 32-64MB, which is rarely enough for most nontrivial apps). The JVM likes to use as much memory as you're willing to give it, to keep GC times low (nearly free) and to give it lots of room to breathe. Almost all these benchmarks could run in far less memory (maybe 1/5 as much or lower) if the JVM were choked down to that level. So it's not surprising to me that the memory sizes for these very object and CPU-intensive benchmarks start to approach that 512MB limit; the JVM is just stretching its legs.

Expect to see a lot more performance work coming in JRuby 1.6. I've blogged about it here: [http://blog.headius.com/2010/05/kicking-jruby-performance- up...](http://blog.headius.com/2010/05/kicking-jruby-performance-up- notch.html)

Also expect to see more work on picking a "winner" as far as lightweight servers go. Something that works as seamlessly as Passenger could be the "last mile" we need to get folks to make a move.

And watch our two Ruby Summer of Code projects: Ruboto, bringing JRuby to Android; and C extension support.

We're working very hard to bring JRuby to everyone and everyone to JRuby. The reasons not to use JRuby are rapidly disappearing.

<comment><AUTHOR> > The Linux versus Windows numbers are a bit surprising to me. If I were to > make a guess, I'd guess that the JVMs used were not identical (perhaps like > Isaac Gouy mentions, one platform was 64-bit and the other wasn't) or some > other detail altered the performance characteristics of the test.

The same identical version was used: Java HotSpot(TM) 64-Bit Server VM 1.6.0_20.

> But the performance drop does seem to be in line with other implementations, > so perhaps Windows really does suck and there's not much we can do about it.

The leading theory. ;-)

<comment><USER3> I don't know that this theory totally holds water (Windows OS developer here, announcing obvious bias) - looking at the results, the one place Windows really gets nailed is the I/O test; I suspect there's some significant optimizations that could be done there, as I/O on Windows OS in general certainly isn't 4x slower than Linux.

<comment><USER2> If there's something we or the JVM could do to improve these numbers, I would love to talk to you about it. At this point, if the JVM developers haven't found the magic sauce, we JRuby guys probably won't either...but I'd really love for JRuby performance on Windows to match JRuby performance on Linux.

<comment><USER3> I don't think that I can actively hack on the JVM, but I can tell you that XPerf is a great way to determine where you're spending your time. <http://www.microsoftpdc.com/2009/CL16> is a really good intro video on the topic, it's a very powerful tool (though doesn't provide as much analysis as Instruments for example)

</comment></comment></comment></comment></comment><comment><USER4> JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?

<comment><USER5> For scripting, that's definitely a problem. But it's not a big deal for long- running processes (e.g. a web application server). But Ruby definitely benefits from both: a fast Ruby with ~zero startup time, and a fast Ruby on the JVM.

3 years ago, Ruby implementation problems became the hot topic at Ruby conferences. Ruby was a beautiful language with an ugly implementation. It's great to see that the community has executed on this concern.

<comment><USER4> While I agree that it's not important for long-running applications, there is still a lot of scripting done in Ruby, and it's very frustrating to get a a 5-to-10 second wait just to tell someone their arguments were invalid. Waiting that long for tests is also such a drag on iteration.

I think once JRuby has stabilized the native gem support and has some sort of Passenger-like deployment option (Glassfish and Warbler isn't quite there yet), we'll see some big players built on MRI start to move their Web applications to the platform.

<comment><USER6> Use MRI for short-lived and JRuby for long-lived. Problem solved?

</comment></comment></comment></comment><comment><USER7> It will be interesting to see what sort of difference Java 7 makes for JRuby.

<comment><USER8> Java != JVM

<comment><USER9> But invokedynamic is part of Java 7.

<http://java.sun.com/developer/technicalArticles/DynTypeLang/>

<comment><USER2> InvokeDynamic and other Java 7 features (method handles, NIO2) are definitely going to improve JRuby's situation, but maybe not in the way you expect. Indy and method handles will largely allow us to delete (or not load) code we currently generate to get the same effect. Smaller runtime, possibly a smaller distribution. NIO2 will give us more direct access to streams, process handling, and so on, so we can delete hacks we've written to do all that ourselves.

But perhaps the most interesting aspect of any new major Java release is that they're usually 10-20% faster across the board, due to new and better optimizations. As the saying goes, if your Java app isn't fast enough, upgrade to a newer JVM.

I think invokedynamic combined with more runtime profile-driven optimizations in JRuby could easily double JRuby's Ruby-execution performance (or better), and in many cases reduce memory churn too. Lots of good things coming...it's nice to have an army of VM engineers on your side.

</comment></comment></comment></comment><comment><USER10> Why no IronRuby test on Windows? Understand, I'm no fan of M$, but it seems very odd to run the IronRuby test on Mono, then omit running IronRuby on the "native" .NET environment.

<comment><AUTHOR> IronRuby was tested on Windows a few weeks ago: [http://programmingzen.com/2010/06/28/the-great-ruby- shootout...](http://programmingzen.com/2010/06/28/the-great-ruby-shootout- windows-edition/)

</comment></comment><comment><USER11> Means and (especially) medians mean little to nothing when you're doing them over entirely different benchmarks. Why bother? A 3D plot would be a lot clearer.

<comment><AUTHOR> > Means and (especially) medians mean little to nothing

It's the other way around. Given the skewed nature of the data, the median is a better measure of the central tendency of the data set.

But note that I'm not plotting the median only. I use a box plot which gives you a much better statistical picture than using a simple median (or mean). Nevertheless, _summarizing_ different benchmarks has its limitations and box plots give you a rough, general idea of what's going on.

<comment><USER11> I disagree. If you write ten benchmarks, and they finish in the same order on all platforms, the median really doesn't give you any information apart from how the middle one did. At least the mean will be changed if the slowest benchmark for some reason is a lot slower on one platform. In this case, there was some variation, but for the most part it looks like the median is just one of 4 or 5 middling benchmarks in all cases, so you're really just removing data, if anything.

The box plot is a good choice here. What I would like to see is a graph plotting time against {VM} x {benchmark size} to see how each platform scales within a benchmark.

With the data you've got, apart from confusing me a little by including the mean and median, you did a good job presenting it. I'd love to see _why_ some platforms do so much well than others in some cases (except JRuby which everyone knows is a memory hog), but this seems way out of scope for this article. :)

</comment></comment></comment><comment><USER12> Too bad there's no MacRuby, which is probably the fastest ruby interpreter (though it only runs on OS X).

<comment><AUTHOR> It's right there in the first paragraph of the article: [http://programmingzen.com/2010/05/16/benchmarking- macruby-0-...](http://programmingzen.com/2010/05/16/benchmarking-macruby-0-6/)

<comment><USER13> And it looks like it's slower that either 1.8 or 1.9...

</comment></comment></comment><comment><USER14> The curve I dream of seeing: c++ slower than any good coverage flavor of Ruby.

<comment><USER2> I'd like to see that too. In JRuby, we may be able to get Ruby-to-Ruby calls to perform as well as Java calls, which would at least get that bottleneck out of the way. The remaining performance issues, however, are usually the rate at which objects can be allocated. In order to reduce that we may need a little JVM help (escape analysis that works well enough to actually eliminate allocations) and we may start to explore optional static typing, to allow _really_ reducing numeric operations to raw primitive math.

At this point, we realize that sometimes you really do need native performance, and we're not taking any options off the table to get there.

<comment><USER14> Charles, is there any chance virtual machines, JIT compilers can get "smart enough" to introduce native typing without requiring a hard decision by a developer. I'd prefer not to have to worry about types ever, and let the interpreter/compiler/optimizer slap them onto objects as needed to really crank numeric throughput.

Maybe I could tune software with profiling tools after the fact. But it feels like as soon as you start locking specific objects down it's a slippery slope.

I'm not very familiar with the depth you've gone to, but can a dynamic object have numeric features or be capable of substituting numeric handling for a limited time (virtual numerics) and then revert back to a sloppy untyped object?</comment></comment></comment>


Honda Launches Official Insight Hybrid Blog with New Photos and Videos - <AUTHOR> http://www.treehugger.com/files/2008/10/honda-insight-hybrid-blog-photos-videos.php

<comment><USER2> I can't get quite get my finger on what that car reminds me of. Oh right, it's basically a sleaker Prius with a Honda logo on it.</comment>


Doctors Say Shortage of Protective Gear Is Dire - <AUTHOR> https://www.nytimes.com/2020/03/19/health/coronavirus-masks-shortage.html <comment><USER4> I do China sourcing and have decent access to 3-ply surgical masks and limited access to N95 masks.

It's really hard to sell either of those to government bodies, even near cost. Already talked to the Red Cross, wholesale pharmacies and different ministries. They generally insist on payment on delivery, which we can't do for larger orders, as factories sell to whoever has the cash at the factory gate.

Some also want EU certifications (FFP2), while many factories in China only have the local Chinese standard (KN95). And some refuse to pay to a company outside Europa, while wanting to buy stuff from China.

So while I'd love to ship some of this stuff to Europe, currently people there are still blocking themselves. Hoping to work something out soon.

<comment><USER5> Can you email me (email in profile) and I can connect you to some people in the US trying to solve this.

<comment><USER6> Why don't they just charge a higher price to buyers who don't pay cash now? I understand there is a lot of demand, but this does not compute with me. My spidey senses would be going off.

<comment><USER4> This works for private buyers, but these gov agencies have a regulation that doesn't allow them to pay in advance ever. The price isn't the issue. So they can only buy from really big firms, who don't have stock right now and aren't flexible.

<comment><USER7> How do I learn more about this regulation?

<comment><USER4> No idea. They told me by email. And it makes sense for normal times.

It's probably in a procurement regulation or guideline.

<comment><USER6> Sure, but why do all of the smaller firms absolutely need cash right now? If they sell to a government or large entity, payment is all but assured. Even if they have a high discount rate, they can factor that into the price. There's no way they all need the money now to remain in operation.

<comment><USER4> We are way past discount rates here. Firms without enough cash won't survive. Even if you double or triple the price, it doesn't help if you're out of business when they pay weeks or months later. That's why some kind of financing is needed for larger orders that need like $ 1/4m to 1m in outlay first.

<comment><USER6> Can Chinese banks provide bridge financing? You'd think they would be happy to, since half of them are state-owned and China is in a position to help other countries afflicted by Coronavirus.

The bank can give the mask company money now. Once the American NGO receives the masks, it can directly pay the bank. That way the bank does not have to worry about the mask company stealing its collateral. The bank might even offer to pay for the provision of masks as a donation from China.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Let this be a lesson to learn for western democracies to not put all of their eggs in one basket. Diversification, localization and strategic globalization of the supply chain should be at the forefront of the issues to be discussed, ratified and acted upon after this pandemic is over. When one country manufactures 90% of world's goods (not accurate, to make a point), while the top 1% gets their bonuses for increasing profit margins, this is what we have. We've lost skills, we've lost our stance to manufacture things in our own homeland. It is depressing, deeply worrying and feels like the entire world has been gutted out by one country. Just to make it clear - think about this scenario - what would happen if one country made the food for the rest of the world? (Thankfully, we don't, but it can happen). What about pharmaceuticals? (Unfortunately, 90% of the world's generic drugs are made in Asia, primarily in India who in turn depends on China) [1].

[1] China is the world's largest raw materials exporter for Drugs: [https://www.wsj.com/articles/china-opens-door-to-foreign- dru...](https://www.wsj.com/articles/china-opens-door-to-foreign-drugs-for-a- discount-1543320003?mod=article_inline)

Edit: I just realized that some of the startup and entrepreneurs around the world are on this forum, if you'd like to get into manufacturing, want to learn about more abstract concepts of manufacturing, I implore you to checkout: Manufacturing Planning and Control for Supply Chain Management reference book - [https://books.google.com/books/about/Manufacturing_Planning_...](https://books.google.com/books/about/Manufacturing_Planning_and_Control_for_S.html?id=TkGRswEACAAJ) This book is absolute _gold_. Manufacturing is like playing this game Factorio (google it) but in real life. It is an exciting field ripe for innovation, many _very_ hard problems and unlimited potential (and a lot of risk as well).

<comment><USER9> Strategic stockpiles seem much more cost effective than autarky.

<comment><USER8> It is not about autarky, but diversification and resiliency of the supply chain. Automakers are experts at this - BMW cars made in USA (South Carolina) have US made parts and ones made in Germany have locally sourced parts from Germany, yet the ones made in South Africa have diversified sources - <USER2> local and international. If you're in the US, you can see this % of locally made parts right on the window price sticker. It's not just for show - <USER3> there is a shortage of headliners in US, it can import it for a short term needs from Europe and vice-versa.

No one is suggesting complete in-house isolation aka Autarky, but to avoid SPOF (single point of failure) supply chains - probability of each link breaking adds up when your supply chain is 18 levels deep from an iPhone to the copper mine.

<comment><USER10> I imagine that unless it's 100%, the "% of locally made parts" is very poorly correlated with supply chain robustness.

If a BMW contains 99% local American parts, it's quite likely that much of the 1% are the hardest things to produce locally.

</comment></comment></comment></comment><comment><USER11> There is reason to believe that the hospital mask shortage is due in no small part to employee (and patient/family) theft of masks and not necessarily due to dramatically increased need at hospitals (at least not yet).

I say this as a resident physician at an urban hospital in the US. We're now severely low on N95 masks and moderately low on surgical masks but we have only had less than a dozen confirmed covid-19 cases (granted about 100 tested negative cases) so there's no way even 100 additional patients requiring masks suddenly plummeted our stockpiles of masks. Indeed, hospital administration noticed and sent out a mass email imploring employees to return unused masks in personal possession.

<comment><USER12> This. There are barely any covid 19 patients yet hospitals are low on masks due to panic. Beds are still open and ventilators contrary to media claims are not currently on a shortage.

<comment><USER13> There are also not nearly as many tests being run as there are patients with suspect symptoms. Yes, the number of confirmed COVID-19 patients may be low, but that doesn't mean that the number of people with the disease is low.

According to the CDC[1], you can contact your healthcare provider for the possibility of a test if (and only if) you are in close contact with someone with the disease or if you're in a community where there's ongoing spread. That's still a very limited subset of people who might have the disease.

There's very limited insight into who does or does not have the disease in the US.

[1][https://www.cdc.gov/coronavirus/2019-ncov/symptoms- testing/t...](https://www.cdc.gov/coronavirus/2019-ncov/symptoms- testing/testing.html)

<comment><USER14> And these criteria become a catch-22. How does a community become identified as having community spread if you won't test anyone in a community that isn't so identified? My understanding is someone has to be admitted to the hospital and then tested to get the ball rolling.

</comment></comment></comment></comment><comment><USER15> Again severe failure on the govt's part. Their inaction in when it was needed the most led to all these circumstances that makes it ripe for situations like these. As the number of infections spread and economic situation get worse these kind of things will get really really bad. Once the second and third order effects kick in it's going to be a catastrophe. And our leaders answer to all of this is to give $1200 checks to people. All they care is about the economy as it gives them higher odds for their reelection. I don't understand how such incompetence can be tolerated and why they are not fired and instead have to wait till next election.

<comment><USER16> > Again severe failure on the govt's part.

If you live in a democracy, then you _are_ part of the government. You can't just blame other people for this.

<comment><USER17> That's ridiculous. An average citizen cannot vote more medical supplies into existence no matter how hard they vote.

</comment></comment></comment><comment><USER18> I keep seeing articles like this pop up. During one of the first coronavirus press conferences, the White House invited CEOs from Walmart, Target, CVS, etc. – presumably to show strength of the private sector.

On the flip side, why can't we enlist money and resources from the private sector to quickly fix some of these supply issues? For example:

\- Convert car factories to produce masks and ventilators.

\- Convert construction companies to build makeshift hospitals. (Or use hotels.)

\- Use tech companies to improve national information access with regards to CV19 testing and track and help patients using their software on their phones to help with contact tracing.

I realize that it's not as simple as pressing a button and instantly converting a factory that makes Teslas into one that makes masks. I also realize there are potential privacy concerns with nationalized information tracking.

But, we're about to enter an unprecedented public health crisis. We have resources that can lessen the impact if we just align and get behind this direction.

I can't help but think we could do more and not just wait for the shortage to happen, and for the curve to spike.

We stockpile enough nukes to basically destroy the whole Earth (exaggeration but you get the idea), but we can't stockpile some ventilators and face masks in case of a pandemic? You can't fight a pandemic with diplomacy. At least you can fight a foreign enemy with that.

<comment><USER19> Turns out N95 masks are quite high-tech, and even China is having trouble scaling up its production. They're made of a material, meltblown fabric, which only a limited number of factories are capable of producing.

[https://www.npr.org/sections/goatsandsoda/2020/03/16/8149292...](https://www.npr.org/sections/goatsandsoda/2020/03/16/814929294/covid-19-has- caused-a-shortage-of-face-masks-but-theyre-surprisingly-hard-to-mak)

<comment><USER20> They aren't having trouble scaling up... They already have. 200 million masks a day, 20x in February.

If we (America) can't scale up we are in deep doodoo. Trump has been pissing off China by calling the Corona virus the "China Virus".

<comment><USER21> 200 million surgical masks but only 600k n95 masks, per the npr article gp linked to.

The machines to make the n95 masks take both the Germans and Chinese about 6 months to make.

</comment></comment></comment></comment><comment><USER22> The ER docs at my wife's hospital this morning were wearing pediatric masks with Disney characters emblazoned on them. And this is in a major suburban hospital.

</comment><comment><USER23> The inability to just requisition, demand resource, mobilize people and so- forth, is breathtaking here. The start of WWII saw the quick re-purposing of industries for the war effort.

Today, it seems an inability to see what's necessary and get it to people is disturbing. The situation is effectively a war and one that's being fought very quickly.

I could brainstorm and mention the "fast fashion" is renown for creating conventional clothing to a variety of specifications, _quickly_. It seems like that talent could be harnessed for various kinds of safety equipment. Just an example, I'm sure there are a hundred similar things conceivable but despite the looming collapse of conventional procedures, somehow all bureaucratic hurdles remain in place.

<comment><USER24> I still can't believe that no western country is even capable of creating freaking face masks at scale (and no, doesn't need to be N95).

</comment></comment><comment><USER25> [https://archive.md/8EcPa](https://archive.md/8EcPa)

<comment><USER26> Thank you

</comment></comment><comment><USER13> My sister's an ER doc in Baltimore and they're getting one mask per 12-hour shift. That quantity doesn't protect them from anything or their patients

<comment><USER20> My understanding is they are good for 4 hours. When the masks are saturated they are not effective. Maybe it's better to have 2 and rotate them out.

I saw someone else post this on HN... Worth a look. [http://www.imcclinics.com/english/index.php/news/view?id=83](http://www.imcclinics.com/english/index.php/news/view?id=83)

<comment><USER13> That's a valid idea, but it's unfortunately not something she's in control of. All the PPE protocols are coming from people higher than her.

They're also not getting eye protection at all so she's taken to wearing her glasses instead of contacts. Not as good as actual eye protection, but it's better than absolutely nothing.

In short, they don't have what they need.

</comment></comment></comment><comment><USER27> The crazy thing to me is the government or hospitals haven't issued a massive n95 drive to obtain more.

I have a few left over from a house project I did a while back. Kept one for myself, but happy to donate the other 4 I have. I'm sure if the request was actually made people would donate. Is it enough? No idea, but construction workers, painters, etc don't need them right now.

People want to do something, let them.

<comment><USER28> Just curious why are you waiting for a request? Why not call the nearest hospital and say "I've got 4 n95 masks, do you want them?"

There is a problem with issuing a request - not everyone will know about it. As you mentioned, you think there was no request. But there were multiple: here's one example [https://www.poynter.org/reporting-editing/2020/hospitals- are...](https://www.poynter.org/reporting-editing/2020/hospitals-are-running- out-of-masks-industrial-masks-have-been-okd-for-use-are-local-construction- sites-donating-them/)

</comment></comment><comment><USER29> I wonder what if there's a straightforward way to make facemasks by hand, or with tools that are generally available?

I'm imagining cutting apart a furnace filter and wrapping the fabric around a wire frame, or something like that. If someone were to develop a process that was simple and reliably repeatable and produced good quality effective masks, that could be a way for otherwise un-busy people to keep hospital staff supplied.

One issue I suppose is whether there are upstream bottlenecks, like not being able to get a reliable supply of the right kinds of filter material.

<comment> j-c-hewitt There are a lot of hospitals directing employees to sew them by hand.

There is a simple and reliably repeatable method: having a factory. Not sure what is needed but there are lots of suppliers on Alibaba for this type of item. There are lots of rumors about export controls in China, denials of the same from Chinese officials, and rumors of seizure by US customs.

Never imported medical stuff but anecdotally many US sellers are being solicited by Chinese factories looking to sell masks and other PPE into the US.

</comment></comment><comment><USER30> Chinese n95 masks are available very cheaply on Ali-Express from a variety of sellers who can ship by airmail. I don't see why doctors/nurses shouldn't order them personally if they can't get them from work. For example: US $10.09 20% Off | 10PCS Disposable KN95 Mask FFP2 Protective Mask Safety Masks 99% Filtration for Dust Particulate Pollution N95 Protection

[https://a.aliexpress.com/_dSIOgZ3](https://a.aliexpress.com/_dSIOgZ3)

</comment><comment><USER31> Car factories can be converted to produce masks. An electric car manufacturer in China, BYD, became the biggest mask maker in 3 weeks.

[https://www.bloomberg.com/news/articles/2020-03-13/buffett-b...](https://www.bloomberg.com/news/articles/2020-03-13/buffett- backed-byd-says-it-s-now-the-biggest-maker-of-face-masks?srnd=technology-vp)

</comment><comment><USER32> What does it take to build those masks from scratch?

We are at roughly 1 out of 100.000 being infected. Until 60% have developed immunity, there is still a long way to go where almost everybody on earth will want to own masks. The need of the hospitals is just the tip of the iceberg.

Is it possible to source the machines and materials now to be ready for production when the wave hits really hard?

</comment><comment><USER33> Are there any reusable masks that are effective? It seems like throwing away these masks after a few hours of usage is partly to blame for the shortage. Generally damp materials are good at blocking particles better than dry ones. So is there any possibility of reusing the mask after washing in soap water?

</comment><comment><USER34> Maybe this DIY approach to masks can help in the interim - better than no mask at all?

[http://www.cidrap.umn.edu/practice/homemade-personal- protect...](http://www.cidrap.umn.edu/practice/homemade-personal-protective- equipment)

</comment><comment><USER35> >"The federal government's not supposed to be out there buying vast amounts of items and then shipping," Mr. Trump said. "You know, we're not a shipping clerk."

Hey, the guys not wrong, he's not a shipping clerk

<comment><USER36> They do that for weapons, ammunition, food, clothing, etc, etc, etc.

<comment><USER37> The interstates, rail networks, oh and THE USPS, which makes the federal government, literally a shipping clerk.

</comment></comment></comment><comment><USER38> If this article was dated January I might care.

Everyone in the hospitals from nurses to management knew exactly what is coming but did nothing.

And nothing has even happened yet, wait till the virus actually arrives in a few weeks.

Did any hospital plan or ask for help properly? Did any nurses union raise the issue?

Anyway they have numerous studies from Africa where they can't afford equipment, rather than the lack of planning by people on half a million a year, to look at.

<comment><USER28> Nurses and other staff are not there to make decisions based on firsthand geopolitical and epidemiology research. They have enough day-to-day work to do. This information should be provided to hospitals and other healthcare workers from higher up. This level of resource use / need may be even above what the local management should analyse, because ideally there would be regional stock available to shift to the clinics/hospitals affected by most cases.

<comment><USER39> I agree with you regarding client-facing staff, and think the parent post has misplaced lack of concern. However, I also think the post makes an important underlying point about hospital administration generally and "where their heads were at."

Increasingly a lot of hospital administration is very profit-focused. Not all but maybe most; where it's not, it's increasing, and where it's not supposed to be it often is, but hidden.

What this means is that the focus of hospital administration is often not on epidemiology and public health, even though it should be. It _should_ include that more. It's focused more on squeezing out the maximum from each provider in terms of billable hours and patient contacts. When you're focused on stuff like that, you're not thinking about public health.

And so we have the consequence of that now. I don't think this is the only problem -- there's also government overregulation, rent-seeking provider monopolies that artificially restrict supply of services, and lack of coverage for patients -- but it's part of it. In general, at an abstract level, healthcare in the US has become very focused on protecting the interests of the established system, and less so on the interests of citizens and patients. It's a house of cards with several problems at once, getting hit by the perfect storm.</comment></comment></comment>


New Amazon patent: sending video of orders being boxed - <AUTHOR> http://www.techflash.com/seattle/2010/03/amazon_patents_new_customer_service_video_of_orders_being_boxed.html

<comment><USER2> I bought a nice hat from <http://www.kleinbottle.com/> and he sent me pictures of it being packaged up, so this sort of thing has been done before. I've no idea about patentability though.

<comment><USER3> The Patent and Trademark Office prohibits holders of business degrees and software engineering degrees from joining the patent bar or being patent examiners. Those practitioners are required to have other kinds of engineering degrees only (plus a law degree).

Partly as a result, patent examiners do not consider commercial software and business practices to be 'prior art' and patent examiners do not search, even on a superficial level, business magazines, case studies, ACM journals, commercial computer magazines or such materials in 'prior art' searches. The PTO considers that anything in those fields can be patented including common established techniques and obvious combinations.

There has been some talk lately about submarine patents that apply to Theora or H264. One other kind of patent that is likely to apply to both is patents that have not been applied for yet. The PTO seems to have no trouble at all granting a monopoly on existing practices. Microsoft lost hundreds of millions of dollars over in-place editing of linked objects, a technology that had been running on windows for years before another company applied for a patent on it.

<comment><USER4> This, if true, completely flies in the face of the expectation that patents are not obvious to, and can be read and understood by, a person skilled in the art. No average software engineer could implement a system based on reading its patent, and no average software engineer would think these sorts of patents are inventive.

[http://en.wikipedia.org/wiki/Person_having_ordinary_skill_in...](http://en.wikipedia.org/wiki/Person_having_ordinary_skill_in_the_art)

He who has the gold makes the rules. Corollary: he who makes the rules gets the gold.

</comment></comment></comment><comment><USER4> That's pretty obvious, because I came up with a detailed system for doing the same thing and I don't run a shipping business. This is an idea whose time has come (i.e. an inevitable product of today's world, manifest as a new idea popping into the minds of dozens or hundreds of people everywhere), because it seems a lot of people have been doing the same thing.

</comment><comment><USER5> There is a digital camera shop that does this as well. I think they have been doing it for a long time.

</comment><comment><USER6> This is an April Fools - right?

<comment><USER7> I really truly hope so!

</comment></comment><comment><USER8> Next thing you know, each of those blabbering simpletons in the Windows 7 commercials -- "making things faster was _my_ idea!" -- will be awarded their very own patent.

</comment><comment><USER9> When will the madness stop?

</comment><comment><USER10> ok all this drama just given me as idea ..... i am to patent "WALKING INTO A SHOP THROUGH THE FRONT DOOR" and sue any shop owner that violate.

</comment><comment><USER11> Certainly a cool idea and a nice feature, but how on Earth is this patentable?

<comment><USER12> It is a business method patent. From Wikipedia: A business method may be defined as "a method of operating any aspect of an economic enterprise". It is mainly in the US, Australia, Japan and Singapore that business methods are usual. In Europe this is not regarded as being inventions, and are therefore not patentable.

More info on <http://en.wikipedia.org/wiki/Business_method_patent>

Oh, and _of course_, there is a lot of discussion going on about these kind of patents.

<comment><USER13> The supreme court is currently reviewing the legality of business method patents in the Bilski case. I have a Google news alert for it, because if they rule broadly enough, many software patents could be overturned.

<http://en.wikipedia.org/wiki/In_re_Bilski>

</comment></comment></comment><comment><USER14> What a fucking ridiculous patent. While the effort behind pulling the actual process off may be quite difficult, the obviousness of being able to do this should not be patentable.</comment>