Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Flub Paradox

steved-imaginaryreal.blogspot.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: The Flub Paradox

#61

Post by codygman »

_dps wrote: post #60
michaelochurch wrote: post #32

Earlier quoted context omitted.

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it. Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lo…

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

I've never taken a calculus class and I'm very productive in Haskell. Maybe knowing all of the applied Math and that there is a better solution available in Haskell keeps you from being productive?

I take the route of solving problems the first (or second) way I come up with, then take advantage of how easy it is to refactor Haskell code when I have a better solution later.

For instance I didn't understand Monads too well while writing my first Haskell program and just did everything in continuation passing style.

Re: The Flub Paradox

#62

Post by michaelochurch »

_dps wrote: post #60
michaelochurch wrote: post #32

Earlier quoted context omitted.

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it. Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lo…

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

Haskell took me a while, because there weren't many great resources on how to write many kinds of "real" code in Haskell. The quality of material is getting steadily better.

I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack. If you're coming from Java, you're more productive than you were at 1 month in Haskell (you still know very little Haskell, but you're pwning your former Java-toting self)... but in your case, you already know quite a few high-level languages. So it's not surprising that you get less done in a language that forces you to contend with monads (which aren't as hard as they're made out to be, but they're one more new concept) just to have state. If you're coming from Java, you're more productive in Haskell almost instantaneously, before you really even know it. If you're coming from Python, you're less productive day-by-day because the compiler keeps burning you, but you find long-term development going faster due to fewer code breakages. If you're coming from Ocaml... the short answer is that they're both great languages with more in common than not (although I prefer Haskell) so it's not surprising that it takes a while to get up to your prior speed (because your prior speed is so much higher than that of someone from Java).

Real World Haskell is a good book, though a bit slow and dated. Learn You a Haskell is a decent intro book but it has some gaps. I'm working on a Summer Haskell Course at my company and will be publishing the slides. And Chris Allen recommends the CS 194 course that Penn offers (you can find it online). Resources are out there.

Re: The Flub Paradox

#63

Post by marcosdumay »

_dps wrote: post #60
michaelochurch wrote: post #32

Earlier quoted context omitted.

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it. Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lo…

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications.

Haskell is powerful, but won't solve all the problems on the world.

Re: The Flub Paradox

#64

Post by marcosdumay »

raverbashing wrote: post #14
smitherfield wrote: post #9

Earlier quoted context omitted.

I knew C; C was a friend of mine. Javascript, you're no C! When it appeared, C was a revolution in programming languages. It offered a combination of performance and expressiveness that simply outclassed anything else available (still true today, 43 years later, if more narrowly). It instantly became the most popular and held that position to this day, becoming a major influence on virtually every other popular progr…

> much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over Python existed in 1995, but I doubt it was very known at the time. Ruby was created in 1995 Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements? "But, all things considered, it was as close to perfection" Pascal didn't have a braindead way of dealing with strings.…

C string functions lets me copy an image from a memory position to the video controller for displaying, or to the disk for storage. Pascal's ones don't.

Calling it "better" is completely missing the point. Nobody would have written UNIX in Pascal, for obvious reasons.

Re: The Flub Paradox

#65

Post by marcosdumay »

veddox wrote: post #40
stevedonovan wrote: post #10

Earlier quoted context omitted.

Ever so slightly ;) I think it admirable that people invest a lot of time in the environments they spend so much time in, but a professional has to be flexible. (It is entirely possible that my sarcasm got out of control here.)

Just out of curiosity, what makes you say IDEs are bad?

IDEs aren't bad, but...

Automatic code generation is bad (unless its completely automatic in "you don't ever see it"), because code always have to change, and changes aren't automatic.

Heavyweight building setup is bad, because you can not replicate or automate it.

Long names everywhere hinder legibility. (Although long names on confusing or ambiguous places are a good thing.)

And, finally, people learning to program should learn how to program without one at some point, so they know what they are doing.

None of that makes IDEs bad. It just neuter their biggest selling points, but there are lots of small gains you can get from one.

Re: The Flub Paradox

#66

Post by _dps »

marcosdumay wrote: post #63
_dps wrote: post #60

Earlier quoted context omitted.

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications. Haskell is powerful, but won't solve all the problems on the world.

This is an excellent point and maybe you gave me a good compact summary of the situation. Perhaps you can tell me if you agree.

The kind of work I do tends to involve a small number of low-variability data types, and the ROI on complex logic (w.r.t. computational performance) has to be very high for it to be accepted into a project. We don't shy away from complex logic, but we do have a high hurdle for it to cross before it becomes a net win.

In contrast, Haskell is perhaps best for large numbers of high-variability datatypes where complex logic is inevitable, regardless of performance costs. And it helps precisely by encoding as much of the complex logic (e.g. safety rules) into the variability and expressiveness of the type system.

I guess all that may be obvious, in hindsight. But I think your comment helped me crystallize the distinction. So, thanks :)

