Paul Buchheit: blog, v2 - <AUTHOR> http://paulbuchheit.blogspot.com/2008/12/blog-v2.html <comment><USER2> Seriously? This is front page news?

<comment><AUTHOR> As the submitter, I feel an obligation to defend it. I thought the dissection (however brief) of blogging vs. microblogging and what he thinks each is best suited for was interesting. Since he's the founder of a microblogging service, he would be in a position to provide an insightful viewpoint.

<comment><USER3> He's in a position, but did he provided it? Bush is also in the world leader spot, does his own people aprove what he does?

I know, karma-whoring with my anti-Bush comment, but there's a point here. It's like killing your father and fucking your mother for you Freud folks.

"I've decided to blog differently" is not HN material. It's not even _news_, because he gave very personal reasons for it (and I commented there on his blog).

Don't follow the person, follow the whys.

</comment></comment></comment><comment><USER4> I was going to disagree with those negative comments below but then read the blog and damn; this guy has a freaking ego to think people would want to edit his ramblings for him in any other way than comical..

<comment><USER5> I got the impression that part was very much tongue-in-cheek, and he doesn't _actually_ expect other people to edit his blog for him. It's very PB-style deadpan humor.

Though that just goes to show that we need automatic sarcasm detectors on the Internet, along with a <sarcasm> tag. Then you can be lazy and the compiler will infer your jokes for you.

<comment><AUTHOR> I wonder if it was a reference to this: <http://www.avc.com/a_vc/2008/12/the- editor-dill.html></comment></comment></comment>


Teaching Math Without Words - A stunning approach - <AUTHOR> https://www.youtube.com/watch?v=7odhYT8yzUM

<comment><USER2> This is phenomenal. I took a university course in Bifurcation theory and throughout the course, the language used in trying to explain the concepts were the inhibiting factor in understanding what was going on. We benefited greatly from a visual approach. You get to skip over a mental translation medium and swim in the concepts. Thanks for this.

</comment><comment><USER3> I wish they had versions for iOS devices. I had my credit card ready to buy these for my kids.</comment>


Round Peg in a Square Hole [video] - <AUTHOR> https://www.youtube.com/watch?time_continue=2&v=AvFNCNOyZeE <comment><USER2> I love Tadashi Tokieda so much, he's just one of the most delightful human beings I've ever seen. I highly recommend all of his Numberphile videos, and you should also check out his Toy Models lecture [1]. It's so much fun to see him show some weird phenomenon with marbles or magnets or whatever (that should be seemingly simple to explain with mathematics and/or classical physics) and then say "There is no theory for this. We have no idea why this happens. I'm working on it though".

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

<comment><USER3> Tadashi is awesome! I love his video explaining how someone found a prime that looks like the Arms of Trinity Hall [1]. Highly recommend all videos from Numberphile [2] and Fermat's Library [3].

[1][https://www.youtube.com/watch?v=fQQ8IiTWHhg](https://www.youtube.com/watch?v=fQQ8IiTWHhg) [2][https://www.youtube.com/channel/UCoxcjq-8xIDTYp3uz647V5A](https://www.youtube.com/channel/UCoxcjq-8xIDTYp3uz647V5A) [3][https://www.youtube.com/channel/UCSD2RxaYn2Nxkm41gp- eKfA](https://www.youtube.com/channel/UCSD2RxaYn2Nxkm41gp-eKfA)

<comment><USER4> If you aren't convinced rolling downhill is complicated, physicist Walter Lewin has a demonstration involving cylinders, no fluids this time.

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

<comment><USER5> That was incredible. Every combination hypothesized, then experimented with, ending with an intuitive explanation.

<comment><USER6> I'm afraid I have to dissent here.

Compare the footage at 2:10-2:15 with that at 3:20-3:25. He _wants_ the result to be that the box starts sliding at the same angle in both cases, and that's what _should_ happen if what they teach in physics 101 is correct, but that is _not_ actually what happens in the video. In fact, the box starts to slide noticeably earlier in the second case (which is exactly what the off-screen crew members predicted). But he simply glosses over this and says "within one degree the same". What is what _should_ have happened, but is not what actually happened. This is a very unscientific attitude, and I think this does a tremendous amount of damage to the popularization of science, particularly in the face of accusations that science is just another religion with its own dogmas, high-priesthood, etc.

The correct reaction here would have been, "Hm, that's interesting, it started sliding earlier. That's not what I expected, and is not what theory predicts. Let's see if we can figure out why this happened."

It's also kind of lame that we have to rely on his callouts to know what angle the board is at. It would have been trivial to set up a pointer that would have been visible to the camera.

P.S. Yes, I know that he "explains" the discrepancy at 3:40, but his explanation is bogus. First, the discrepancy is much bigger than the "half a degree" that he explains away. And second, his explanation is actually a hypothesis that is easily tested: just run the experiment multiple times. He could easily have done this and again demonstrated how science is actually supposed to work, but he didn't.

P.P.S. He does it again at 7:02 where the longer cylinder is clearly beating the shorter one by nearly a full cylinder radius right before he proclaims "no difference".

<comment><USER7> I understand your complaint, but this isn't a formal proof or a research paper seeking peer review. This is an educational demonstration of physics concepts that have already been very well-established through the much more rigorous methodology and peer review you are asking for. Of course the educational demonstration won't have the same rigor, and it shouldn't be expected to.

<comment><USER8> With respect, I don't think that was his complaint.

The problem is pretending to demonstrate by experiment something that involves abstractions to the real world.

It's the same thing with 'demonstrations' that a heavy object will fall at the same speed as a light object where inevitably its 'close enough,' but not actually true (they do in perfect vacuum, but not in a simple experiment).

This happens a lot in demonstrating science, because science is really messy. And even relatively simple physical phenomena we don't understand fully (a recent topical example is we don't properly understand why curling stones curl the way they do).

The problem is pretending the answer is simpler than it is. Which inevitably leads to motivated 'pseudo-experiments'.

<comment><USER6> > The problem is pretending to demonstrate by experiment something that > involves abstractions to the real world.

Not quite. My complaint is pretending that the result of an experiment was something other than what it clearly was and saying, implicitly, "despite the fact that you could plainly see that the result of this experiment was NOT what I said it would be, you should nonetheless believe what I tell you about the laws of physics because I'm the professor and you are the student and I know what's what and you don't. Pay no attention to the actual outcome of the experiment that you saw with your own eyes and instead trust my authoritah."

> This happens a lot in demonstrating science, because science is really > messy.

That's no excuse here IMO. In this case the demo was simply very poorly designed. It's just not that hard to construct a friction and moment-of- inertia demo that actually shows what it is intended to show.

<comment><USER9> Obviously he is gearing up to demonstrate the significant difference between hollow and solid cylinders. It's the only race out of all that anyone could place a confident bet on the outcome, and this is what matters. Kids learn that weight and size make no difference. Kids would probably call out the differences on the day and then that could be explained and repeated if needed.

<comment><USER10> I think you're glossing over something very important though - which is that he visibly demonstrated that he was wrong. I understand his intention and how he was building up towards the end, but this video makes me question everything he says rather than believe him. He is very much telling us to ignore what we saw with our eyes because it disagrees with his prediction, with very little explanation as to why. He made a prediction, he demonstrated for us that his prediction was wrong, and then he told us he was still right. If that's not an appeal to authority then I don't know what is.

<comment><USER7> I just don't think it's anywhere near as egregious as you make it sound. If he had literally told us to ignore our eyes, yes that would be bad. But he explicitly said that things were close, and that variations in the plank can cause slight differences, and that averaging a few trials would show extremely close results. Sure, you have to "take it on faith," but it's a very reasonable explanation, and by the end of the demonstration (when you see the much larger difference with the hollow cylinders) it becomes clear (or at least extremely easy to believe) that the tiny variations in earlier experiments were indeed the result of "impurities" in the physical medium rather than attempts to conceal inaccuracies in the physics claims being demonstrated.

<comment><USER10> I admittedly could be wrong, but I feel you're approaching this video from the assumption that he is a physics professor and what he says must make sense. I suspect you've already taken physics at some point and this reinforces what you've already learned.

