Haskell in Production - <AUTHOR> http://felixmulder.com/writing/2019/10/05/Haskell-in-Production.html <comment><USER4> All the interesting code is in the next post, [http://felixmulder.com/writing/2019/10/05/Designing- testable...](http://felixmulder.com/writing/2019/10/05/Designing-testable- components.html).

I'm not sure why they use a generic monad rather than ST, they don't need continuations for this.

The Reader monad with a big record is standard Haskell, it's basically what GHC uses: [https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea7682232...](https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea76822322b746a632778/compiler/utils/IOEnv.hs#L55)

data-has is less standard, it only seems to have been used seriously by one project, which has a bug on file to stop using it: [https://github.com/myfreeweb/magicbane/issues/20](https://github.com/myfreeweb/magicbane/issues/20)

But overall it's interesting, we'll see where the series goes.

<comment><USER5> It's always good to see examples of how a language is actually used, rather than just assertions of its superiority.

That said, if Haskell programmers truly consider this a superior and readable way to write code would tend to reinforce my preconception of them as an insular community elevating arcane jargon to a virtue (not unlike the APL programmers of yore).

<comment><USER6> Its strange how code written in unfamiliar languages is ... unfamiliar? The Haskell in that post is bog-standard. The definition of "arcane" is not "I don't know it".

<comment><USER5> I've worked in a pretty wide range of languages. I think I know "unfamiliar" and I can tell it apart from "arcane".

OP claims that "this article will emphasize writing easy to grok, maintainable code". The definition of "easy to grok" is not "once you've bought into the entire mindset, this will be obvious to you".

<comment><USER7> > I've worked in a pretty wide range of languages

Which languages are those? If the answer is "N flavours of imperative/OO languages" (like C/C++/Java/C#/Ruby/Javascript) then you really haven't worked in languages _different_ enough for you to truly learn anything new. The rule is simple: if learning a new language is easy, then there isn't much new in the language for you to learn (except a different flavour of syntax or whatever).

<comment><USER5> True, most of my work was in imperative/OO languages, though the imperativeness ranged from "global variables for everything" to "No global state, predominantly immutable objects, predominantly single assignment".

But I've also worked in Prolog and SQL, and dabbled in languages like UNITY: [https://en.wikipedia.org/wiki/UNITY_(programming_language)](https://en.wikipedia.org/wiki/UNITY_\(programming_language\)), so I have some degree of openness to different paradigms.

<comment><USER7> > so I have some degree of openness to different paradigms.

That's great! I truly believe that learning new hard stuff is how a software developer goes from average to great. If you learn a little bit every day then after 5 years you will be SO much better than the average guy/gal sitting next to you.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > Haskell is great for business and great in production

I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit.

I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the other is rewriting the codebase in Rust.

<comment><USER9> in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought- per-line-of-code in Haskell/FP projects.

many engineers (and businesses!), culturally, come from the opposite angle (legions of generally pluggable engineers on java/python/golang plowing through tickets/features). that's fine, but it isn't super amenable to the Haskell world, because IME non-imperative setups require different mode of thinking about design, so harder to drop in and crush a ticket. i wish i could explain this more, but i'm struggling to articulate with examples.

i think the thorough types really help you get up to speed on data structures, but unless you are in a functional mindset pretty much exclusively, your (my?) brain spends a lot of time un-imperative-ing itself. also, laziness can be a factor, so need some expertise there.

it also helps to have conventions e.g. old school java (are we point free, or not? etc. etc.)

all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that.

<comment><USER10> > all in all i think it requires a lot of discipline that can easily break > down, whereas some of the popular imperative languages you can still sort of > plug along (=> punt the technical debt) despite that.

Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc. All these disciplines seem to boil down to the same systemic result, push effects to the edges of you program so you can more easily test, evolve and maintain. Functional programming (of the typed variety) tends to allow me to write garbage code, that is testable and can be easily evolved and maintained because the paradigm encourages me to be a good actor.

I've refactored production code in imperative languages and typed functional languages and only one of them allowed me to make HUGE sweeping changes with ease and high confidence.

<comment><USER11> > There is a whole cottage industry of methods for your discipline of choice: > Clean, SOLID, TDD, etc.

I'm not a big OOP fan, but I'm pretty sure Clean and SOLID are principles (or sets of principles), while TDD alone is a practice. I'm also not very familiar with Clean or SOLID, but I'm pretty sure they apply to Haskell as well, and I would expect that Haskell enthusiasts would ordinarily boast that Haskell allows (or encourages) them to write code that is more SOLID with less effort than other languages.

My criticism of Haskell is that there tends to be an obsession with writing the most SOLID/DRY/etc code possible at the expense of productivity. It's a code golf / ego culture.

Yes, this is cultural and not "built into the language" (quotes because I doubt there's a clear distinction between a programming language's culture and the language itself, but that's a debate for another time), but you can't unplug from the culture, because you need the ecosystem to solve any nontrivial problem (so you still have to interface with overly clever code).

Further, even if you could unplug from the culture (perhaps by writing everything in-house under your own improved culture), there are still no 'rails' that encourage naive, flat-footed, dumb code, and that's the kind of code you want 99% of the time. As far as I'm aware, there isn't even a clear standard for writing clear, naive code in Haskell.

<comment><USER12> SOLID applies only to OOP. Not using classes trivially satisfies the requirements of every letter. Hell, most design patters are trivial if you use functional programming.

</comment></comment></comment></comment></comment><comment><USER13> We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.

<comment><USER14> For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.

<comment><USER15> They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.

<comment><USER14> I think so.

[https://insights.stackoverflow.com/survey/2019#technology](https://insights.stackoverflow.com/survey/2019#technology)

<comment><USER15> That doesn't speak to Haskell. You can say that's because there's not a lot of Haskell and that's likely _at least_ partly true. But the difficulty hiring for a position depends on the number of people qualified _and_ the number of other roles competing for those people. The fact that _both_ of those numbers are smaller for Haskell than (say) Java doesn't tell us whether it'll be easier to hire for Haskell or Java.

<comment><USER14> True. Lets check the numbers. 90,000 developers took the survey.

Java: 41.1% 36990 developers

JavaScript: 67.8% 61020 developers

Haskell: 0% 0 developers

Jobs:

Java: 73,447 jobs

JavaScript: 59,647 jobs

Haskell: 492 jobs

[https://www.indeed.com](https://www.indeed.com)

Given the numbers, as a hiring manager, I will never ever suggest to any company to try to use Haskell or hire Haskell devs. I know many developers who use it though. They sucessful with what they are doing, turning business problems into Haskell problems and solving those. Sometimes patch the compiler, sometimes write a completely new one. As a tech leader I do not want to have these problems, even if I could hire enough people for projects (which I can't). I always like to read blogs about what is going on though. It satisfies my scientific curiosity but that is it.

<comment><USER15> Those are numbers. I'm not sure what they say, ultimately. If we believe them, then we can conclude: there are substantially more Java programmers, but substantially more unfilled Java positions, but a much bigger (... infinite) ratio of Haskell job to Haskell programmer, etc, etc. I'm not sure which of those wind up being most important.

I _can_ say what I've said - that my experience of trying to hire the next couple Haskell programmers has not been harder than my experience of trying to hire the next couple JavaScript programmers.

There's also a big question of the quality of the survey, and how representative it's likely to be of your company's overall hiring pool - <USER2> say you have many Haskell programmers in your network, and your network is probably substantially fewer than 90k individuals, so something seems amiss.

I'm not interested in getting drawn into the rest of your ranting.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> This is a great guide and sound advice. And hopefully in a year we'll see the community converge on Polysemy (or fused-effects for performance) to make this strategy even more natural.

<comment><USER17> Polysemy still appears mysterious to me.

I would absolutely _love_ an article that translates the "Designing Testable Components"[1] part of this article into its Polysemy equivalent.

[1] [http://felixmulder.com/writing/2019/10/05/Designing- testable...](http://felixmulder.com/writing/2019/10/05/Designing-testable- components.html)

</comment></comment><comment><USER18> Always nice to see Haskell at work. I haven't learned the language myself yet, but I absolutely love postgREST, which is implemented in Haskell.

</comment><comment><USER19> I'm not sure why this post is getting so much hate, it's well written and I really enjoyed reading it. Thanks!

<comment><USER20> People seem to hate Haskell because it's not [popular-language-that-they-use]. To think that Haskell is used, liked, and works, seems to upset people who don't like, use, or understand Haskell. Or, so it seems.

</comment></comment><comment><USER21> How is such an obscure language - with associated difficulty in finding talented engineers - ever going to be a better choice than a more mainstream language, which probably has many of the same features?

<comment><USER7> > with associated difficulty in finding talented engineers

This is a myth. There are now _many_ experienced developers who currently can't use Haskell in their day job but would love to. If I decided to start another business, picking Haskell would give me access to a lot of top talent who would otherwise not be interested.

</comment></comment><comment><USER22> How long does it take the "new programmers who have not worked with Haskell before" to learn and understand all the ASCII-art in the example code? How $ differs from <$ differs from & differs from .

On top of trying to remember that <> is string concatenation and >>= and <\- have something to do with monads.

<comment><USER23> I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you _can_ write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putting.

<comment><USER24> It's because Haskell's type system at least helps you avoid getting the line noise _wrong_. If you have to refactor some complicated line noise then the compiler holds your hand.

<comment><USER22> What would an error look like if I misused $ or &?

And yes, compilers hold a user's hand in most languages (including PHP with type hints :) ).

<comment><USER25>
        • Couldn't match expected type '([Integer] -> [Integer]) -> [b]'
                      with actual type '[Integer]'
        • Possible cause: 'map' is applied to too many arguments
          In the second argument of '(&)', namely 'map (* 2) [1, 2, 3]'
          In the second argument of '($)', namely
            'map (+ 2) & map (* 2) [1, 2, 3]'
          In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

<comment><USER22> In my opinion this doesn't help much.

<comment><USER7> Of course not. You have to learn how the type system works to get it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> I really wish Java had associated types and static methods as parts of interfaces (i.e. constructors as part of the interface). Those two features make complex architectures much easier to design and use.

<comment><USER27> Interfaces can have static methods.

<comment> james-mcelwain I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods.

AFAIK there are issues with how Java handles dynamic dispatch that prevent this.

<comment><USER27> What would calling such a method look like?

<comment><USER28> Imagine that Collection had a static method `empty` that created an empty collection of the appropriate type depending on the type you are assigning it to, e.g. `List list = Collection.empty();` would create a list, `Set set = Collection.empty();` would create a set, and so on. This would be fairly similar to how things work in Haskell.

<comment><USER27> If you know you're creating a List (it's there on the LHS) why not write List.empty()?

<comment> james-mcelwain Here's how it works in Rust. You can imagine this working in Java with reified generics: [https://gist.github.com/rust- play/214adf5bd15b18ec2d5c63d97f...](https://gist.github.com/rust- play/214adf5bd15b18ec2d5c63d97ff8ba2c).

<comment><USER29> Fascinating! What are the uses of something like this? Is this at all related to concepts or metaprogramming?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> If I remember correctly, Co-Star, the horoscope app, runs Haskell on the backend.

<comment><USER31> Boy those guys must be laughing at their customers.

</comment></comment><comment><USER32> This is an incredibly good series. Just what I've been looking for. I'm writing a Servant API myself and this really explains a lot of the fundamental concepts in plain English.

</comment><comment><USER33> > We tried a lot of different patterns - readers, handlers, MTL, and tagless > final.

Is there any books or long form articles digging into these different approaches? I know basic Haskell and heard of these different patterns a few times. I'm curious how it looks in a larger Haskell project and what the pros/cons are of each, and general popularity.

Edit: I see the next article in the series has more real code examples

</comment><comment><USER34> The more I see it in use, the more I want to learn Haskell, but I can't think of a practical reason to do so.

<comment><USER7> Learning things is how you keep your brain sharp.

<comment><USER34> I need to get halfway fluent in JS first, but good point.

<comment><USER7> Once you get there I recommend then learning Typescript (Javascript with types) and compare the experience with Javascript.

</comment></comment></comment></comment><comment><USER35> The amount of knowledge required just to have a clean design o the simplest of things, i.e. a few functions that add and delete users is very big; almost all of Haskell's important parts need to be known.

Is that good? for me, it's an obstacle. I can't expect all the developers that come and go to have a perfect understanding of monads in order to use/debug/extend such code.

And what did Haskell actually buys us here? my apologies for being skeptical, but it doesn't seem to buy us anything...in other languages, such things as creating a user, deleting a user, logging actions requires a lot less boilerplate and complexity.

</comment><comment><USER36> Everyone in the comments either doesn't like Haskell, because it's hard and different or niche or whatever, so they think Haskell is bad for production even though they don't code in it and haven't worked at a place that used it extensively.

The other group of people in the comments are people who love Haskell and are happy to have validation from the OP.

But I'm not really any wiser. I like Haskell, but I work in DevOps and the language simply isn't relevant there.

<comment><USER37> Everyone... except for the top comment?

</comment></comment><comment><USER38> It's interesting to watch the wonderfully meandering train of thought(s) triggered by a success report of using a non-mainstream programming language. So let's meander some more...

The strong reactions are understandable. New programming languages are added to the zoo faster than ever before. And within each language there's a steady influx of new frameworks (angular1, angular2, react, vue, ...) each with a learning curve. It's a challenging environment, and it feels like it's getting exponentially harder as time progresses. One must resist the trap of following every silly new idea.

So why bother spending even an afternoon with Haskell? Spend an afternoon playing with Python and you'll be writing code the next morning. Spend a day with Haskell and you'll have more questions than answers.

The fundamental problem is, most likely, the new paradigm. Functional programming takes some time getting used to. Sure, the functional style is creeping into mainstream languages, so most of us have seen and used it already. But _pure_ functional programming is another level. Broadly speaking, everything is a function, a function in the mathematical sense: Same input, same output. Everything is immutable, it's all about chaining pure functions. Crazy, right? Why would you subject yourself to such rigour?

I'll argue that pure functional programming has something to offer that is more relevant than ever. 1\. Pure functions are easy to test. Same input, same output, that is a strong guarantee. It'll still be a challenge to thoroughly test every single function, but at least each test is meaningful because there are no interactions with anything outside the function. 2\. Pure functions are easy to compose and parallelize. Single-thread performance is hardly ever a relevant benchmark anymore. Sure, C is faster, but good luck trying to parallelize a complex C program. (The worst thing I can imagine is having to debug messed-up, multi-threaded C++ code.) 3\. There is structure in how to compose pure functions, and it's structure in the mathematical sense, not in the fuzzy Gang of Four pattern sense. Much of the 'arcane', 'academic' jibber jabber is exactly about these mathematical structures. The power of having a rigorous method for structuring programs is immense. It really is. The hurdle is not a high as it may seem (unless you have a low affinity to maths - <USER3> which case you probably shouldn't be programming computers anyway). 4\. Pure functions are easy to refactor. (See below.)

I'll also argue that strong typing has a lot to offer and will become more mainstream. 1\. Make the compiler your friend, not your enemy. Strong types glue the functions together in just the right way and prevent me from making silly mistakes. 2\. Business logic can be encoded in a compact and transparent way. Changes to the business logic (and it always does change, doesn't it?) are also compact and transparent. 3\. Refactoring is just ... wonderful. Strong types combined with pure functions, that is a magical combination. Change the type and let the compiler tell you what the implacations are. As there are no side effects code can be refactored with confidence. It is a vastly different experience from any OO language.

Now, finally, to Haskell: It can be characterized as a strongly typed, lazy- evaluated, garbage-collected, pure functional programming language. (Lazy evaluation hasn't been mentioned, yet. It's something that needs to be understood and considered in order to write efficient code.) In "language design space", something like Haskell must exist and will always exist. (I say 'always' because maths has something eternal about it and pure functional programming and strong typing have solid mathematical underpinnings.) And in this "language design space" Haskell dominates. Contrast this with the compiled, weakly typed, imperative, low-level languages like C, C++, Golang, Rust. I have a hard time picking amongst those, but I believe everyone should know at least one of them.

So is it worth learning Haskell? I tried to argue that it's not a fad and the concepts are fundamental and increasingly important. To me, personally, it looks like a an investment I can benefit from for decades to come.

As a business, do the advantages outweigh the costs and risks? We all know that corporate culture often stands in the way of change. One root cause is the asymmetric payoff: A thank you if it goes well, and job-loss if it goes badly. In such an environment inertia is the rational choice. - But if your company truly believes to be an innovator, or leader in the field, or seeks to gain an edge over the competition, then Haskell should be on the list of things to try.

</comment><comment><USER39> Advice for people using Haskell in "production": Don't. Save not only yourself the disappoint, but every other stakeholder around you. Use something tried and tested.

<comment><USER7> Let me guess: you have never programmed in Haskell?

<comment><USER39> I have programmed in Haskell. I have programmed in assembly. I have programmed in just about every language in-between. Haskell is at best, a sophisticated toy suited to a small subdomain of problems.

Have you ever tried to roll Haskell into production, when compared with something like C# or Java?

<comment><USER40> What was your experience like rolling Haskell into production?

<comment><USER39> Cabal is probably the most unsuited packaging system for production software. It has no useful test integration nor freezing ability. Tried to change profiling? You're in for a bad time. What about deployment. Want git? Nope. You can't. Want to build artifacts? What is this, TypeScript?

</comment></comment></comment></comment></comment><comment><USER41> > Haskell is great for business and great in production.

Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell.

If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to write it in Haskell", I'd get laughed + kicked out.

<comment><USER42> > It is extremely hard to learn, has an extremely confusing + needlessly > complicated syntax and

I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part

<comment><USER43> >but what's wrong with the syntax?

I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better.

[http://www.haskellforall.com/2015/09/how-to-make-your- haskel...](http://www.haskellforall.com/2015/09/how-to-make-your-haskell-code- more.html)

<comment><USER44> Note that this is to make Haskell more readable _to non-Haskell programmers_ (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code _less_ readable if you're familiar with Haskell and is quite frankly just bizarre. I do not think you'll find many programmers, Haskell or otherwise, who find lots of nested parenthesis to be the paragon of readability.¹

If the goal is to show snippets of cool Haskell code to other people this article is… fine I guess? But I don't think it's good for much more. Not even for teaching Haskell, since people should probably learn the language as it is used instead of some arbitrary "more readable to non-Haskell programmers" version. Using do-notation is probably even counterproductive for teaching since it obscures what's actually going on.

Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

―

¹ Lisp programmers aside, but even then in Lisp you're basically just drawing a tree and so the parenthesis kind of fade away, but in languages with infix syntax and operator precedence you can't ignore them.

<comment><USER45> > Honestly this sentiment from the Haskell community that Haskell is somehow > bizarre and impenetrable to outsiders

They're not inventing that from thin air. I can understand Haskell with a great deal of effort, but it certainly requires a great deal of effort.

My wife is a non-programmer. She knows nothing about code. I could explain what the go code I write does in a few minutes and she could follow it with a minimum of hand waving. I don't think I could explain any non trivial Haskell code in hours to even professional programmers

<comment><USER7> I have explained Haskell code in a few minuts to professional programmers and they got it. It took a bit longer to explain monads but it wasn't hours.

</comment></comment></comment></comment></comment></comment><comment><USER46> I will probably get stomped on for this but to me it's a giant elephant in the room.

When that one purist on the team proposes mandating having 100%, 80%, or _any_ hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity.

However - when one (ie, a Haskeller) says that the code must universally pass 100% _strong static type verification_ coverage -- arguably SO MUCH worse cost/benefit than unit testing -- and you say "no that's impractical" it's suddenly a different game.

The elephant in the room is this. Haskell and strongly typed languages are highly impractical, academic pursuits. They do not at all respect the dynamism of the real world. You can certainly build production systems in any language including Haskell but by picking Haskell you are throwing sticks between your legs unnecessarily.

<comment><USER47> Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase.

I agree that haskellers have a tendency to disregard the cost of using sophisticated type machinery. Which is unfortunate because haskell's greatest strength (IMO) is its ability to opt in to strong static verification for the 10% of code where it provides the most value.

<comment><USER46> > Just because an expressive static type system is available, doesn't mean you > have to use all of its expressive power. There's nothing stopping you from > writing your system using little more than String, Int, lists, IO etc. Of > course, you probably have a higher chance of bugs, but that might be the > right tradeoff for your usecase.

This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do-able" but only in a sense. And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind.

<comment><USER20> This is opinion. Haskellers have opinions too. Whatever you like and whatever gets the job done: bravo

<comment><USER46> Nope. Not everything is "every way is just as good as the other".

>Whatever you like and whatever gets the job done: bravo

"The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least.

There can and should be a conversation about doing this job well.

Mandating strong static typing across the board is exactly what Haskell does. My claim is this is death to productivity/throughput when you compare it to alternatives. The death part can be argued --the best leg Haskellers can stand on afaict is that _overall_ throughput is increased due to decreased attention to the kinds of bugs prevented by strong typing. This needs to be proven by them.

Otherwise -- by definition -- strong type systems are asking you to take special care to meet a type proof that is not necessary to do to implement correctness in other PLs.

Every time I've implemented a solution in a strongly typed system I always run into the type prover complaining about something that _Might_ be but that I can prove is not the case. Here is the limit of the type checker - it is simply not aware enough to understand what we're doing. So it puts needless requirements left & right. This is hostile to productivity.

Now you go.

<comment><USER48> I believe you're exaggerating the frequency that the compiler rejects valid programs. It happens, but no more frequently than random runtime type errors occur in dynamic code.

In any case, one can just as easily argue that the value of static types come not just when the code is first written, but under the legion of modifications that need to occur. Not to mention how self documenting it is which also aids modification.

Some people just don't like static typing, which is fine, but making the statement that it's categorically worse is hard to defend.

<comment><USER46> This is not an opinion thing. If you're saying that type checkers _can_ reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of a proof to how this is possible. And what is this magic type system that can do this, bc it sounds like some super AI.

The reason I'm confident in my objections is because this is what I get from static typing fundamentalists: never a concession as to its cons and costs. Is it that static typers can't _see_ the relative costs bc they are not using the full power of dynamic languages?

<comment><USER7> > the full power of dynamic languages?

There is nothing you can do in a dynamic language you can't do in a typed language. There is no "special power" that only dynamic languages have. If you truly believe that dynamic languages have "special powers" that typed languages can't have then I recommend studying a bit of basic computer science. Starting with the Turing Machine or Lambda Calculus.

<comment><USER46> > There is nothing you can do in a dynamic language you can't do in a typed > language.

There is nothing one can't do in assembly that you can't do it in a higher- level PL.

The argument is not what one can or can't do.

The argument is that one world (dynamism) _allows for_ higher throughput than a static-checked environment. This can be discussed but the "can do" argument is of no interest.

You "can do" anything given enough time. One doesn't even need a programming language. You can manually execute instructions by hand. But this is not the discussion.

<comment><USER7> > The argument is that one world (dynamism) allows for higher throughput than > a static-checked environment.

I have programmed in both dynamic languages and typed languages for 35+ years. And I am most definitely more productive using a typed language. Otherwise I wouldn't. So I wonder why our experiences are so different?</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Something was wrong. It seemed I had angered the techno libertarians. - <AUTHOR> http://squashed.tumblr.com/post/167363113/why-people-are-sheep <comment><USER2> I was disappointed by the backlash against Squashed on this site. Partly it's because he writes a personal blog, doesn't go out of his way to promote himself, and so probably wasn't writing for the Hacker News crowd; partly because as a former Tumblr user, he was one of the bloggers in the "in" crowd that wasn't snooty or irritating, and he spent a lot of time crafting his ideas to display online.

Also, the phrase "Lodwickian UberMensch" is worth a hundred upvotes. I'm a fan of Jake Lodwick's work, met him once in NYC at a concert, but his attitude towards other people is at least somewhat off-putting.

<comment><USER3> Are you serious? The guy's whole post is one massive trollbait designed to make people angry.

<comment><USER2> No, it's not. Again: I've read Squashed for a long time. He goes back to the very beginning of Tumblr. Usually, he writes for himself and, perhaps, for a small core of readers who like his opinions. You need to understand that Tumblr's different from most blogging platforms in that it has a built-in community, so that the people who use it frequently feel a lot more freedom to express their opinions in a more personal way. Marco Arment, who's on Tumblr's staff, just wrote this week about how he never tries to write for news aggregators anymore.

So Squashed disagrees with the people who flamed out against him, and I'm certain he believes what he's writing, but don't see it as him trolling. Rather, it's him writing how he feels without thinking about who's going to read it. I'm certain he didn't expect Hacker News picking on him, and so didn't make an attempt to round out his writing and make his ideas balanced.

He has that right. Since when do bloggers have to write for any audience other than themselves?

<comment><USER4> since the 'net made the world small enough that you have to deal with the opinions of those you've offended

<comment><USER2> He doesn't, really. If things got bad enough, he could disable comments and ignore us all.

I think we're a mature enough community, however, to learn not to get ourselves enraged over one man's personal blog, and to let him keep to his own circle. We can just not upvote the things he writes that we decide offend us.

It would be a shame if the shrinking world led to alienation and hatred rather than to communities selective enough not to start flamewars with all the other ones.

<comment><USER5> I think grandalf is right on this one. That last article was pretty dickish.

I hadn't actually expected a whole lot of people to read it. (No, I'm not doing anything to promote the site. Some of the ... less gracious than usual comments tipped me off that something was up, and Google Analytics suggested I look at ycombinator to figure out why the heck it had increased my monthly traffic by 900%.)

The big regret? I was reworking the layout. Because I suck at CSS, this takes a few days. Normally it's not a big deal. There may be forty or fifty non- Dashboard visitors. When traffic spikes at the same time as the layout is unprecedentedly ugly, that's something to be ashamed of. I'm surprised anybody even read the article. I would have been tempted to comment, "D00d, ur site is uglier than ur m0m. tl/dr."

</comment></comment></comment></comment></comment></comment><comment><USER6> Maybe I'm crazy but this seems like an argument for communism. Basically he's saying success is due to luck and that the playing field will never be equal when some people can be lucky and others can't. Take this quote…

"This can lead to some awkward philosophical conclusions. If you have succeeded by doing something relatively simple, you have to ask yourself why everybody else hasn't done the same thing. You could tell yourself that they simply value different things and thus chose their lives. You sacrificed and worked hard-and even if somebody else looks like they've worked hard without the same results, they must be secretly lazy."

He's basically putting forth two premises: (a) 2 people can work equally hard and get vastly different results and (b) that there's something inherently wrong with that. But if both those are true than there's really only one solution which is communism. That's the very definition of communism in fact. Government is the only entity that has enough power over people to make things fair so it should control all the resources because it will act fairly and distribute rewards evenly.

I don't mean to accuse him of holding a belief he doesn't hold but how else could the world create the environment he desires?

<comment><USER7> Communism? I certainly didn't read it that way. Have you considered the idea of a basic income - it's been mentioned before here, most recently <http://news.ycombinator.com/item?id=756880>

Via the inspiration for that thread: <http://en.wikipedia.org/wiki/Basic_income>: "Winners of the Nobel Prize in Economics that fully support a basic income include Herbert Simon[24], Friedrich Hayek[25][26], James Meade, Robert Solow[27], and Milton Friedman[28]."

Hardly communists, or even Marxists. It seems to me that the original poster is not arguing for government enforced fairness (and communism isn't any better at delivering that than capitalism IMO), but for mitigation of the worst inequities. Over in Europe colege education is heavily subsidized by the state, on the understanding that the state will collect a rather greater share of subsequent income in the form of taxes. This is by no means perfect, and indeed European college graduates are not assured of a job or promising opportunities on graduating either, far from it; but at least they graduate without enormous debts.

On the flip side, America provides far better business opportunities for entrepreneurs, not least the simple fact of a single market of 300 million with a single dominant language and a national media landscape, which is not to be sneezed at. Indeed, in 50-100 years, when China or India have caught up with the developed world in terms of GDP per capita, the potential entrepreneurial gains from being able to market to a Billion people at once will make US business fortunes look modest.

I think the point being made here is not that communism or any other system is better than capitalism, but that diligence and loyalty are socially exalted but economic rewards flow more towards opportunists and rent-seekers.

<comment><USER8> > Indeed, in 50-100 years, when China or India have caught up with the > developed world in terms of GDP per capita, the potential entrepreneurial > gains from being able to market to a Billion people at once will make US > business fortunes look modest.

I don't know about India (but I'm sure it's a similar situation), but in China you have vastly different cultural groups across different regions. It's a _large_ country. And I'm talking a larger cultural divide than "East Coast" vs "West Coast" in the USA.

I doubt that you'd be able to having a marketing campaign that included all 1 billion people... It might be viewed by close to a billion people, but you'd have to be targeting a smaller demographic.

</comment></comment></comment><comment><USER9> Surprisingly well written article. I'm going to check the rest of his blog; let's hope it's all this good.

The article is supremely smug (because he doesn't seem to consider for a second that his point of view may be incorrect), and he shamelessly dismisses the counter arguments as delusional Ayn Rand fanaticism. However, it made the rant all the more compelling, so I don't mind.

The problem is that he made no real effort to acknowledge any of the counter arguments. Starts strong. Digresses in the middle. Ends abruptly.

<comment><USER3> How can you say that it's well written when it's smugness is over the top?

I thought it was one of the worst articles ever linked from HN, both in its annoying tone, its irrelevance, and is lack of actual points.

</comment></comment><comment><USER10> So, let me get this straight:

1) Some young graduate is bitter because he didn't fall into an awesome job right out of college.

2) His blog post about that was somehow worth someone linking it here, and people getting pissy about it.

3) He's followed it up.

4) That follow-up is somehow worth a huge debate here between people who can't meaningfully discuss libertarianism and people who can't meaningfully discuss libertarianism.

 _Seriously?_

"Graduate unhappy about not being given job" is not news. Complaints about the "young generation" are not news. Talk about how the "old system" that handed out jobs has "broken down" is not news.

These are stories that are older than many of the people posting here.

Maybe a discussion of why anyone in 2009 goes through life with 1950s-vintage ideas of how the world works is in order, but that seems under-examined.

</comment><comment><USER11> The author is saying that libertarians are the product of luck, moderate intelligence, and a bad understanding of sociology that limits their perspective to introspection alone.

The author's observation is based on a product of his bad luck, moderate intelligence, and a very selective view of the arguments advanced by libertarians.

</comment><comment><USER12> A few of his arguements rest on the idea that "techno libertarians" all got rich from the tech bubble, but I know plenty of them getting rich _right now_ sans bubble. Indeed, one of my most succesful friends got a job right out of college, and the offer came in august of 2008.

The author points out that many people do not have the luxury of enjoying computers. Well there are plenty of other careers that are high paying and intellectually stimulating (sales, actuary, contracting all come to mind). All of them require several years of practice and hard work before they result in a middle class income however.

<comment><USER13> I interpreted the dot com comments as an example of the larger point about the disconnect between 'being smart/working hard' and 'success'.

E.g. People get rich without being smart or working hard. They also _don't get rich_ by being smart and working hard.

Ergo Rand-ian assumptions are debatable and their conclusions in serious doubt.

<comment><USER8> I think there are few people that get rich without working hard or being 'smart'... but it depends on your definition of 'smart.' There are plenty of people that have gotten rich by being clever, while not well educated.

[ This obviously excludes people that have obtained wealth as some sort of 'birthright' ]

</comment></comment></comment><comment><USER14> The truly limiting aspect of this article is the author's assumption that a person can be typed as believing anything philosophically simply because of what he does or what he has or has not achieved.

This incorrectly assumes that one's belief in something being true cannot vary from a particular life perspective.

Can a student be a libertarian even though he has yet to accomplish much in life? Can a wealthy mogul believe in communism even though he is positively dripping in filthy lucre? Not according to the author's (implied) premise and yet we know that in both cases the answer is yes. It is the premise that is false.

Thus, the author basically answers his critics by slipping in, _sub silento_ , an _ad hominem_ attack to the effect that only an unthinking person who happens to have gotten quick financial success in life can possibly be a libertarian. The unexpressed corollary to this is that no one could otherwise possibly be so stupid as to believe in a libertarian philosophy.

I am not defending any particular philosophy in saying this; just noting the below-the-belt mode of argumentation. I think this is why it can rub people wrong even if points made along the way might otherwise be interesting to consider.

</comment><comment><USER15> I paraphrase:

He constructs a narrative of a hn user who does not feel "entitled" because he got what he wants. This hn user must be in constant anxiety because he is more successful than he deserves, so he rationalizes his position by explaining why others do not deserve as much success.

The phrases "entitled", "deserve" and "dumb luck" are much too overloaded. (PG essay: <http://www.paulgraham.com/gap.html>)

</comment><comment><USER15> _Odd. I generally only pull in a few comments a day—and most of those are fairly constructive—even when they are critical. Something was wrong._

half of the comments on that post are just stuff like "great post. thank you.". To the other half he replies with snark. Somehow this blog post is the opposite of the ideal HN discussion.

</comment><comment><USER16> I suspect the reason that technology and libertarianism go hand and hand are very different from those presented here. People who are technological are generally more engaged by machines than people, and have less of an appreciation of social norms. They also are more likely to appreciate the Austrian school of economics which is very mathematical in nature, and be less susceptible to emotional appeals in favor of certain policies (i.e. "oh how the poor kittens are starving, let's spend 1 billion on animal shelters this year").

<comment><USER17> Austrian economics is the antithesis of mathematical economics. [http://en.wikipedia.org/wiki/Austrian_School#Analytical_fram...](http://en.wikipedia.org/wiki/Austrian_School#Analytical_framework)

Many libertarians latch on to austrian economics because they already agree with the conclusions austrian economists come to, and it's easy for lay people to understand. Conversely, it takes quite a bit more effort to understand a neoclassical dynamic partial equilibrium model.

<comment><USER16> I perhaps should have explained a bit more clearly. The Austrian school relies on mathematical proof, as opposed to experimentation and the resulting analysis with statistics. Yes, statistics is math, but hardly anyone who finds logical rigor psychologically satisfying gets the same enjoyment out of a p-value of .082.

</comment></comment></comment><comment><USER18> It looks like somebody should ask Santa for a thicker skin next Christmas.

The advice I read here was of the tone: "Hey, we were once where you are now. Take it from us: It gets better, but your current mindset is set for failure."

The author should spend a day picking through the youth-directed angsty tunes and movies of the early 90s. He's not the first to go through crap like this, even in recent history.

Suck it up and take on a McJob to pay the bills until things recover. The experience in social survival will do you a load of good the next time things get rough.

<comment><USER2> So you see a problem, which is, "The way that modern society works puts a lot of people in soul-killing menial jobs and wastes their childhood", and your solution is "It's okay, other people have gone through it, stop complaining"? That's both cruel and obtuse.

<comment><USER18> Hardly! I'm saying "we're not strangers to what you're experiencing, but your conclusions are incorrect".

You can believe whatever you want, but belief alone won't make it true. Accept the environment you've found yourself in and then do what you can to adapt to and correct it. That's what I've done.

Bitching about it without action is going to do squat.

<comment><USER2> I agree, but I also think that there's great value in trying to change the environment entirely.

<comment><USER18> ...and how's that working out for ya, Bruce Lee?

Many, many generations have come before you with exactly the same idea, and all struck out (most notably the "boomers", who went a long way towards giving us the environment we're facing now). It sounds as though you want someone else to fix the problems you're facing rather than pick up your tools and fix them yourself.

Learn about the environment you've found yourself in and then try to fix it to the extent you are able. If _everyone_ did that in their own corner of the world, we'd get the result we wanted.

I faced a load of crappy jobs when I graduated in the early 90s and found myself far, far behind where I thought I'd be. Today, I'm running the kind of company I wanted to work for when I graduated.

I've worked at fixing my corner of the world and have succeeded to some small extent -- what have you done?

<comment><USER2> I don't agree with the people who're looking for some huge revolution in society. I prefer the guys who're quietly ducking out and finding some place where they can be happy. That's the subject of a whole different diatribe that doesn't belong here.

However, I sympathize with the thought that society as a whole does a lot of harm, and I don't like the people who get mad at the people who complain about it. That holds even if I disagree with some of the ideas of the original complainers.

<comment><USER18> Good for you, Sparky.

Now, what are you going to do about it out here in the Real World?

<comment><USER2> I'm afraid I don't know who Sparky is. I'm guessing he's not another martial artist?

I don't care much about the Real World. I'll just keep things stable and happy where I am, and avoid the rat race as much as possible.

<comment><USER18> So, nothing then? Of all the plans to 'change the world', that's the worst I've heard.

Kindly stay out of the way whilst the rest of us continue trying to improve things.

<comment><USER2> My actual stated plan was to worry about _my_ world, which is to say the people and places that matter to me. If people stopped trying to treat the world as a single breathing mass, we'd have less conflation and we'd all be a lot happier.

Don't act like you're on some sacred mission I'm not. You're on Hacker News. I know why _I'm_ here - I get a thrill out of debating people. You're here for no better reason. The difference is that you seem to think that your argument is above mine.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> What is his point? Either you grow rich in a bubble by sheer luck, or being a worker drone is your only option?

Seems to me he misses a few grey areas in between. Also, if you are not a Computer whizkid, there are other areas where you can succeed. Some people even got rich with a multitrack. (Not that getting rich is the only meaningful measurement for success).

What is the more cynical attitude: to assume people are miserable because they are sheep and just too scared to try anything, or that they are miserable because they are hopeless?

</comment><comment><USER20> If you're angering the techno libertarians, that's a pretty decent sign you're doing something right.

Also: techno libertarians on the internet == unintentionally hilarious.

EDIT: this comment score is a pretty decent sign I'm doing something right. :)

</comment><comment><USER21> Maybe I'm too much of a geek, or not enough of one, but I got a kick out of the "a dozen or so comments" turning into "71 comments" a second or two after page load.

</comment><comment><USER22> disappointed when this was not an article about Warhammer 40k.

 _+5 to your nerdosity_

</comment><comment><USER23> "Nor do they have any monopoly on a distorted view of reality." Libertarians' views of reality are almost always less distorted than the downright wacko views held by most Democrats and Republicans, socialists and conservatives.

Nor are all, or even most, libertarians particularly successful, much less the money worshipping conservatives the socialistic "social responsibility" whiners like this essay like to criticize.

<comment><USER24> _Libertarians' views of reality are almost always less distorted than the downright wacko views held by most Democrats and Republicans, socialists and conservatives._

From the perspective of a libertarian, perhaps.

<comment><USER23> There are two kinds of people in the world, libertarians (whether or not they call themselves that) and evil scumbags who want to control other people. It makes no difference what excuses you make for your evil; you all still have to twist reality to justify it to each other and to yourselves.

<comment><USER2> There are many kinds of people in the world. One similar dichotomy I could draw is between people who appreciate the nuance and complexity of being alive and having to make millions of decisions as you grow up, and people who think it's possible to draw a line and declare some people as evil and other people as good based on a single part of their existence.

<comment><USER23> People are extremely multidimensional; but the fundamental political division is willingness or unwillingness to coerce others, that is to use force to make others do what you want them to, which is THE fundamental feature of gov't.

<comment><USER2> I'll agree with you to some degree, but in some cases force is needed. See my response to you elsewhere regarding regulations, which I think is an important part of society.</comment></comment></comment></comment></comment></comment>


Entrepreneurs wanted; Kick starting the distributed economy - <AUTHOR> As the title suggests, I'm using the fact that ycombinator is a VC network and I expect there to be plenty of enterpreneurs here.
I wrote a paper that explains the ideas and what we really need in this industry to more distributed systems forward.  The paper gives a high-level overview of a system that facilitates generic distributed services by acting like a common-usage server to store the data the user wants and essentially having an always-on design so your users apps don't have to be always on.
You can find the paper as published on the publishing site yours.org; https://www.yours.org/content/entrepreneurs-wanted--kick-starting-the-distributed-economy-f4d6c84e2f6c
I got a user complain about some architectural thoughts being behind a pay-wall.  Please realize that the architectural design is just a hint, just ideas for how to implement it. Any architect can take the free text and design that.  I have no wish to earn money from this idea!
What I want is to see this or a similar idea become reality.  I can help anyone that is interested in starting an organisation implementing this and rolling this out.
Would love to hear more from you guys/girls.
ps. as mentioned, a user complained based on a misunderstanding. I hope its Ok to post a clarification and a better introduction for YCombinator and entrepreneurs connected to them, if I'm missing some rules about how to behave please let me know. I have no experience here.
Thanks! <comment><USER2> I made it about halfway through your manifesto before I gave up. Mind if I give you a couple of pieces of unsolicited advice??

1.) Find a good proofreader. This proofreader will ideally know a great deal about the decentralized economy.

2.) Stop attacking centralized apps. Trashing different architectures is not persuasive. If anything, it does the opposite because intelligent readers will start thinking of counterpoints when they should be digesting your arguments.

<comment><AUTHOR> Thank you for the advice.

I might do a better writeup some in some time, so this is useful for sure.

<comment><USER2> Thanks for the reply and best of luck. You make some wonderful points!

</comment></comment></comment><comment><USER3> I think many people like centralized services because they're often just nicer to use due to the stake/incentive the organisation running it has in to make it better. Also business customers like them because they've got someone to talk to and blame if things go wrong. Can't some things be decentralized where it make sense and others not be? Are you suggesting the examples of the services you listed have a decentralized version?

<comment><AUTHOR> All very good points and my suggestion is mostly in line with those points.

In most decentralized systems there are no incentives (other than wanting privacy, etc) and I agree with you that this lack of incentives has a bad effect on the quality.

In many ways my suggestion is to create a base layer that is run on centralized servers (like ISPs are centralized, without lock-in) and they have an incentive to make it better because the content-creating users pay them.

So the suggestion is to have a new horizontal market that enables distributed developers to create applications on top of.

The examples of services (chat / reddit etc) could be written on top of this horizontal market layer where the basic data communication part is paid-for and well maintained and the developers will have much less work to make their decentralized systems ready for mass consumption.</comment></comment>


$100k Raised in Three Days—Way to Go, Ruby - <AUTHOR> http://www.engineyard.com/blog/2010/100k-raised-in-three-days%E2%80%94way-to-go-ruby/

<comment><USER2> Infinite redirect because of long hyphen. Entire entry here: <http://www.engineyard.com/blog/2010/></comment>


I Made Deep Fried Water at Last Week's Stupid Shit No One Needs Hackathon in SF - <AUTHOR> https://www.youtube.com/watch?v=fDiHUZ3mjxM <comment><USER2> Not everything needs to be fried.... Also, wow. And many grats. That was in another sense quite a feat.</comment>


Grasshopper – A coding app for beginners - <AUTHOR> https://grasshopper.codes/ <comment><USER2> I'm torn about all of these types of apps. On one hand, I think it's great to invite people into the world of coding and doing so in a user friendly matter. No doubt Grasshopper and a handful of similar apps are well designed, but is it really the right way to go about things?

I remember vividly learning to code at age 11. I had an old computer, windows would constantly crash and the only thing I could access really was QBASIC.

Alongside a book with code snippets, I would simply write a line of code, hit run and see what happens. Then, go back to the code and 'go rogue' (meaning: change the numbers a bit and make the line 5pixels instead of 2 for example). This is where the magic happened, because I actually coded something. It wasn't part of an educational application, it was the real deal inside the real editor with a real output.

The learning always came from trial and error and in a way is very similar to how I still code things (when I'm not designing SaaS products for awesome B2B companies)

The book might be replaced with Google & Stackoverflow, but the principles are the same.

The magic of coding, I believe is in writing something that is real.

<comment><USER3> I think it's an important signal that in every thread like this rather than say "wow, I wish I had something like grasshopper when I was a kid", we start waxing nostalgic about QBASIC. (I'm right there with you btw).

A lot of us grew up learning with tools, not toys (except you, logowriter, you're cool). Then we went and made the tools totally unapproachable. So now kids get the opposite approach: toys, not tools.

Teaching software like grasshopper is an experiment, and we're about to see the results. The first version of Scratch came out in 2003. Obviously this is super fuzzy, but for the sake of argument call 2003 the border between the QBASIC/getting a Sam's teach yourself C book at B&N era and the Scratch era. So a hypothetical 8 year old who started learning with scratch in 2003 is now 23 years old. The kids who grew up on this stuff are about to start showing up in adult life, and it'll be interesting to see how they turn out.

<comment><USER4> This would make a great AskHN.

It would be interesting to know if anyone on HN in their early 20s or lower were first introduced to software development via scratch or some other means.

<comment><USER5> I'm 24, so maybe a little old, but I was first introduce to programming with Game Maker. Later I did a little bit of Flash if you count that, and then moved onto Visual Basic.NET when I did 'Software Development' at high school.

For a long time (since mid-primary school) I had been toying with HTML, mainly from a book from the local library, and by just looking at the source code of websites that interested me.

I think it's clear that 'toys' like this, and like Game Maker, that make programming simple and user-friendly have been around for a long time, and don't necessarily stop people from learning more advanced concepts or languages, except if they lose interest. But even if they do, hoefully they will have packed up some skills that they can apply to other endeavours.

<comment><USER6> Here are some thoughts with no real point.

For me (26), part of what kept me interested in learning to program was the sense that I was working through something convoluted and solving some personal problem. Overcoming some sort of adversity. In this case, it was writing hodgepodge pascal to automate Runescape and Neopets, then also Flash for fun and profit.

I now have friends that are interested in the concept of programming, but have no application for it. I'm happy to aid in their journey, but when they ask me "What should I program?" I have no idea what to tell them. "Pick something arbitrary" I say, only to hear "What's that mean?". I feel like programming is something most people either come to organically or don't follow though with, regardless of challenge involved.

If we are to think about what would make a successful programming class, would it look more like math such that "Today we'll learn math, because math will totes be useful later for some reason" or would it look like "Make a computer do something interesting or useful with minimal human interaction".

</comment></comment></comment></comment></comment><comment><USER7> We're super excited to be announcing Grasshopper today! We're hoping that it'll make learning to code accessible to more adults that are interested in applying coding skills to their careers, hobbies, or just for fun.

Please let us know what you think, ask questions, all that jazz. We're still in the process of learning and making changes, so all feedback is super helpful.

\- Laura (Grasshopper Founder)

<comment><USER8> I click "Start Learning" I get "Grasshopper wants to use google.com to Sign in"

Why?

<comment><USER7> Good question! We're building Grasshopper while we're within Google's Area 120, so the easiest way for us to ensure Google's privacy best practices are followed is if we use Google Authentication.

It might be possible for us to convince the powers-that-be to use another form of authentication, but for right now, we're sticking with just Google Auth.

<comment><USER8> I think that:

Privacy best practice is to know nothing, or as little as possible, about the user.

If storing progress is required, and local device storage is not sufficient, a minimalist online setup is the desirable solution.

An automatically generated user id and a simple user-progress table should be enough. GCloud has all the required parts ready to go.

In any case this whole thing should come _after_ the user has had a chance to experience the product.

But that's just me.

I ain't no power-to-be ;)

<comment><USER7> We've thought about putting the signup after the tutorial, just haven't had the time to get to it just yet. I'll add this as a +1 to us starting to work on it :)

Thanks for the feedback!

<comment><USER9> The google signin was the stopping point for me too.

</comment></comment></comment></comment></comment></comment><comment><USER10> I tried looking for a video of someone using the app so I could get a more clear idea of the sorts of things it would teach. This is the first thing I came across: [https://www.youtube.com/watch?v=lsA2bGdrkaQ](https://www.youtube.com/watch?v=lsA2bGdrkaQ)

I found it interesting to hear the kinds of reactions the kid was having to it: if you skip around the video you'll see the most common reactions are jumping around between distress, frustration, and anger.

 _I don 't think that's because this is a bad app._

Instead, I think that's probably a natural part of learning to program—and of programming even once you've learned. It's kind of a strange thing that something which can bet net enjoyable (oftentimes) can also so typically elicit those kinds of reactions (of course adults are better at suppressing them, but the impact must still be there).

</comment><comment><USER11> You would think that someone at Google could use their own search tools to look up a name for a coding tool before using one that's already been in existence for years. [http://www.grasshopper3d.com/](http://www.grasshopper3d.com/)

<comment><USER12> You're assuming they care. Google was aware of a startup called Inbox that did stuff with email, yet they went ahead with their own app called inbox, steamrolling the startup.

I have no reason to suspect the same thing isn't happening here.

<comment><USER13> Wouldn't be the first time that happened. Go had the same "issue." [0]

The ticket was eventually closed with status "unfortunate"

[0] [https://github.com/golang/go/issues/9](https://github.com/golang/go/issues/9)

</comment></comment></comment><comment><USER14> I'm the CTO of Grasshopper and am happy to answer any questions folks have about how it works. :)

<comment><USER15> Can we get an alternate method for the signup process? My children who have devices don't have Google accounts.

<comment><USER14> Thanks so much for the feedback (both here and in the app). That's something we're looking into, and I totally understand it makes it hard for kids to use the app. Grasshopper is an Area 120 project (a part of Google) which is why that account system is currently used for syncing course progress and achievements between devices.

btw is there a login system you'd prefer? I'd love to forward any thoughts you have to the Area 120 leadership.

<comment><USER16> How about an anonymous login system that doesn't require an email address and just generated a random userid / password? I'm thinking of setting up a Code Club at a local school and it would be great if kids could use it without having to provide any personal information whatsoever.

<comment><USER14> Thanks for the idea! Supporting things like anonymous login or username/password is definitely something we're considering. :)

</comment></comment></comment></comment></comment><comment><USER17> If my first language had been javascript I would have walked away and written off the computing world as a joke.

<comment><USER18> How familiar are you with modern javascript?

</comment></comment><comment><USER19> Seeing the response on HN to these kinds of tools/toys makes me wonder if they're marketed incorrectly.

These things aren't really teaching "how to code" (what we associate with stuff like Java, Python, etc.), but "how to think like a computer" or "how to break down and solve problems." I wonder if there would be an equally pessimistic reaction if the headline and marketing material said that instead.

I think a lot of being a successful developer comes from being able to think a certain way, and I think that these types of games/toys can definitely help children learn to think that way. I remember the Dr. Brain games giving me some of my first glimpses into this kind of literal, step-by-step thinking.

</comment><comment><USER20> I'm now tired because I played with it instead of going to sleep :(. I must say, it's well-executed and feels lightweight (which is a surprise both considering applications of this kind, and considering applications coming from Google).

I must say I love the attention to details! I was impressed by the effort that seems to have went to design the error detection - I start to mess with an example, and the messages tell me _exactly_ what I'm missing at the right level of abstraction. Like, I forgot to to the next line when drawing blocks, and the popup explains I should use newLine(). Or, in another case, the popup telling me that yay, I have row 1 and 3 of the solution correct, and need to work on row 2. Etc.

Also the little details made me smile - like being able to replay the "jumping grasshopper" animation on success screen by tapping the grasshopper.

The keyboard model used in Grasshopper is something I first seen in Hacked ([http://www.hackedapp.com/](http://www.hackedapp.com/)), and it seems to be catching on, which is great! Now I really wish someone would make a keyboard for Lisp like that; I could do some work while standing in a bus...

</comment><comment><USER21> The name is a bit confusing, as Grasshopper [1] is also a coding tool for beginners, designed for 3D algorithmic modelling.

[1]: [http://www.grasshopper3d.com/](http://www.grasshopper3d.com/)

</comment><comment><USER22> Congratulations on launching. I'm looking forward to trying it out, but on first glance I wanted to say that the design is very charming.

Edit: a Google account sign in, however, isn't that charming. I got a 404 on trying to log in. Oh well.

</comment><comment><USER23> So here's the question: does this product reflect any of the research into teaching programming or is it just "somebody had an idea"? There is nothing on the website I could find that addresses this.

We know a reasonable amount about teaching programming, and in particular we know that traditional methods are really bad. Most people, when they teach programming, reproduce the poor traditional methods used to teach them.

There is already a large quantity of "learn to code" apps and sites. We don't need more. We need more quality.

</comment><comment><USER24> More info: [http://time.com/5243949/google-grasshopper- game/](http://time.com/5243949/google-grasshopper-game/)

</comment><comment><USER25> Been playing another game from Google this week with the wife and a lot of fun.

[https://kotaku.com/google-s-new-word-game-is-fun-but- weirdly...](https://kotaku.com/google-s-new-word-game-is-fun-but-weirdly-into- brands-1825302946) Google's New Word Game Is Fun, But Weirdly Into Brands

</comment><comment><USER26> Does not work without Google play services

</comment><comment><USER27> Long ago I had an Apple Newton. The funnest thing for the Newton, by far, was a program that would evaluate statements or code snippets of NewtonScript on the device. It let you try little programs while you were waiting for something.

</comment><comment><USER28> As far as I can tell, if a child is on a Google account with parental controls, it is impossible for them to log into the app. This kinda sucks for a nice educational app.

</comment><comment><USER29> I would've recommended this to people I know that want to learn to code, but I wouldn't wish JavaScript to be my worst enemy's first coding language...

<comment><USER30> Really? I think JavaScript is the perfect language to learn with. Yes it has its quirks and weird edge case, but from someone with no programming background I think JavaScript is one of the easiest and most practical language to learn.

I think a lot of the "bad stuff" can be seen as an advantage. Like for example:

\- Lack of strong typing \- User don't have to bother with the data type at first, they go directly into the logic

\- Typecasting when comparing \- faster for quick comparison. E.g. if a user wants to check if the input of the user is equal to a certain number, he doesn't have to cast it as an int/float/whatever before, he just does "10" == 10 and it just works.

And also, its greatest strength I think is the fact that it's the language of the web, and web development has the lowest "barrier to entry", because all you need is a notepad and a browser and you can easily develop and test.

Anyway, as many people have pointed out, I don't think it matters that much what language you start with, because it makes you learn the logic of programming, which is then transferable to all other languages anyway.

</comment></comment><comment><USER31> What is the business model ? Or is it a PR app ? How do you get a job like this, where you can do public good and not have to worry about founding !?

</comment><comment><USER32> No one is going to learn to be an effective programmer using a smartphone.

I do expect a lot of people to install it, use it for 5 minutes, and never bother with it again. It's a perfectly suitable way to push people out of programming because there's no way you can get a real feel for it with a smartphone. All of the 'learn to "code"' applications that don't involve writing actual software seem like a giant waste of time and effort to me.

</comment><comment><USER33> I installed it last week. I was torn whether the constant reminders to do it was helpful or annoying.

</comment><comment><USER34> Why so cute? :(

</comment><comment><USER35> "The road to hell is paved with good intentions"

Can they please just stop putting their fingers in every pie? I WANT Free coding lesson websites, but not from google thanks. They should stick to github with their contributions.

It's difficult to enjoy our lives, with these corporations strolling in like "IS THAT FUN WE SEE?!?!" (because they're giants)</comment>


Ask HN: Why do interviewers not give you feedback upon rejection? - <AUTHOR>

Why do interviewers end most rejection rounds with a "You're not a fit for what we're looking for" when they could be giving you constructive feedback instead? <comment><USER2> I'm tempted to just tell you to rent the classic Dustin Hoffman movie _Tootsie_ and watch the first few minutes.

The basic reason why it is polite to give people flat, euphemistic turndowns -- not just at the end of interviews, but in lots of breakup situations, including exit interviews, declining of contracts, and breakups with SOs -- is that you don't want to prolong the agony or send mixed signals. You don't want to appear to be negotiating. You don't want to appear to be trying to cause excessive pain. You certainly don't want to provoke the person to burst into tears, physically attack you, stalk you for weeks, months, or years, or file a lawsuit.

You also don't want to tell a person that they're hopeless and will never succeed in the industry and then wake up to find out that they're Steve Jobs. That happens. It happens all the time. Interviewing is a mistake-prone, statistical process and decisions are based on hunches that cannot be explained, only rationalized, even to oneself.

There is a reason why constructive feedback is so valuable. People won't give it to you up front. I myself am much more direct online than in person -- in person I'm a hopeless softie, until you get me into an engineering situation or otherwise give me hints that you can take it. Not everyone has the emotional stamina to withstand the full force of MIT-style, anonymous-peer- review style power criticism.

<comment><USER3> Also, interviewing is a weeding-out process. If they tell you what you did wrong, then you (and anyone else you share that information with) will become better at gaming that process. This makes it harder for them to tell whether they have a good candidate or someone who can game the system well.

<comment><USER4> A good interview process should be resistant to gaming. For instance, multiple interviews. Multiple people doing the interviewing. Asking the candidate to demonstrate a capacity to do the work.

But, let's say the candidate does successfully game the interview and gets hired. Your company should absolutely use the first N-days of a new hire to check fit. Many I've seen explicitly say the first three or six months is a probationary period. The problem is when companies aren't honest with themselves about making a bad hire (capability or fit) and letting the new hire go.

Particularly for internal job candidates, I highly recommend being direct and saying, "Here's where you're short. Here's what you can work on over the next year or so to get into a better position. It's not a guarantee, but you'll be better prepared." Give them homework.

If a candidate is really and truly interested, they'll follow through on the advice and follow-up on it. That gives you a better candidate to look at for your next req.

</comment></comment></comment><comment><USER5> I spent > 2 years of my life doing a face-to-face technical interview (ramping up the staff for a prior startup) literally every day. I've also been a hiring manager for a large tech company. I've given a _lot_ of interviews.

The problem with interviewing is simple: all you can determine during an interview is whether the person is good at interviews.

That skill is not necessarily a good indication of doing well at any given job (especially with software engineering). The "constructive feedback" would be at best, superficial, but more likely, it would be based on the "blink response" of how the interviewer perceived you as you walked through the door -- so it's not only dubiously-based advice, it's advice that most people find hard to deliver.

The large tech company also explicitly told managers not give negative feedback due to legal reasons.

</comment><comment><USER6> One thing that I haven't seen mentioned yet.

A lot of hiring decisions come down to personality fit and likability, especially if you're hiring for a small team. Telling someone that you just don't like them is a pretty difficult thing to do for most people.

I know that I couldn't say it and have personally fallen back on the "we got a lot of good applicants and it was a tough decision" non-answer.

</comment><comment><USER7> Because it does not benefit them in the short run and to eliminate the possibility of saying something that could land them in legal trouble.

<comment><USER8> _the possibility of saying something that could land them in legal trouble_ When I worked for Kaplan (a subsidiary of the Washington Post), we were trained to not give any feedback after interviews or teacher auditions specifically for this reason. There was a situation where a potential teacher was not accepted after an audition and he asked why. A Kaplan representative told him that it was because he had a thick accent and that students would have trouble understanding him when he spoke. He filed a lawsuit alleging racial discrimination and in the end Kaplan settled out of court. Pretty much any reason you give for not hiring someone could be interpreted as discrimination of some kind. It may not be enough to win a lawsuit, but it is enough to force you to settle to avoid the bad PR.

<comment><USER9> And, sadly, that is actually a good reason not to hire someone to teach a class. As many unfortunate students can attest.

<comment><USER10> I had a TA once who had an incomprehensible accent. When people complained, some honcho from the department came to class and berated everyone for complaining because she had passed all the qualification tests to lecture in English, despite the fact that _actual students couldn't understand her_.

This was in the business department. Apparently, the people who are supposed to be teaching how to run a business valued their own a priori qualification tests over the experiences of actual customers[1]. While the situation pissed me off even then, the irony did not occur to me until years later.

[1] Academics don't like the implication that students are customers, but in this case the analogy holds.

<comment><USER11> And those academics are right. Let me sidetrack for a bit, because this is an important point, that not everybody thinks of:

If students had to pay the actual cost of their education, it'd be much higher, even in Ivy League schools. Universities complement the tuition fees by getting public funding.

And (in theory, at least) tax money should be given for a good reason. The public as a whole does not care about the personal benefits that some would get by gaining a degree. That's the private interest of those people, and we're talking public good here: it should help all.

Tax money is given to universities so they would create inventions and innovations in science and art, which are in the public interest. And to create those we need well-educated people to invent and innovate.

Thus it's not the students buying education. That's a byproduct, and they're not the customer, just a beneficiary. It's the public buying educated people.

Of course, this is all pinko-think, and it's true that some academics are just old farts who keep wondering how dare those students interrupt the academics very important nap time, and who thought of letting students in campus anyway?

<comment><USER12> > If students had to pay the actual cost of their education, it'd be much > higher, even in Ivy League schools.

That seems really unlikely. The fact that it's expensive to provide this exact bundle of services doesn't mean that's what would get provided without the subsidy. What's more likely is that the services that mean the least to the customers would get cut until the tuition was more reasonable. Without tax funding you'd get schools that were focused primarily on teaching. Like high school, but with more accomplished teachers.

<comment><USER11> And then we won't have research. So the material taught will stagnate, just like in high schools. If we treat students as customers, then they want the best -- so to improve, the student-oriented university would hire teachers that are also great researchers, so they'd have something new to teach, that isn't taught by the competition. And that research is costly; and we come full circle to the research-oriented universities.

<comment><USER10> How much does an undergraduate really learn that's from the latest research?

<comment><USER13> Not too much (and that's particularly true if you look at the older engineering disciplines.) The goal of an undergraduate education would be to learn how to learn.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> They don't have the time, they don't want lawsuits, they can't tell you that they ended up hiring Jeff the tax guy's cousin because many of the staff already knew him and he's a good dude as well as a good coder...etc.

</comment><comment><USER15> In my experience almost all candidates can figure out for themselves why they didn't get the job. Some of that is from giving plussed/non-plussed signals during the interview but mostly people know when they don't know the answer to something.

The few people who have ever asked me for feedback were simultaneously the least qualified and most confident candidates people I've met. No matter the answer the next step always seems to be pissed off replies, demands for a second chance or thinly veiled threats. I've stopped giving feedback because there's just no value in spending my time on it and the people who want it don't seem equip to use it.

</comment><comment><USER16> I've found that when you're rejected, it's okay to write back asking for specific guidance as to how you might improve for next time. I've gotten valuable insight > 50% of the time this way.

<comment><USER17> I often ask for feedback _during_ the interview.

If I'm interested in a position, I'll typically ask the hiring manager what reservations or concerns she may have about hiring me. Factual errors aside I make it a point not to debate those concerns at the time (and I make it clear up front that I'm not going to try to talk them out of their concerns), but I've found:

A) You typically get fairly honest answers this way (in part because the question catches the interviewer off-guard, which is generally a good way to get an honest response).

B) The feedback is useful for adapting your presentation and pitch at another firm.

and

C) If you get the job this is _very_ useful information to have. It tells you what your new boss views as important and what skills she thinks you are lacking, often with a candor you won't get if you ask the same question on your first day on the job.

EDIT/PS: I'm trying to think how I'd react to this sitting on the other side of the desk. I've done a lot of interviews but I don't think anyone has ever asked me this question. I certainly give vague non-answers when I'm rejecting a candidate after the fact (typically something like "we've found someone who is a better match...") but if I was asked in the interview I'd probably give an honest answer but it would be focused around the work instead of the candidate, which probably makes it easier to deliver.

</comment></comment><comment><USER18> There are times when I've really, REALLY wanted to be able to give that feedback -- usually when a candidate came in second in a close race and I wanted them to know they did really well, but there's been other times when I thought specific feedback would really help someone (I interview a lot of fresh college graduates) -- but HR has told me every time not to do it, not even if they review the language first.

What's funny is the one time I got such feedback myself I thought it was because the company I interviewed with did it _because_ they were paranoid I would sue: About 12 years ago I interviewed when I was 4+ months visibly pregnant (and I openly talked about it too -- I don't hide anything), and afterward the person I interviewed with sent me an extremely nice note that they liked me at lot, but they had to go with the more qualified candidate, although if she didn't work out, they'd hire me. I blew the letter off as them being paranoid about getting sued, but a few weeks later I got the call -- the other person didn't work out and I was hired. Go figure.

</comment><comment><USER19> I've done a lot of interviews and the reasons are:

1\. They dont want to hurt the interviewees feelings.

2\. They want the interviewee to feel good about the company even if they didnt get the job. (Marketing?)

3\. There might be legal reasons.

But one thing I advise now is to ALWAYS ask for feedback. You can do this by getting an interviewers email during the interview and emailing them after. Something of the form:

\</comment><comment></comment><comment>---

Hi,

Thank you very much for taking the time for interviewing me yesterday. I was notified that I wasnt a fit by HR.

I was wondering if you could let me know: 1\. Which questions I got wrong in the interview and what answers you were looking for? 2\. What areas you feel I need to work on? (ie an open ended question which lets them give you any type of feedback)

Regards,

\</comment><comment></comment><comment>---

Asking for feedback is HARD. But nothing brings out more respect in me than someone who wants to know why they failed and who takes steps to fix those issues in the future.

</comment><comment><USER20> Usually, the number of rejects are much much more than the accepted. Time is a big issue.

Take YC. 1000 apply; 40 get in. How long would it take to individually let the 960 that didn't get it why they couldn't get it?

It's not a perfect system...but I don't see how that would change given that it's about time.

</comment><comment><USER21> From experience searching for jobs in the last year it seems to be exceptionally rare to get any sort of feedback after an interview - constructive or otherwise.

My guess is that this reticence is mainly due to the laws surrounding employment, since it costs practically nothing to send a brief email. If anything which was written as part of a response could be construed as being racist/sexist/etc then in theory the company could face lawsuits. Also in the current economic situation some people might react badly to a negative response, especially if they have made exceptional efforts to get to the stage of having an interview.

</comment><comment><USER22> Another reason is that you get into an arguing match.

Interviewer: "I don't think you have the skills for the job." Interviewee: "Sure I do! Etc."

</comment><comment><USER23> Why would they? There is literally no benefit to interviewers to do so -- they've already rejected you, so improving your performance won't help their company, and it could help their competitor that does hire you. It could cause problems ("would you have considered my interview more impressive if I was race/gender/nationality/height _X_? Time to lawyer up").

</comment><comment><USER24> Interviewers don't give most candidates tangible feedback/criticism because the vast majority do not want it.

People who just bombed an interview usually know it, and aren't in a place to receive constructive feedback.

The rare few who handle that well should explicitly ask for feedback or critique.

I always give this when asked, but never offer it unasked.

</comment><comment><USER25> One time, I got a call from a hiring person at a company telling me that I wasn't selected for a specific job I had wanted. I turned around and asked him why and asked a few feedback questions, and the guy ended up changing his mind and extending me an offer. So at least from my experience, it's always good to ask for feedback on how you did.

</comment><comment><USER26> How valuable would the answer be?

Most interviews come down to how much the interviewers liked you and whether your bearing in the interview matched the company's image of itself. They might come up with a variety of justifications if you pressed them, but it's never going to be the truth: they just liked the other guy more.

<comment><USER27> That is the truth that is often overlooked.

Feedback is not entirely useless, but good managers know that how useful a person ends up being, is not a function of his knowledge at the time of the interview. And that is true even for highly skilled professions like programming.

Performance/productivity is dominated by human factors, psychological factors, office environment, team synergy etc etc.

Even when I do technical interviews, people assume I am interested in getting the right answers out of them. In truth, while I am somewhat interested in what answer they give, I mostly watch _how_ they answer the questions.

</comment></comment><comment><USER28> It's also the point that it's easier and safer for a company to say 'no' to hiring someone than to say yes, especially if there's any doubt what so ever in the candidate's abilities. This is true for the financial and time cost, as well as the resulting lost productivity and chaos created when having to hire, fire, and find a replacement.

Therefore given how "picky" companies have to be in hiring someone, they often have an order of magnitude more people to say no to than yes, and the earlier in the process you go the more orders of magnitude of "no" they have to reply with.

Thus it makes sense for them to only provide feedback if someone requests it explicitly, and because it also shows them that you are still interested and put some extra effort into the process.

</comment><comment><USER29> The real answer might be because very few applicants can take it gracefully.

</comment><comment><USER30> Most interviewers don't have wear poker faces when they're not discussing salary. You can often tell by their response if they liked or disliked your answer.

Most good interviewers also have a list of questions they formulate based on what they think might be your potential weaknesses to assess whether they are a real liability or not.

So in a nutshell, if you pay attention to the verbal and non-verbal cues during the interview, you probably don't need to ask for feedback.

<comment><USER18> This is a good point: although it does depend on the interviewer, I know I personally am _horrible_ at not showing what I think when I'm talking to someone (esp. as I'll usually ask a follow-up question to an answer I don't like, just to make sure they really are saying what I think they're saying). And if someone can't figure it out from there where they got it wrong, maybe they don't have the interpersonal skills we'd want in the first place...

</comment></comment><comment><USER31> Their reasons aside, if you ask, you can usually get it.

<comment><USER8> I usually gave an indirect answer when interviewees asked. For example, when hiring part-time employees, most of whom were current college students, all I really cared about was their ability to show up on time, follow directions, and be familiar with standard business practices. So anyone who showed up late to the interview, wore inappropriate clothing for a business setting, answered cell phones during the interview, etc. was cut. If someone asked why I would usually frame it as "I can't discuss the decision to hire or not hire you specifically, but generally companies look for candidates who show up on time to an interview, dress appropriately, and don't answer phones, etc."

<comment><USER32> Gosh, people must be bad at interviewing...turning up in business attire (no matter the company culture), turning your mobile off and arriving (reasonably) early are fundamentals.

I've never had a problem once getting to the interview stage and have been quite proud that I tend to be seen as valuable, but if thats the competition, I'm less impressed with myself...

<comment><USER18> We once (8 years ago?) had a woman pull a beeper out of her bra in the middle of an interview. And that was not, by far, the weirdest interview.

</comment></comment></comment></comment><comment><USER33> Time, and they don't owe you one.

</comment><comment><USER34> Time.</comment>