Re: The Flub Paradox

#67

Post by bkeroack »

AnimalMuppet wrote: post #59
michaelochurch wrote: post #38

This is intelligently argued and articulate but the content is a bit lacking. First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statica…

But a good IDE won't make you take your hands off the keyboard. See, for example, IntelliJ. There are keyboard shortcuts for everything .

IDEs become indispensable primarily in giant, overly-OO tarballs where (in the words of Adele Goldberg) "everything happens somewhere else". In more sane languages/codebases you don't need to "jump to symbol definition" constantly because the code is pretty easy to navigate.

Re: The Flub Paradox

#68

Post by AnimalMuppet »

bkeroack wrote: post #67
AnimalMuppet wrote: post #59

Earlier quoted context omitted.

But a good IDE won't make you take your hands off the keyboard. See, for example, IntelliJ. There are keyboard shortcuts for everything .

IDEs become indispensable primarily in giant, overly-OO tarballs where (in the words of Adele Goldberg) "everything happens somewhere else". In more sane languages/codebases you don't need to "jump to symbol definition" constantly because the code is pretty easy to navigate.

First, the complaint I was replying to was about having to take your hands off of the keyboard. Your reply to me therefore looks like a rant that was looking for a place to happen, rather than something that actually belongs in this thread.

Second: Fine, you don't like OO (at least the way it's often done). You don't want to have to jump to symbol definition. Great. But there are quite a few other useful things that an IDE can do to help you besides jumping to symbol definitions. Maybe you should learn some of them - you might find them useful.

Re: The Flub Paradox

#69

Post by markc »

>Clojure is an attempt at re-Flubbing Lisp.

And it's a successful attempt - unless you require top tier adoption to qualify.

>Where is Flub being used as a secret weapon, in the way described by Paul Graham? Why aren't its practitioners exploiting their natural advantage?

Clojure is a good candidates for Flub not only because of its power and expressivity (and as a Lisp, its natural fit as a PG-style Flub), but because it is being exploited to advantage by those who've discovered it.

A small sampling includes: Adzerk, Beanstalk, CircleCI, Cognitect, Consumer Reports, Daily Mail, Database Labs, Democracy Works, Deutsche Bank, eBay, Factual, FarmLogs, Groupon, Heroku, Intuit, LivingSocial, ViaSat, MixRadio, Netflix, Nubank, OpenTable, Pivotal, Precursor, Prismatic, Puppet Labs, RoomKey, Sonian, Soundcloud, Spotify, Staples, Teradata, ThoughtWorks, Cisco, Two Sigma, Upworthy, uSwitch, World Singles, Innovation Labs, Zendesk, ... (sorry If I left out your awesome Clojure-fueled project/company but the list is too long)

The Clojure experience at these companies seems to mostly fall somewhere between gushingly effusive and merely enthusiastic. Sure, there's some self-selection, and it's hard to separate developer talent from language choice in those successes, but read a few case studies and you start to get the impression that Clojure itself is not only an advantage, but a significant one. That's not to say that Clojure is the only good candidate for flub; there are other powerful, productive, and pragmatic languages that can deliver high productivity in the right context. But if I had to pick one language to be dubbed Flub, it would be Clojure.

Re: The Flub Paradox

#70

Post by Dewie3 »

camperman wrote: post #35

I just got back from a very positive strategy meeting with my partner (I do the code and he does the ops and the sales) and this essay struck a chord with me. Why are we making so much progress when I'm a decidedly average programmer? I think it's because I'm a decidedly average programmer in enough languages to know what their strengths and weaknesses are and thus to be able to pick the right tool for the job: - har…

That's a nice kitchen sink full of languages.
Post reply on HN