Consider this from the perspective of someone who knows nothing of physics and is skeptical of science and academia. Here is a person that shows us he is wrong, does almost nothing to rectify this (there is a very brief explanation, but why not more demonstrations? Or really, why not just prepare a better demonstration that doesn't have these problems?), and then continues to pontificate as an authority figure.

If his goal is to offer a refresher to people that already know the physics, okay I guess this makes sense, but I sure as hell would've liked a refresher on the equations personally (so I am not the target demographic). If his goal is to teach people that know nothing of physics, he really could've done a lot more to actually teach and explain things.

Getting back to my first paragraph though, I feel like this comment thread might be a great example of humans being humans - everybody is susceptible to confirmation bias (again I could be wrong, but that hypothesis makes the most sense to me). If you didn't already understand the physics and you didn't take him at his word because he is a college professor, honestly his tutorial is unconvincing. He completely ignores the scientific method!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> To me this is not very surprising to me, since in Germany there exists a well- known children's game called "Durch eine Postkarte steigen" ("step through a postcard"), where - as the naming suggests - you have to step through a postcard while you are only allowed to use scissors to cut the postcard in a clever way.

Here a German YouTube video that shows how it is done (you don't have to understand anything that is spoken, since I think the video is quite self- explanatory):

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

<comment><USER12> I think the reason the example in the video is so interesting is that its non- destructive. It only involves bending and the paper and coaster remain intact.

<comment><USER11> > I think the reason the example in the video is so interesting is that its > non-destructive. It only involves bending and the paper and coaster remain > intact.

There is a quadratic hole cut into the quadratic paper (which I would clearly call "destructive"). It is just not shown in the video how the quadratic hole is cut into the quadratic paper.

If this argument does not convince you, here is another one: Also for stepping through a postcard after the hole is cut it is just bending the paper.

<comment><USER13> Ehh. They way you initially cut the paper constraints how you later can fold it. If the square was cut any smaller you wouldn't be able to fit the coaster through no matter how you try to fold the paper. The square and its size is a constant in this problem, using a scissor to make the square bigger after its given to you would be considered destructive. In the postcard problem there is no such constraint as you are allowed to cut in whichever form/size you want.

</comment></comment></comment></comment><comment><USER14> Goes to show how poorly adapted our intuition is in manipulating space across dimensions. Its scary to think about how much ground breaking science is still left uncovered because of this blindspot.

<comment><USER15> The only thing I found surprising about this was that you were expected not to have known how it worked. It's the same sort of thing as trying to move a couch and having to angle it to fit it through a door, it's how 3D space works.

<comment><USER16> I think the equivalent would be a door that is too small now matter what angle the couch is in. The only way to get it through would be to "stretch" the door in 4-d space and collapse it back into 3-d to allow the couch through.

</comment></comment></comment><comment><USER17> If you like the idea of solving problems using extra dimensions, Diaspora [1] takes the idea in some really interesting directions. Just be prepared to fight through a few sections of intense Riemannian geometry to bring you into that world.

[1]: [https://en.wikipedia.org/wiki/Diaspora_(novel)](https://en.wikipedia.org/wiki/Diaspora_\(novel\))

<comment><USER18> This is probably my favorite novel by Greg Egan. Most of its central characters are AIs.

</comment></comment><comment><USER19> Love it. It's stuff like this that got me interested in science. I remember seeing the same thing (larger object through a smaller hole) demonstrated on "How" in the 1970s, which was a TV show with a quirky mixture of science and fun. It was aimed at children, but didn't talk down to them.

Here's a ransom episode for those who remember that show.

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

</comment><comment><USER20> so cool - I also like the term 'ambient 3rd dimension'

<comment><USER21> But let's not hijack a perfectly well understood technical term and give it another meaning. "isomorphism" in the javascript community, I'm looking at you.

<comment><USER22> Programs do well defined things in their space but are sometimes aware of stuff outside their space - eg if another program slows down the machine exposing a timing bug in the first program.

</comment></comment></comment><comment><USER23> Seems obvious to me: you have a square with four sides of length _n_ , and when you fold the paper, the four-sided square with a circumference of _4n_ becomes a slit of length _2n_.

</comment><comment><USER24> You can fit any object at any size through a an arbitrarily small and arbitrarily shaped hole. Just blend it an send it through as a stream with the same cross section as the hole. The naysaers will say that this is cheating because you are changing the shape of the object, but the trick mentioned here is just changing the shape of the hole from a square of one perimeter length into a rectangle with the same perimeter length. Similar yet simpler trick for those who don't have a blendtec ready at hand.

</comment><comment><USER25> Someone posted this in a comment on HN during the week and I subscribed immediately. Soooo wonderful. I'm definitely going to give this a shot with the kids tomorrow. Thanks for reminding me.

</comment><comment><USER26> Didn't think I'd really be that interested in this. Kind of made me excited. Thanks.

</comment><comment><USER27> I think about the analogy of folding spacetime when I see things like this... what could you used to fold a 4d region of spacetime into a fifth dimension to create a "wormhole" and where would it lead? I'm not even sure what this would mean!

</comment><comment><USER28> Never heard of Tadashi Tokieda before so THANKS!

</comment><comment><USER29> Great video, but I think it would have been better without the cartoons. They were distracting and added nothing.

</comment><comment><USER30> I wish HN would loosen up and admit that videos are a new medium, worth taking seriously. It might bother us that longform writing is dying, but when the new generation decides that this is the way new ideas should be communicated, we'll be left with no audience.

For example, I've been working on an essay for some time now, but I'm seriously considering making it into a companion video. I have no video experience whatsoever, so that's a tall order. But what are you to do? If you want to make an impact, are you sure it's still possible to do it by writing 173 essays over 15 years? It used to be, but the world seems to be changing.

(This is mostly a reaction to this post being one of the rare videos Deemed Worthy to be on the front page, when there are tens of thousands of others. It's not a good idea to mix up the content too much, but there really are a lot of quality videos and no central curation mechanism. Unlike articles. /r/videos is for mainstream content, like [https://youtu.be/kJGGlVg5PpY](https://youtu.be/kJGGlVg5PpY). There really isn't any place that collects intellectually gratifying content like the current submission.)

<comment><USER31> I typically don't have the patience for most videos. I want information, and much of the time, the information bandwidth or payoff is too low. I think video can be great auxiliary, supporting material, but there should usually be a textual component when trying to inform.

<comment><USER32> I get around this by watching videos in fast forward

</comment></comment></comment><comment><USER33> Ahhh Easter Egg! Firmware version! Love it!

</comment><comment><USER34> Thought this was going to get clever but... it didn't.</comment>


Ask HN: Why aren't users told when their HN accounts turn 'dead' - <AUTHOR>

If you change your settings to 'show dead' you will find lots of comments from users who are totally unaware that their accounts are now 'dead'.
Dead accounts can still comment, but their comments can not be seen by most users, and cannot be upvoted. Since I started checking a few weeks ago, I've found about 100 people who were happily posting away, wondering why they never received any comments to their comment, or new karma, but happily taking part. Once told these users can usually search back through their comments to one heavily down-voted post that killed their who account.
I understand that users don't register with emails, but surely there could be some way of letting people know their account has been closed (and why), so that they know to modify their behavior.
Many of the dead comments are fine and on topic, and are written by people that want to be (and think they are still part of) the great community HN has here. <comment><USER2> I guess its a way to contain spam accounts. If you start banning those accounts, spambots will simply create new ones.

<comment><AUTHOR> Maybe, but most of the spam seems to be new stories, not comment spam. In fact in the last few weeks I've yet to see a single spam comment (dead or alive).

A few dead comments were trolling, but the vast majority where good, on topic comments. Just seems sad to lose those users.

</comment></comment><comment><USER3> It is pretty easy to notice when your account is hellbanned now as you are also slowbanned and it makes the site virtually unusable (waiting many seconds to minutes for each page to load).

</comment><comment><USER4> Because that's how this type of ban works. See <http://en.wikipedia.org/wiki/Hellbanning>

<comment><AUTHOR> Indeed - it's just when i look back into 'dead' users comments, it's usually one final post (often about PC/Mac or Apple/Android) that 'closes' their account. These aren't persistent trolls usually, or argumentative people - sometimes it's a flippant remark, or an attempt at humor that gets them banned.</comment></comment>


Being Andre the Giant - <AUTHOR> http://www.cbssports.com/general/feature/25122751/being-andre-the-giant <comment><USER2> My favorite article on Andre: [http://www.drunkard.com/issues/10_06/10_06_andre_giant.html](http://www.drunkard.com/issues/10_06/10_06_andre_giant.html)

<comment><USER3> I was only reading this one on Bleacher Report today:

[http://bleacherreport.com/articles/1930105-remembering- andre...](http://bleacherreport.com/articles/1930105-remembering-andre-the- giants-larger-than-life-career-and-complexities)

</comment></comment><comment><USER4> Samuel Beckett used to drive André to school in his pickup truck. He was too big for the school bus.

</comment><comment><USER5> When I was 8 or 9 years old I had dinner with a contemporary of Andre the Giant, Baron von Raschke. He was friends with my best friends dad. He gave me "the claw" (brainclaw). Life as a young boy doesn't get much better (except for blueberry pancakes).</comment>


Experts Increasingly Question Advice Against Widespread Use of Face Masks - <AUTHOR> https://slate.com/news-and-politics/2020/03/experts-question-advice-against-face-mask-use-coronavirus.html <comment><USER2> Honestly it is the same form of reporting similar to how all the "trading experts" go on MSNBC and tell everyone the market is going to be fine to prevent panic selling. In this case they do advise it to prevent people from hoarding all the masks so there will be some left for the medical professionals who need them more.

<comment><AUTHOR> The article didn't mention cloth masks. Not the protection of medical grade masks to be sure, but they do lessen the probability that the wearer will infect others. Which will slow the spread.</comment></comment>


NordVPN app sends trafic to suspicious URLs - <AUTHOR> https://www.theregister.co.uk/2019/04/26/nordvpn_strange_traffic_domains/ <comment><USER2> I don't understand why anyone would trust these VPN services. Its the perfect way to MITM people who has something to hide. The marketing is aggressive and the price is low, so you can't help wonder how they make their money in the end.

<comment><USER3> I know some ISPs do sketchy things, but I don't perceive any particular VPN provider as more trustworthy. Otherwise, I would use one.

<comment><USER2> Dont get me wrong. I'd rather be MiTM by some letter soup agency or one of their contractors than some dodgy hotel owner in Kowloon. But for every day use on your own private connection, I don't see the need for an VPN service (unless you want to circumvent region restrictions)</comment></comment></comment>


Show HN: Flat UI Colors 2 – 280 handpicked colors by 13 designers - <AUTHOR> https://flatuicolors.com <comment><AUTHOR> Hello everyone! I've collaborated with 13 designers from 13 different countries and we came up with 280 matching colors.

Hope the colors work for your quick needs

</comment><comment><USER2> The onboarding screen is infuriating...</comment>


Towards a new entrepreneurship - <AUTHOR> http://www.startuplessonslearned.com/2010/01/towards-new-entrepreneurship.html <comment><AUTHOR> Anyone here planning on being in the 6 month program?

I would have loved to do it, but the monthly trip out to SFO from BOS is problematic.

<comment><USER2> If I were in the Bay, I would definitely audit [http://courses.haas.berkeley.edu/descriptions/Descriptions/M...](http://courses.haas.berkeley.edu/descriptions/Descriptions/MBA295F-1_Spring10.htm)

</comment></comment><comment><USER3> What about us poor people in Europe :(

<comment><USER4> We plan to have simulcast showings & meetups all over Europe. Where are you based? If you're interested in starting or finding a European-based lean startup meetup, you can check here: <http://leanstartup.pbworks.com/Meetups></comment></comment>


Ask HN: How might one transition from commercial software into research? - <AUTHOR>

The first company I worked at during the "dot-com" era, back when we were all worried about Y2K, lol, used genetic algorithms to solve mobile resource management problems - hence I developed an interest in "deep-search" problems, those problems whose solution space is too large to be solved precisely but solutions can be approximated via heuristics. I still have this interest, but have sort of found myself dealing with logistics types of solutions, i.e., working with solutions that "talk to" SAP supply chain solutions, fine, but does not sort of have the theoretical aspect which I have an interest in.
I am proficient with C and Java mostly along with UNIX commands and some auxiliary skills, but really have more interest in cool problems to be solved rather than the latest/greatest web fads like Ruby and so on. My question would be, how does one, having "cut one's teeth" so to speak in commercial software, sort of "transition" to more research. I also have a bit of a side-interest in AI as I have some experience with back-propagation neural networks written in C as a solution to predict energy markets. I think my biggest interest is sort of "big problems" that require heuristics to solve them but since while I think I have a pretty solid resume in terms of work experience, both in the area of mobile research optimization and in logistics, I don't have the academic "cred" (e.g. B.S. degree) to sort of "back that up" so to speak.
Most recently I have come across the concept of functional programming, of mathematical interest to me, so my current idea is to study a bit more about that. I just wondered if anyone in the HN community had any thoughts in terms of how to "transition" from a rather sucessful career in the commercial/enterprise software world towards more getting into the research/theory end of things, without perhaps the letters after my name to back that up, lol. Any thoughts appreciated! :-) <comment><USER2> Apply to CS grad schools. See if you can work with any researchers or professors that will lead to publishable work. Read through their papers so you can see what they are working on and try contact a few people that have the same interests you do. (You mentioned genetic algorithms, neural networks and functional programming.) I've trying to do the same thing at the moment. Contact info is in my profile if you have questions. Good luck!

<comment><USER2> Also check out this old thread: <http://news.ycombinator.com/item?id=2403031></comment></comment>


I love to see how many Apple Macs were at Obama's State of the Union - <AUTHOR> http://blog.whttl.com/2015/01/20/macs-at-the-white-house-state-of-the-union/

<comment><USER2> Product placement?</comment>


Everyday hassles in Go - <AUTHOR> http://crufter.com/2014/12/01/everyday-hassles-in-go/ <comment><USER2> I couldn't agree more with this article.

I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functional language.

I feel like I have been tainted by functional programming, and now Go feel like a joyless programming language which inevitably affect productivity.

I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time. Doesn't need to be good at long running programs, but it would be great if it can evolve to play a repeat role in a large system/process without the hassles of having to duplicate every written line of code into tests to prevent small changes from breaking things.

I am considering giving Haskell a try, but wondering if it might be overkill.

Any suggestions?

<comment><USER3> I think Haskell is a possible alternative to Go/Python/Ruby for these kinds of tasks.

But nothing's perfect. Some possible annoyances you might encounter:

* Much of the functionality required to be a valid "Python alternative" is not on the base packages. You'll have to install extra packages much sooner than with Python. And you'll have to know what packages to install.

* Despite having proper sum types, most I/O libraries in Haskell rely on exceptions for signalling errors. And Haskell has no proper stack traces. If you are not careful, you might find yourself pining for Go's multiple return values.

(Some would add "having to use the IO monad" to the list of annoyances, but I think it actually helps.)

<comment><USER4> I found ocaml to be a more flexible alternative -- I can sprinkle printf for quick debugging without having to alter types. (I think this is what you mean by "having to use the IO monad". I didn't work with haskell much, so it's possible there's an easy way around this there.) And stack traces in ocaml are reasonable, though not quite as verbose as python's.

But your point about needing to install extra packages stands for either language.

<comment><USER5> OCaml is currently my language of choice. I love functional programming, been doing it for a while now, but it's nice to know that if I read an algorithm in a textbook, I can just implement it as-is instead of doing a translation to be purely functional (and sometimes having to fight to get back the asymptotic complexity). The module system is also absolutely great, and should be copied shamelessly by more languages.

<comment><USER6> Haskell doesn't ban imperative programming, it simply distinguishes it in the types.

<comment><USER5> True, what I mean is that I can be "messy" in OCaml for the sake of expediency. In principle, I prefer Haskell's clean approach, in practice I'm a bad programmer who sometimes does naughty things.

<comment><USER6> Well, Haskell does force you to go and update your types about your effects, and fix the use sites to do proper lifting.

I don't feel this costs much, though, so even in quick&dirty mode, I feel that Haskell is quite productive enough.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience :

After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard.

Well, i downloaded the framework, configured maven, started the hello world tutorial, and quickly found myself dealing with 2 xml files, 1 yaml file, multiple classe files ecerywhere, and couldn't get the whole stuff work immediately.

Then i realized that my golang implementation was already working, and that i completely understood my code and its potential performance characteristic, without having to have deep knowledge about the jvm internals, things like sevlet containers, or how the whole stack would deal with my global variables in a multi-threaded context. All my code was just one simple program.

My temporary conclusion right now is that golang type system is indeed extremely shite, but that if what you need is to develop simple yet efficient web services, it doesn't matter that much.

<comment><USER8> I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutting concerns" like authentication or async calls that you'd have to either have built into your framework, or use some kind of "magic" (AOP, monkeypatching) to add to all the methods where they were needed. [https://github.com/spray/spray/tree/release/1.1/examples/spr...](https://github.com/spray/spray/tree/release/1.1/examples/spray- can/simple-http-server/src/main/scala/spray/examples)

<comment><USER9> > use some kind of "magic"

No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window.

You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution?

All of that complexity falls away with golang and this is a conscious choice of the golang team. I have lots of things I love about Scala and lots of things I hate about golang, but from a "get simple web service out the door in a scalable way" golang wins hands down.

<comment><USER8> > No it doesn't use magic, but it does take a language that is burdened with a > complex type system and throws it out the window.

What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it.

> You also are glossing over a huge host of complexity around > build/deployment. What jvm are you targeting? Is it on the servers you are > deploying to? Are you going to make a fat jar? If not, how are you doing > dependency resolution? Is your build artifact something that sbt does out of > the box or slightly different (lord help you if it is)? Are you going to do > ivy, s3, or maven resolution?

If you're just playing around, you push the button in your IDE and it runs. If you're a serious business you make these decisions once and reuse them in every project. (To answer your questions explicitly: the default is to build for java 1.6, which has been on servers since before go even existed; if you're building for a newer version it's because you know what you're doing. My personal choice would be the maven appassembler plugin, but using the shade plugin to make a fat jar works fine too. I wouldn't touch SBT, it's too complex).

Yes, you do have to make some choices, put a bit of effort into deployment. But I think that's a necessary cost, because it's the only way to allow tooling to evolve. Imagine if ant had been built into the JVM back in 2000; maven would never have been able to replace it, so we'd be stuck with it forever. Look at the Python standard library; when Python first got big, it was this great selling point full of really useful tools. Now, it's where modules go to die, because things that are built into the language can't evolve at the same place as things that are outside it. I fear exactly the same thing will happen to the Go tooling (though of course, we won't know one way or the other for ten years). If I can think of one language that really emphasised an "easy deployment model", it's PHP. Not only did that approach lead to terrible deployment practices, but now that the landscape has shifted and Apache is no longer universal the way it once was, it's not even particularly easy to deploy PHP any more.

<comment><USER9> > What are you talking about? Spray works hand-in-glove with the Scala type > system; would, in fact, be impossible in a language without it.

In the example you linked to: [https://github.com/spray/spray/blob/release/1.1/examples/spr...](https://github.com/spray/spray/blob/release/1.1/examples/spray- can/simple-http-server/src/main/scala/spray/examples/DemoService.scala#L19)

The "main" function dispatch is not type safe (nor can it be given Spray's reliance on the current akka type model).

My experience is that anything that relies on akka ends up throwing out a huge majority of useful type safety because it is hard to minimize it. A bunch of the advantages you mention around AOP and not monkey patching are due to this.

<comment><USER8> Ah, my bad. [https://github.com/spray/spray/tree/release/1.1/examples/spr...](https://github.com/spray/spray/tree/release/1.1/examples/spray- routing/on-spray-can/src/main/scala/spray/examples) (or even [https://github.com/spray/spray/blob/release/1.1/examples/spr...](https://github.com/spray/spray/blob/release/1.1/examples/spray- routing/simple-routing-app/src/main/scala/spray/examples/Main.scala) if you want the very simple case) are better examples, that use the lovely type-safe routing DSL.

</comment></comment></comment></comment></comment></comment><comment><USER10> The article author points out, correctly, that Go code has far too much "interface{}" in it. That's an indication of real need for more power in the type system.

Generics may be overkill. Parameterized types may be enough. The difference is that you have to explicitly instantiate a parameterized type. Generic functions and classes get instantiated implicitly when used, which gets complicated. (See C++'s Boost.)

Go already has built-in parameterized types - "map" and "chan". Those are instantiated with "make", as with

        p := make(map[string]int)

That's an instantiation of a parameterized type in Go. Go already has a full parameterized type mechanism. It's just that users can't define new parameterized types - all you get are "chan" and "map".

For parameterized types, struct definitions would need type parameters. A parameterized type would later be instantiated explicitly in a type declaration, with the parameters filled in and a new name given to the generated type. This is more explicit and less automatic than generics. There's no automatic specialization, as in C++.

This is enough that you can write, say, a binary tree library once and use it for multiple purposes. It's not enough to write C++'s Boost. That seems in keeping with the design of Go.

<comment><USER11> That's not really the full story though. The parameterized type isn't just `map[K]V`, it's more than that. The type `K` needs to be hashable, and not all types support that. e.g., slices do not: [http://play.golang.org/p/IKp_I25NW2](http://play.golang.org/p/IKp_I25NW2) It gets more complicated then that too, because composite types can be used for keys, but only if the type does not contain any non-hashable type.

Similarly, if you're going to build a binary tree data structure, then you probably need a way to compare elements. How do you express that constraint?

Standard ML has a similar limitation, which resulted in the presence of an `eqtype`, which is basically a way of saying, "any type T that can be compared for equality." But of course, ML has its modules...

So I'd argue that type parameterization alone doesn't really buy you much. You might say: well, we need bounded polymorphism then. OK. How do you define bounds? Maybe you figure out a way to abuse interfaces (but a bound isn't a type while an interface _is_ a type), or you add a new way of specifying interfaces to the language.

The road to generics is long, complex and fraught with trade offs. Blessing a few key parametric types is a really interesting compromise, and I believe it's one that was absent in a similar practical manner in pre-generics Java and C++.

<comment><USER10> True. A useful question to ask is this: what's the minimal parametric type design that would allow writing "map" and "chan" within Go? (Ignoring, of course, that "map" and "chan" both have special syntax; map has a "[]" operator, and "chan" has "select')

If we needed to write, say, "thread-safe map", or "network chan", with type parameterization, that should be possible.

</comment></comment></comment><comment><USER12> "Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" \-- Me

I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution.

That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's need not what they ask for. That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go. Worse yet it may calcify the Go development team in a way that will keep them from addressing the basic issues that generics might help solve. Either way Go is just another computer language and I'm happy to use it often to solve problems I'm working on. That said I use a lot of computer languages every week when I'm working on stuff, none of them are perfect and my solutions to the underlying problems are fragile and constantly evolving as the problems unfold. This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1.

"One Computer Language to bring them all and in the darkness bind them".. LOL

<comment><USER13> Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others.

There is scope for legitimate criticism of language design based on the expressive power^1 of their features.

In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it.

1\. [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656)

<comment><USER14> You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature.

When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.

</comment></comment></comment><comment><USER15> This article has some good points but I'm going straight for the first one: I don't miss generics.

Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go.

Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much.

I didn't miss them when I developed Mergo [1], a simple library to merge structs. I think we all agree if we should rewrite this in Java (or other language with similar type system) we would use generics at some point.

[0] [https://github.com/imdario?tab=repositories](https://github.com/imdario?tab=repositories)

[1] [https://github.com/imdario/mergo](https://github.com/imdario/mergo)

<comment><AUTHOR> Did you miss it when you were working on larger codebases? The library you mentioned clocks at 500 LOC, and while the LOC metric is pretty inaccurate, it takes a lot more time to really miss language features.

<comment><USER15> No. I didn't. I have around 2K public LOC in several projects (I can't check now my private projects, I guess I had typed more than that) but I would trust better NateDad's experience.

I have two years of sustained Go usage (since end of 2012) and never missed them.

</comment></comment></comment><comment><USER16> The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this.

The rest is mostly a Haskell fanboy whining that Go isn't Haskell.

<comment><USER17> Best joke in the industry:

"Code reuse!"

Cracks me up every time. ;-)

We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

<comment><USER18> Like c's 'libc', or C++ boost, or pythons 'requests', or...

Lots of code reuse there that depends on generics.

<comment><USER17> Yes, libraries get used. That's their point. My point was, that very little of application code ever gets reused, although we somehow always think it will.

<comment><USER18> And most people are asking for generics to write libraries which don't rely on unblocking interfaces.

Even in the process of writing a single program, there are a number of times where you reuse certain bits of logic, and having generics makes it easier to refactor those into a single function, instead of duplicate code with multiple types (or overly generic types).

</comment></comment></comment></comment></comment><comment><USER19> Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by the language compiler into a native code could improve matching, parsing and validating consistency, instead of writing lots of loops everywhere. Compiler warnings instead of errors on unused variables, imports, etc. to allow faster prototyping. Better testing culture with meaningful test names and line numbers with actual failed tests. Table testing suggested by Golang team doesn't even support that with the means of standard library, you have to use your own runtime.Caller(1) wrapper.

But generics? "Safer" type system? No, that's unnecessary complexity. As others pointed out, we already have Haskell and Rust for all those things.

<comment><USER17> You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful.

For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you.

Maybe you should take a look at Lua and especially LuaJIT [1]. You might like it. Lua(JIT) is single threaded, but provides co-routines [2] as a language construct. Performance is about same as Golang, sometimes faster, sometimes a bit slower. Lua has GC, but you can control latency by controlled GC invocations. It can be made pretty predictable, a lot of current AAA games use Lua internally.

LuaJIT's FFI [3] is excellent, calling native C libraries is a breeze, very easy and requires no bridge libraries or code.

[1]: [http://luajit.org/](http://luajit.org/)

[2]: [http://www.lua.org/pil/9.1.html](http://www.lua.org/pil/9.1.html)

[3]: [http://luajit.org/ext_ffi.html](http://luajit.org/ext_ffi.html)

<comment><USER19> Refcounting and a single threaded runtime, instead of GC and a multithreaded one.

By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.

<comment><USER20> Go would need to be completely rearchitected in order to move to a single- threaded runtime.

<comment><USER15> As far as I know, it should be enough with runtime.GOMAXPROCS(1) to run as single-threaded.

<comment><USER21> No, the runtime will still create new threads whenever you call a C function or syscall.

</comment></comment></comment></comment></comment></comment><comment><USER22> If the author reads this, I think he's confusing "quiet" and "quite".

</comment><comment><USER23> _> For those who are bothered about the exponential algorithmic complexity of nub_

There is nothing exponential about nub. Given only equality comparisons, detecting and eliminating duplicate elements requires quadratic running time.

<comment><AUTHOR> You are right! Others noted that mistake as well.

</comment></comment><comment><USER24> Wanted to say, you can potentially do better than this in go for arbitrary JSON:

type JSON map[string]interface{}

Go ahead and use the json.RawMessage type instead:

[http://golang.org/pkg/encoding/json/#RawMessage](http://golang.org/pkg/encoding/json/#RawMessage)

Not even going to wade into the lack of generics war, still very happy without them and going on a full year of Go usage.

<comment><USER25> Yeah, I almost never use map[string]interface{} when unmarshalling JSON. Most JSON has a static structure (and I'd argue that any JSON that doesn't is misbehaving). If the structure is static, you can simply use a struct that represents this[0].

If it doesn't, then you just use json.RawMessage to defer unmarshalling, but you can still dispatch to a finite number of structs that represent the universe of possible responses.

[0] And no need to write it all out by hand - if you have a single example JSON response, you can generate it automatically: [https://github.com/ChimeraCoder/gojson](https://github.com/ChimeraCoder/gojson)

</comment></comment><comment><USER26> Every time I read an article criticizing Go I end up appreciating it even more.

Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax.

Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug...

Maybe it's because of the bogus examples they give like criticizing

> file, _ = os.Open("file.txt")

> file.Chmod(777)

for not handling explicitly a possible error when it's just because the example is ill written and the proper code is

> file, err = os.Open("file.txt")

> if err != nil {

> ... handle error ...

And here I stopped reading the article, it's always the same arguments over and over: more elegant and complex code vs. the un(cool) but oh my, so much simpler Go code.

What I find really amusing though it's how people are so smug in their writing, pointing out the "obvious errors" (billion dollar mistakes!) that the Go authors made and their "ignorance" of proven modern programming language constructs they could implement in Go.

There are two possibilities here, pick your preferred one.

1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude

2) These bloggers claiming obvious errors in Go design don't really fully understand the trade-offs involved in what they ask for and ignore the fact that the Go authors have carefully thought about them and optimized accordingly

I will go back to programming in Go, I'd take writing for loops all the time vs. writing a one liner in Haskell and then agonize over using the lazy or strict version of it :)

<comment><USER9> I think there is a third option that you are ignoring. Pike, Thompson & Co. are designing for a different problem set than the blog authors.

Golang seems to shine at very simple, concurrent tasks that can be passed from one set of developers to another regardless of sophistication levels of those teams. It seems to fail pretty miserably at making a single sophisticated developer vastly more productive. It's what Java would have been if they'd thrown away the write once/run anywhere goal and never gone down the J2EE box canyon.

There is nothing wrong with either goal btw, they just are in some ways opposites.

</comment></comment><comment><USER27> One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use.

The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are annoying at first, but then you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _).

It's a different approach and it's refreshing.

<comment><USER28> Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".

<comment><USER29> Rather, I don't like to copy-paste and slightly modify simple loops over and over again. Abstraction is a basic tool of programming; where has it gone?

<comment><USER28> They're simple loops. You don't need to copy and paste, you just write them out because it's just ridiculously simple logic. Just like you don't copy and paste if statements.

<comment><USER30> All loops encode simple logic? I don't think that's true.

Either way, a very good reason for not using loops is to make code more readable. If I see a loop I have to run it inside my head to figure out what the intent is, and if there's multiple things going on, that can take time. If I see a 'map' I think "right, this is tranforming every element in this list in this way"; if I see a filter, I think "right, this is removing elements in this list that don't satisfy this property", if I see a groupBy, I think "right, this is grouping elements in this list by this property", etc., etc.

Code isn't only more succinct, it's more human friendly.

<comment><USER31> Expanding a map to a for loop is very simple. Yes it removes a shortcut available when writing code, but when reading code I can consume that simple chunk of logic in one mental bite just as easily as I can a call to map.

<comment><USER30> Sure ... but if a loop is effectively doing a map, a filter, and a bunch of other operations all at once? It's a lot quicker to figure out what's going on if it's been written with combinators (once you're familiar with them) than if it's the vanilla loop.

<comment><USER32> It can be a lot less performant to chain several combinators.

<comment><USER30> If we assume the operations we're talking about take time linear in proportion to the list, you've just gone from a * n time to b * n time, where b > a. Both of these are still O(n) in Big O notation, which drops constants, because constants unless they're very large or n is extremely large, tend to have relatively little effect on the running time of an algorithm.

Choosing to write more verbose, difficult to decipher, difficult to maintain code, under the claim that it will perform better, is not a good thing: "premature optimisation is the root of all evil".

In practice, if this becomes an issue (which you find out through benchmarking once you know there is a perf issue), most modern languages offer an easy way to swap out your data-structure for a lazily evaluated one, which would then perform the operations in one pass. Languages like Haskell or Clojure are lazy to begin with, so do this by default.

<comment><USER32> My comment was carefully worded in order to denote that it is not true in all cases.

Your Big O analysis is correct. However, in a real-world case the list could be an iterator over a log file on disk. Then you really don't want to use chained combinators, repeatedly returning to the disk and iterating over gigabytes of data on a spinning plate.

And yeah, you could benchmark to figure that out, or you could use the right tool for the job in the first place.

<comment><USER30> Or you could use a library explicitly designed with these considerations in mind, that offers the same powerful, familiar combinators, with resource safety and speed. e.g.,

Machines in Haskell: [https://hackage.haskell.org/package/machines](https://hackage.haskell.org/package/machines)

Scalaz Stream in Scala: [https://github.com/scalaz/scalaz- stream](https://github.com/scalaz/scalaz-stream)

I've no doubt an equivalent exists for Clojure, too, although I'm not familiar enough with the language to point you in the right direction.

One of the most amazing things about writing the IO parts of your program using libraries like these is how easy they become to test. You don't have to do any dependency injection nonsense, as your combinators work the same regardless of whether they're actually connected to a network socket, a file, or whether they're just consuming a data structure you've constructed in your program. So writing unit tests is basically the same as testing any pure function - you just feed a fixture in and test that what comes out is what you expect.

I found this really useful when writing a football goal push notifications service for a newspaper I work for. I realised that what the service was essentially doing was consuming an event stream from one service, converting it into a different kind of stream, and then sinking it into our service that actually sent the notification to APNS & Google. The program and its tests ended up being much more succinct than what I would normally write, and the whole thing was fun, and took hardly any time.

I would say that is the right tool for the job.

<comment><USER32> In many cases, YAGNI.

This started as a conversation about for loops vs. chained combinators and wound up with specialized libraries for IO. You're not wrong, but that's a lot more work than a for loop to parse a log file efficiently.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python.

The tradeoff in these designs are to prevent tuple types, always keep using structs, prevent using algebraic types over structs. Allow for nil, but try prevent common Null errors etc.

Haskall is theoretical a much better language. But Golang was designed to be practical & simple over being mathematically sound, and theoretical better.

<comment><USER30> I dislike it when people say languages are either 'practical' or 'well designed'. As if a language is only useful if it's not built on sound mathematical ideas ...

Generics are not a particularly new idea and nobody who uses language that implement them yearn for the days when they weren't around.

See Paul's post on the idea that 'worse is better': [http://pchiusano.github.io/2014-10-13/worseisworse.html](http://pchiusano.github.io/2014-10-13/worseisworse.html)

<comment><USER34> The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing.

You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality".

EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of 'worse is better', C is.

<comment><USER30> Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect.

I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and they don't have any issue with it. What it comes down to is whether the people you work with will understand or want to invest the amount of time required to learn those abstractions. If you're working with very talented programmers, that might be yes. With the majority of programmers it is probably no.

But we're not talking about the I/O Monad. We're talking about generics, which are not difficult to understand, and that Go lacks them is a shame, as it means that whole layers of abstraction are not available to the programmer, so they end up having to spend more time writing boilerplate.

<comment><USER34> So he invested time in building up his straw-man before tearing it down?

The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?

<comment><USER30> Not that it particularly matters whether we're talking about C++, as it's rather tangential, the original essay by Richard P. Gabriel that coined the term "Worse is Better" talks about C++ ([http://www.jwz.org/doc/worse-is- better.html](http://www.jwz.org/doc/worse-is-better.html)):

      The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

In his later essay on the same topic ([http://dreamsongs.com/Files/IsWorseReallyBetter.pdf](http://dreamsongs.com/Files/IsWorseReallyBetter.pdf)) he again talks about C++:

       In the computer world, the example of interest to JOOP readers is C++. Many would concede that languages like Smalltalk, Eiffel, and CLOS are vastly "better" in some sense than C++, but, because of its worse-is-better characteristics, the fortunes of object-oriented programming probably lie with C++.

Simplicity is more often simplicity of implementation than interface. Anyone who's worked with the C standard library knows that it's anything but simple. There's a lot of incidental complexity that is due to design inconsistencies. The complex parts of a language like Haskell are the bits where the ideas themselves are complicated, but the power you get for overcoming that initial learning curve is very great.

</comment></comment></comment></comment></comment></comment><comment><USER28> "Why Go is not Haskell"

<comment><AUTHOR> Author here. I think that is a very valid point. However, a lot of features I mentioned are present in other imperative languages, like Rust. The Go authors however picked other solutions I consider inferior, hence the article.

<comment><USER28> It seems like Rust is what Go would become of you added all the Haskell-ness to it. Which is fine, but we already have Rust. So... Maybe we should be asking what Rust is missing from Go? Or if Rust is good enough, just use that.

<comment><USER8> Rust is missing garbage collection (which is by design, but IMO manual memory management is the wrong hair shirt to wear), and maturity.

What I want is OCaml without people complaining about concurrency (which I suspect is mostly FUD - how many people who choose go "for performance" actually profile their programs? I get the sense there is this group of people who think any high-level language is inherently as slow as Python). Or Haskell without laziness (maybe Idris will eventually become this?), and perhaps with a lower-friction approach to I/O. Or Scala with native compilation (again I think complaints about this are probably mostly FUD, but if nothing else the JVM startup latency is real). Or any of these three getting the hype that Go gets, tbh.

<comment><USER34> So, uh, what are you actually after? Just use Scala if that's what you want. If you can't be bothered to manage memory in rust, then it seems hard to believe that native compilation makes a difference for you.

Is it all just about the hype? Write code, ship products.

<comment><USER8> As I said, the JVM startup latency is a real issue. I'd like to be able to write little command-line utilities in Scala (or a Scala-like language) and not have to wait a second when I run them.

But yeah, I'm writing and shipping in Scala, and life is good, I shouldn't care about people hyping what I don't like.

</comment></comment></comment></comment></comment></comment><comment><USER35> "When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason."

</comment><comment><USER8> Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code.

        Map String Any

Is that a function call? A type declaration? What's a parameter to what? The go style

        map[string]interface{}

is, much as I love to hate on all things go, much clearer.

<comment><USER36> > Is that a function call, A type declaration?

If its following a "::" then its part of a type signature and its a type constructor application. Otherwise, its part of an expression and its a regular function call.

BTW, Haskell capitalization is significant in Haskell. Identifiers starting with lower case are always regular functions. Types and type constructors always start with upper case.

> What's a parameter to what?

Application in Haskell is left associative so its

        ((Map String) Any)

Haskell is a functional language and programs are filled with function applications so using spaces for function application avoids a lot or syntactic noise. The only time I find this really bites me is that, due to automatic currying, passing the wrong number of arguments to a function can lead to hairy type errors. This is not a big deal if you use add a healthy amount of type annotations to your code though.

<comment><USER37>
      Application in Haskell is left associative so its

      ((Map String) Any)

You seem to have stumbled on the exact conflict. Anybody who's seen the theory of lambda calculus will recognize the significance of what you've written, and how it applies to partial binding of functions.

Anybody who hasn't will either be thinking of lisp or just be totally confused.

This is where the conflict is. Many developers actually know some programming theory and find Go woefully insufficient for anybody calling himself a programmer. And the ones that just fiddle around with things and make barely working programs without really knowing what they're doing are very happy that they don't have to know this in Go.

What's really going on is that people with real programming background find that Go forces them to think at the lowest possible level of abstraction, with no way up. And people without any programming background say "that's GREAT !".

<comment><USER38> I'd find it depressing if there was any programmer out there who had trouble understanding the concept of "left associativity". I think I learned it in high school.

<comment><USER6> He's talking about the concept of currying, not left-associativity.

<comment><USER38> Original question:

> _What 's a parameter to what?_

Answer:

> _Application in Haskell is left associative so its_

> _((Map String) Any)_

Which looks crystal clear to me. This is also the part of the answer that user _waps_ later quoted.

</comment></comment></comment></comment></comment></comment><comment><USER36> The article mentions many uses of generics but it doesn't go over one of my favorites, which is that parametricity gives you "theorems for free".

For example, I recently wrote a compiler in Ocaml for a scripting language. The type I used for the syntax tree has lots of type parametsrs:

        type ('id, 'str, 'enum) stmtf =
            (* big ADT definition goes here... *)

The 'id type parameter is the type of identifiers (names), 'str is for strings (they get interpolated) and 'enum is for constants.

These type parameters give me some flexibility. When the parser builds the first syntax tree everything is still a string:

        type syntaxtree = (string, string, string) stmtf

and after a pass to bind names the strings get converted to more informative types:

        type boundtree = (nameId, interpolation, string) stmtf

Up to now, we could get this flexibility by being untyped and defining all these fields in stmtf as "void pointer" or "interface". But the generics lets us make everything type safe. Central to this is the "functor map" over stmtf:

        val map_sstmtf:
            id: ('i1 -> 'i2) ->
            str: ('s1 -> 's2) ->
            enum: ('e1 -> 'e2) ->
            ('i1, 's1, 'e1) sstmtf ->
            ('i2, 's2, 'e2) sstmtf

It takes 3 functions telling what to do to the id, str and enum fields, respectively and converts the stmtf by applying those fucntions to each field. The neat thing is that in the implementation of map_stmtf if we forget to apply apply one of these callbacks to one of the fields the code would not typeckeck. The code also won't typecheck if we apply a callback to the wrong field - say apply the "id" callback to a "str" field. This lets us catch at compile time bugs that wouldn't even have been caught at runtime because in the initial syntaxtree both "id" and "str" fields are represented by "string" and are thus prone to being confused with one another. Both of these turned out to be pretty useful as I evolved my language and changed the structure of my syntax tree.

Liberal use of type parameters also gave many other benefits. For example it was trivial to modify the tree to add a line number next to all identifiers, all I had to do was update the type definition and then see the compilation errors to find the parts of my code that had to be updated.

        type syntaxtree = ((position * string), string, string) stmtf

Finally, one extremely neat trick is that you can use type parameters in some places where you would have used recursive types. This pattern is described pretty well in this post I'm linking to and its the sort of thing that you can't really do without generics.

[http://lambda-the-ultimate.org/node/4170#comment-63836](http://lambda-the- ultimate.org/node/4170#comment-63836)

</comment><comment><USER39> Ok, we all know the problem, but do you have a solution? Have you considered the researches done by others, for example this one: [http://research.swtch.com/generic](http://research.swtch.com/generic)

<comment><USER40> Yes, and Go apologists would also know at least one solution if wouldn't keep pretending that they can't keep reading the post until the very _first_ comment on the same page.

<comment><USER39> What I had in mind was that Go is an open source project, if C#'s solution is a good one, why not write up a proposal and try an implementation?

<comment><USER40> Why am I supposed to do that?

A) I'm using a working language already. B) Read the comments on the mailing list regarding third party proposals/implementations from the Go authors.

In short: Complete waste of time.

</comment></comment></comment></comment><comment><USER41> Looks like someone else discovered Go isn't as good as Haskell to program in Haskell. It's a good, very pedagogical article, however.

</comment><comment><USER42> I _really_ like Go but have always missed generics. Wondering if some kind soul would fork Go, add generics and see how that fares.

</comment><comment><USER43> How can sort be considered generic. Every type must be sorted by different stuff, the compiler can't possibly know what that stuff is.

I see what the author is coming from but generics would break what makes go great.

There has been times when I wanted generics, but it has generally meant that i was looking at the wrong side of the problem.

<comment><USER8> > How can sort be considered generic. Every type must be sorted by different > stuff, the compiler can't possibly know what that stuff is.

What. Have you even used a language with generics? Yes it can, very easily; you can do it in a traditional-OO way by having a sortable interface, or if you want to be really cool you do it with a typeclass.

</comment></comment><comment><USER44> golang is a great language for devops to automate infrastructure tasks, but for application dev not so much

<comment><USER28> Have you used it in a real application? Is actually quite good.

</comment></comment><comment><USER45> I loved VB6 so i like go really much...

</comment><comment><USER46> This really seems like a guy who doesn't want what Go has to offer. At every place he compares Go and Haskell, he wants Go to be like Haskell.

There's already a language like that - Haskell.

</comment><comment><USER47> Statically typed languages impose unnatural hardware-oriented constraints on your business logic - It forces you to spend extra time and effort to make sure that your logic is in a format which the compiler can understand.

Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the productivity loss incurred from constantly trying to 'please the compiler'.

Dynamically typed languages offer fluidity in your logic where it is needed. For example, if you add an integer and a decimal (floating point) number together, there is nothing wrong about this mathematically, but a static compiler will complain! It's a limitation of the compiler not the programmer!

Statically typed languages force you to implement rigid class/type schemas within your logic (sometimes with complex hierarchies) - These schemas have to be significantly reworked whenever your business requirements change.

<comment><USER20> Have you never used a statically-typed language? Most statically typed languages can handle adding an integer and a float together. The only one I can think of that isn't capable of that is OCaml, though this is probably a strength of OCaml rather than a weakness (int-to-float casting can be a common source of bugs if it happens unexpectedly).

<comment><USER47> Try to add an int and a float32 using 'Try go' on [http://glolang.org](http://glolang.org) \- I get this error:

prog.go:13: invalid operation: x + y (mismatched types int and float32) [process exited with non-zero status]

I'd have to cast one of the variables to get it to work. Casting is unnatural - Maybe it's not so bad in this case, but in many cases it isn't desirable.</comment></comment></comment>


So, I have this brain tumor (2009) - <AUTHOR> https://medium.com/this-happened-to-me/f32c54c64e42

<comment><USER2> Fascinating story, but "Originally written in 2009 as a note to friends on Facebook."

Updates?

<comment><USER3> There's an update at the bottom, but even that is not up to date. He was facing a second surgery.

</comment></comment><comment><USER4> Did he die? Is that why there's no update?</comment>


What History Gives, the Sea Steals - <AUTHOR> http://www.hakaimagazine.com/article-long/what-history-gives-sea-steals <comment><USER2> _We have fed our sea for a thousand years_

 _And she calls us, still unfed,_

 _Though there 's never a wave of all her waves_

 _But marks our English dead:_

 _We have strawed our best to the weed 's unrest,_

 _To the shark and the sheering gull._

 _If blood be the price of admiralty,_

 _Lord God, we ha ' paid in full!_

</comment><comment><USER3> Long story short, Climate Change exposes some sites only to turn around and wash them away later. And many coastal sites that were known are now threatened as well.</comment>


Quantum chip breakthrough to be unveiled [FT Paywall] - <AUTHOR> http://www.ft.com/cms/s/0/1410dc2c-f383-11e1-b3a2-00144feabdc0.html?ftcamp=published_links%2Frss%2Fworld_uk%2Ffeed%2F%2Fproduct

<comment><USER2> For those who don't want to subscribe...

[http://www.itpro.co.uk/642613/scientists-to-announce- quantum...](http://www.itpro.co.uk/642613/scientists-to-announce-quantum-chip- technology-breakthrough)

</comment><comment><USER3> What are the implications of this for RSA? How powerful must a quantum chip be in order to factorise (i.e. break) the current encryption schemes?</comment>


Ask HN: As a developer, how can I revive engineering culture in my team? - <AUTHOR> Long story short: due to a period of turmoil in my company, many great engineers have resigned and those who are left - are still frustrated and somehow depressed.
The company is getting back to a stable state but the "engineering culture" is gone: nobody talks about interesting problems and solutions, nobody shares knowledge nor tries to improve things around, etc.
It's just a pick-up-and-finish-the-ticket state now and I would really like to change it from inside as a developer.
Have you ever experienced something like that in your career? What did work for your team/company to get the culture back? <comment><USER2> How much of the turmoil was caused by forces outside the engineering team? More importantly, _are they still there_?

If they are, you're screwed.</comment>


Ask HN: Examples of sites with 'customer class' freemium? - <AUTHOR>

Any examples of sites that require registration or upgrading to a premium version for business use?  Chris Anderson mentioned 'customer class' as a freemium model, would like to see examples.  Main difficulty is obviously enforcement. <comment><USER2> <http://amcharts.com/> is one example I can think of. You can use it for free if you don't mind "charts by amcharts" in the corner. This makes it possible for free personal use, as well as the ability to try it for free, but if you want to use it on your business site or software, most would surely pay the fee.

</comment><comment><USER3> At <http://xp-dev.com> there's no SSL on the free accounts - those users who want tougher security of their code transmitting over the wire do have to upgrade. (disclaimer: I own and run xp-dev.com)

</comment><comment><USER4> I've seen several. Search for "Personal Use only" maybe? Those are generally the terms I see when I see the licensing model on a shopping cart. I don't know of any offhand but that's probably where I would start.

</comment><comment><USER5> Most of the "backup services" (jungledisk, mozy, etc.) do either free or really cheap "personal" backup, but have expensive "business" plans.

RubyMine is free for "Open Source".</comment>


What are the possible economic effects of COVID-19 on the world economy? - <AUTHOR> https://www.brookings.edu/blog/up-front/2020/03/06/what-are-the-possible-economic-effects-of-covid-19-on-the-world-economy-warwick-mckibbins-scenarios/ <comment><AUTHOR> From the interview:

> Q: You have seven scenarios for the COVID-19 virus. In the first three, the > virus is contained to China; in the most extreme, a mild pandemic recurs > each year for the foreseeable future. Let's focus on your fourth scenario. > Describe that.

> A: In scenario four, we assume that COVID-19 eventually affects all > countries, but this pandemic is a one-time event and its severity is low. > For China, we assume a 10% attack rate (10% of all people fall ill) and a 2% > case fatality rate (2% of those who are ill subsequently die). We then use > an Index of Vulnerability for each country, basically calibrating how much > it is like or different from China, to estimate the effects of the virus in > other countries. These assumptions are fed into the model to determine the > severity of the outbreak in each country.

…

> The loss of real GDP, relative to what would have been the model prediction > in 2020 without the virus, is approximately $US2.3 trillion for the world, > which is 2% lower than the baseline. Of that, the US economy loses $US420 > billion in 2020, or about 2% less than the pre-virus baseline. Of course, if > the virus spreads more widely or turns out to be more severe, the costs > would be larger.

Full paper (open access): [https://cama.crawford.anu.edu.au/publication/cama- working-pa...](https://cama.crawford.anu.edu.au/publication/cama-working- paper-series/16221/global-macroeconomic-impacts-covid-19-seven-scenarios)</comment>


Ask HN: Best language to learn for a Harvard MBA to prototype his own sites? - <AUTHOR> Yeah I know I'm an mba - go ahead and flame me guys. I don't see a lot of love for my type on here :(. I'm a serial entrepreneur. I've raised lots of venture capital. I'd love to actually build some of my own prototypes instead of hiring a developer, for a change. I haven't programmed in 25 years. I was pretty good at Pascal, back in the day :). Recommendations? I'm looking to build a working site. No mobile app to start. Just a good ol' fashioned website with simple functionality to test some ideas. I'd love to learn a language where I can become productive quickly, but which is still powerful for building a real site. Also something in a mainstream language in case I hand it off to a professional developer, at some point. Thanks, you hackers you. I love you guys, even though I'm not sure you love me back. <comment><USER3> If you want a quick deployment without much hassle, I don't think you can get much easier than PHP with a framework.

Laravel ([http://laravel.com/](http://laravel.com/)) if you want to pick up best practices (yes, there are best practices in PHP) and mess around with MVC and such, or Slim Framework ([http://www.slimframework.com/](http://www.slimframework.com/)) if you want little more than the bare essentials. In both cases, I would recommend using Twig for templates. None of this is particularly controversial, though, but in my opinion the only faster way to get a site up is wordpress, but on the programming side, that's a lot messier to work with.

Of course, the people who will recommend Ruby and Python and whatnot are right too - you can get a reasonable set of frameworks and deployment strategies in various languages. But the case for PHP is, essentially, lack of overhead and low cost deployment. If you can stand an ugly looking weakly typed ad-hoc language, that is.

<comment><USER4> Speaking as a semi-programmer and serial entrepreneur rather than a full- fledged programming ninja, I'd agree.

Ruby on Rails is sexy as hell, Node + Javascript is very nice, but for practical, workmanlike, somewhat-ugly-but-does-the-job prototyping, PHP is the way to go, IMO.

It has the additional, significant advantage that there are far, far more tutorials and general Google answers for PHP than any other language - certainly than newer approaches like Node.

<comment><AUTHOR> Appreciate the input, thx!

</comment></comment></comment><comment><USER5> Would you like to try JavaScript? It can be used both on the client - <USER2> it's the king since the Web was born - and on the server side, using technologies like Node.js

You'd get to learn just one language this way. Besides, JavaScript has a relatively easy learning curve.

<comment><USER6> Yep... I'd have to second this. + PHP.

There's a ton of tools and frameworks and very large userbase. So you can get help.

Or you could use Delphi...

<comment><AUTHOR> thx!

</comment></comment></comment><comment><USER7> Balsamiq for the actual prototyping - [http://balsamiq.com/](http://balsamiq.com/)

You can export from Balsamiq to HTML. See "Exporting your Mockups to Code" \- [http://support.balsamiq.com/customer/portal/articles/135659-...](http://support.balsamiq.com/customer/portal/articles/135659-extensions)

<comment><AUTHOR> thx cliffwarden!

</comment></comment><comment><USER8> 2 suggestions:

1) rails + Heroku. Rails for the community and plethora of pre-built wheels, and Heroku for the absolute brain dead deployment of your creations. (you'll need to learn like 4 git commands)

2) I'll prototype your ideas in any language you want if you give me access to your network. Deal?

<comment><AUTHOR> Thanks for the suggestions! I'll email you, b/c that sounds like a really good deal. Happy to help...:).

</comment></comment><comment><USER9> For productivity, ease of use, and general sanity, I'd recommend Meteor. It has an incredible amount of in-the-box functionality, which is perfect for prototypes as you say.

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

<comment><AUTHOR> thx!

</comment></comment><comment><USER10> If you are thinking long term development, I would suggest modern Javascript Technologies like NodeJS + AngularJS/BackboneJS but if this is few projects things, then go with PHP, you will do everything with PHP+HTML ! Sky is your limit.

<comment><AUTHOR> Thx! Sounds like php is the consensus in the comments.

</comment></comment><comment><USER11> Ruby + Sinatra. This doesn't prevent you from having to create the html and css for the webpages themselves, but sinatra is a dead simple server framework for serving up webpages.

<comment><AUTHOR> Thx adam419!

</comment></comment><comment><USER12> There was some book about building sites/businesses without coding. There's also drupal which can do quite a lot without coding.</comment>


Ask HN: Current technologies for web development both front end and back end - <AUTHOR> Hey HN,
What are the current technologies used to design front end and backend in production scale? <comment><USER2> There are lots of solid choices, and as always it depends on what your problem is. If you want to have an easy time hiring, go with something popular like React, TypeScript, Python.

If you're willing to choose some excellent languages that are not going to be easy to hire for, I highly recommend [http://elm-lang.org](http://elm- lang.org) for frontend, and [https://www.haskell.org](https://www.haskell.org) for backend. Both of these scale incredibly well.</comment>


I owe Etrade $106k, ouch - <AUTHOR> https://www.gofundme.com/jwctrek <comment><USER2> GoFundMe has, in my head, turned into a beggars corner.

I have a friend on Facebook who created a "legal fund" to help her friend who needs $7,500 for legal counsel for her first felony 5th-degree possession charge. I thought it was for weed or something, so I didn't think too much of it, and I said that her friend will likely get 2 years probation/stay + random drug testing, and then it will be dropped.

Then I learned it wasn't weed. Heroin.

I stopped feeling so bad.

<comment><USER3> Sounds like the statists really got inside your head. Why shouldn't your friend's friend be allowed to voluntarily put anything inside her body that she wants to.

>libertarian feels

</comment></comment><comment><USER4> As someone who doesn't really understand day trading or much about the stock market in general, could someone explain in plain English what is going on here? Why would E-trade even allow one of their customers to "go into debt" to them like this?

<comment><AUTHOR> Also Etrade will collect interest on the margin debt.

<comment><USER5> Over the course of a day or so this is pretty small though.

<comment><AUTHOR> Margin interest is margin interest. Compounded daily. I assure that Etrade (or any brokerage firm) wouldn't do if it didn't make them lots of money.

</comment></comment></comment></comment><comment><USER6> On the stockmarket, there are bulls and bears and pigs. The bulls expect stocks to go up, the bears would like to see it go down and the pigs are getting slaughtered. The moral of the story here is to not get into stuff you do not understand.

</comment><comment><USER7> This trader lost a lot of money by shorting KaloBios Pharmaceuticals Inc, which went up on the news that Martin Shkreli had taken an ownership stake in them.

You may remember Martin Shkreli having been in the news recently for a different reason: he's the hedge fund manager who bought the exclusive right to manufacture Daraprim, and raised its price from $13.50/tablet to $750/tablet, to much outrage. (Daraprim is not subject to patent, but only one manufacturer is allowed to sell it in the United States due to the combination of a small market and regulatory dysfunction at the FDA.)

</comment><comment><AUTHOR> I thought this was entertaining. Seeing as how many people are suffering in the world (Paris attacks, refugees, etc...) I guess this guy is suffering as well...

<comment><USER6> It's not entertaining, it's sad.

<comment><AUTHOR> Corrected:

<sarcasm> I thought this was entertaining. </sarcasm>

</comment></comment></comment><comment><USER8> Anyone have explanations on how this is possible? I'm familiar with the basics of options trading but it is still very confusing...

<comment><USER5> See my explanation above on albright's comment

</comment></comment><comment><USER9> This is interesting, I didn't know about shorting stock. I'd guess the best move is just to ride it out. Seems to me that KBIO might still go bust.</comment>