Less is exponentially more - <AUTHOR> http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html <comment><USER2> I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features):

On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation.

On the other side, take a look at your average real workshop: a mechanic's garage, a woodshop, or an operating theatre. They are filled with tools. Mastery is knowing a hundred different implements, each carefully designed for one or a few uses. Mastery means having tamed a thousand tools and knowing which one is the perfect one to apply to the situation at hand.

Programming languages live on a continuum between these points. Over in Zen land, you've got Scheme and Go, maybe Smalltalk and JavaScript. Over in everything-but-the-kitchen-sink territory, you've got Java, C#, Common Lisp, and C++.

The first image certainly seems cooler: you as code ninja wielding vi and lambdas with deadly precision. It's the aesthetic of the artist and intellectual. The second image is blue collar, the tradesman, the kid who took shop class for four years, the vocational school graduate.

If we accept the second image, that says something deep and maybe unpleasant about how we look at our work. But, honestly, I think the reality is that quality professional work often looks like the second picture. Every time I go to Home Depot and get some random tool that only does one thing (basin wrench, water heater element remover, you name it), it takes a job that would be hours of frustration and turns it into child's play, _and the quality of the work is better._

Simplicity is a virtue worth striving for, but I think it's also valid to want _tools perfectly suited for certain tasks_. The real art is balancing the two.

<comment><USER3> Your metaphor certainly resonates with me, but there are two mixed concepts here:

1) The 'zen' axis of language syntactic joy.

2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary.

Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java with its epic standard library, and c++ with its insanely huge number of 3rd party libraries are the workshop, and go is the empty room with a desk.

I mean, the go standard library is amazing (<http://golang.org/pkg/>) but its missing some of the features you might want if you're say, trying to build a desktop application on windows...and there just isn't (yet) the 3rd party support for it.

Professional work is, as you say, strongly tied to the practicality axis.

Yet, its worth noting that there are certainly domains that even now go is a better and more _practical_ target for applications than C++ or java, with a comparable runtime speed. Specifically, I'd suggest, cross platform system level tools and web applications.

It doesn't really surprise me that most C++ programmers haven't jumped to go; I'd wager most C++ programmers work on applications that don't cross into these domains.

<comment><USER4> IMHO, its not fair to compare Go libraries (at this stage) with the more mature implementation of libraries in C++ and Java. That will come with adoption, but even at this early stage, the set of libraries that come with go offer a lot of power.

Agreed Java came out of the gates with a good (??) desktop programming library. Google Go's library on the other hand is very web oriented with the building blocks of http, templating, json all woven in - maybe its a better approach to take, seeing how desktop programming is fast disintegrating into a proprietary, incompatible mess with bottle windows (metro) and apple (ios) locking up their environments.

I agree heartily with the zen metaphor, when programming in Go, I find the language recedes to the background and allows me to focus on the task at hand. That's the hallmark of a great language design.

The very very very fast compilation times (you have to experience this to believe it), helps a lot. Gives it the fast turnaround of a scripting language without any loss of power/ expressiveness.

<comment><USER3> The point I was making is that _right now_ go has a poorer set of 3rd party libraries than, for example java or c++, and that means that as a _practical target_ it's not as attractive for people writing _particular types_ of software.

It's patently absurd to argue that because go > C++ on the 'Zen' scale, that it's somehow also > C++ on the 'practicality' scale. These two axes are not totally independent (arguably say, the verbosity of java for example, decreases its value on the practicality scale) but they're weakly related.

Having a toolkit like QT makes C++ a vastly superior choice to go for a desktop application, _despite_ the fact that C++ lies somewhere on the dark depths of hell on the 'Zen' scale.

What I was saying, and agreeing with the OP on, is: Pick your tool for your problem.

In some cases, that's Go. In some its C++. In some it might be java; but not having all those tools lying around that people can pickup to use is a major failing for go.

...and sure, that'll change eventually I'm sure; but it's an entirely valid complaint _right now_

</comment></comment></comment></comment><comment><USER5> Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere.

1\. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an ordered map, or a b-tree, or any one of countless data structures that one can take for granted in every other language. And yes, there are implementations that take interfaces, but you have to very odd-looking casts to coerce values in and out of them.

2\. Go - or its testing support - doesnt allow a simple assert or EQUALS macro, simply because Rob believes everything should be done with if/then structures. Along with error handling, this makes go tests painful to read.

3\. Idiosyncratic handling of pointers and values, leading to confusion everywhere and accidental copies and bugs where people pass by value accidentally because its extremely easy to.

4\. Channels aren't really that useful beyond small programs (IMHO, maybe I'm wrong), and by making them synchronous any non-trivial go concurrent program has to reason very carefully to avoid deadlocks.

There are countless similar things. People will put up with these idiosyncracies for a while but move on in the end.

<comment><AUTHOR> Allow me to respond to your points.

1\. Your characterization of Rob's position on generics is not at all accurate. The Go team's view, in a nutshell, is that generics would offer some exciting possibilities for Go (particularly when combined with its concurrency model) but that it is also extremely hard to do generics well. We have put a huge amount of work into defining and refining Go, and we don't want to break it with a bad generics implementation.

There are plenty of "proper implementations" of these collection classes. Your only criticism of them seems to be that they are not type safe. But it is trivial to implement a type safe wrapper around such containers, if you desire it. So the situation is perhaps a little cumbersome, but no worse than C. I don't think this is enough to doom the language.

2\. This appears to be a matter of taste. You find Go's tests hard to read. I find them easy to read, as they're not written in some domain-specific testing language. They're just Go code.

If you need asserts in your Go tests, they're trivial to add with an auxiliary package, and thanks to "go get" it is trivial to install and use external packages.

3\. I have carefully reviewed the code of hundreds of new Go programmers (I'm a Go readability reviewer at Google and work on the open source project) and I haven't observed the issues you describe here. I sometimes see an initial confusion about addressability, but it is usually just this: [http://golang.org/doc/go_faq.html#methods_on_values_or_point...](http://golang.org/doc/go_faq.html#methods_on_values_or_pointers)

4\. I think you're wrong. Think of any time you've written an event loop or had to rally multiple threads. I'm confident that in most of those cases you could have done it more cleanly with goroutines and channels.

Finally, look at the state of programming today. Most of the languages and libraries that people use are riddled with idiosyncrasies. The Go language and libraries, by contrast, are amazingly regular. This is not just my opinion, but the feedback that I receive consistently from Go programmers around the world.

<comment><USER5> > So the situation is perhaps a little cumbersome, but no worse than C.

Actually, this is not totally true. C has pre-processor and void * which allows for simple generic data structures with no performance impact. go ties your hands here since you have to use type-assertions which are not free, unlike C casts.

> 4\. I think you're wrong. Think of any time you've written an event loop or > had to rally multiple threads. I'm confident that in most of those cases you > could have done it more cleanly with goroutines and channels.

Goroutines are great, but synchronous channels are not at all easy to use beyond simple producer/consumer models.

I'll also note that for both complaints 1 and 2, you think its trivial for programmers to just do the work, but I though go was all about saving programmer time?

<comment><USER6> > I'll also note that for both complaints 1 and 2, you think its trivial for > programmers to just do the work, but I though go was all about saving > programmer time?

Go is "penny foolish and pound wise", to subvert the maxim.

It is indeed trivial for programmers to just do the work, and in return you get an amazingly regular system that saves huge swathes of time grappling with larger issues.

I've noticed this realization occurring to other programmers. It's not at all obvious until you've written a significant amount of Go code.

</comment></comment></comment></comment><comment><USER7> It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers.

It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compiler writer myself (albeit a research compiler, Manticore), ownership dramatically changes your attitude towards using a language. Optimization limitations become "small bugs to fix when you run into them" rather than a "reject this tool as unusable" issue.

<comment><USER8> There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go:

<http://go-lang.cat-v.org/organizations-using-go>

<comment><USER9> Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.

<comment><USER10> I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewrite?

<comment><USER11> > Go is so small you could hold the spec in your hand and it's going to be > faster and more efficient than python as well as safer to modify thanks to > type safety.

I think it's very naive to think that the value of a language in a corporation is limited to its syntax or compilation speed.

<comment><USER10> If I had limited my analysis to just those things you would have a point. I didn't though. errnoh provided the justification OP was missing. The pre Go1 api changes where a very fast moving target so reducing that maintenance burden was a valid concern. My response was just consternation at the desire to rewrite something when the language is simultaneously easy to learn, safer to modify, and probably faster and more efficient at the task than the language you rewrote it to.

</comment></comment></comment></comment></comment></comment><comment><USER12> The comment on types reminds me of a very thoughtful comment in _The Structure and Interpretation of Computer Programming_:

"Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types. Our own discussion of computational objects in chapter 3 avoids these issues entirely. Readers familiar with object-oriented programming will notice that we have much to say in chapter 3 about local state, but we do not even mention ``classes'' or ``inheritance.'' In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning."

The next time your complex type hierarchy starts to fragment, you might want to think about that.

</comment><comment><USER13> For some reason I find this sentence rather amusing:

"Starting point: C, fix some obvious flaws, remove crud, add a few missing features."

From what I've seen, they've done some good things with this language, and looking backwards from today, it's clear that C is one of its ancestors.

Yet if I was given a blank sheet of paper with the same sentence, I would end up with a completely different language. In other words, this reads to me like shorthand for "Rob, that thing that's in your head, build that" (which is a perfectly legit thing to say -- I've said it myself).

It's like giving a bunch of people the requirement to fix the "obvious flaws" of automobiles, and someone draws a convertible, and someone draws an electric car, and someone draws a motorcycle, and still someone else draws a bus. Looking backward, you can see where it came from, but looking forward, nobody can predict where fixing someone else's obvious flaws might lead.

I kind of want to hold a contest where I take some ordinary thing that everybody uses but nobody loves, and have a bunch of people all design a new one that just fixes the "obvious flaws"!

</comment><comment><USER14> > Early in the rollout of Go I was told by someone that he could not imagine > working in a language without generic types. As I have reported elsewhere, I > found that an odd remark.

What I find odd is that he makes this statement, but then doesn't explain which of the following he prefers:

1\. Rewriting algorithms again and again for each minor variation of a data type

2\. Downcasts everywhere

3\. Contorting code to work with the two magic data structures, array and map

Instead he goes on to rant about type hierarchies, which is awfully non- sequitur.

<comment><AUTHOR> You don't need to pick one of those three. Maps and arrays cover most cases. The rest of the time you can implement capabilities on your types (touched on in the article) and do some type assertions.

The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type systems.

<comment><USER15> It's not an unreasonable way to view the world, though.

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."

-ESR, paraphrasing Fred Brooks

<comment><USER16> data structure != type

</comment></comment></comment></comment><comment><USER11> > What it says is that he finds writing containers like lists of ints and maps > of strings an unbearable burden. I find that an odd claim. I spend very > little of my programming time struggling with those issues, even in > languages without generic types.

Rob Pike seems to be doing a kind of programming unlike what most developers do. I fill, empty, filter and analyze values in containers all the time, and I suspect I'm not the only one.

> C++ programmers don't come to Go because they have fought hard to gain > exquisite control of their programming domain, and don't want to surrender > any of it. To them, software isn't just about getting the job done, it's > about doing it a certain way. > The issue, then, is that Go's success would > contradict their world view

I'm disappointed that the only justification that he can find to explain why C++ programmers are not embracing Go is "C++ programmers don't get it".

<comment><USER8> > Rob Pike seems to be doing a kind of programming unlike what most developers > do. I fill, empty, filter and analyze values in containers all the time, and > I suspect I'm not the only one.

I don't think you are disagreeing, there is a reason Go has built in containers like slices and maps: they are very useful.

Rob said he spends very little time _struggling with those issues_ , it doesn't mean he doesn't work with containers, just that (in Go) it is not a struggle, it is rare for you to have to write your own containers, and when you have to it is not particularly difficult (compared to eg., C).

</comment></comment><comment><AUTHOR> Here's the video of Rob delivering the talk: <https://www.youtube.com/watch?v=JE17r3n1kz4#t=53m5s>

IMO it is more compelling when spoken.

</comment><comment><USER17> The claim that wanting to be able to abstract over types is the same as thinking that programming is about constructing taxonomies is one of the sillier claims I've seen recently.

<comment><USER18> His claim as I understood it is that the fundamental building blocks should not be types (what something _is_ ), but functional capabilities (what something _can do_ ). Type abstractions are fundamentally hierarchical (from an abstraction to multiple concrete versions), whereas capabilities are fundamentally about composition (I can do A, B and C).

<comment><USER19> _Type abstractions are fundamentally hierarchical_

In C++ or Java they certainly are, but Haskell's type classes, for instance, are much more similar to Go's interfaces.

<comment><USER10> I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.

<comment><USER20> I know it's a common saying, but I've never understood how exceptions can prove rules.

<comment><USER21> It is a very old saying from when "prove" meant what "test" means now. Exception is meant in the sense of exceptional, unusual. "The unusual event tests the heuristic."

</comment></comment></comment></comment></comment></comment><comment><USER22> Its not just that many programmers want more control. Its also the case that many programmers want more complication. They really prefer the most complicated and difficult way to do things. They don't trust things that are easier or simpler. I think that maybe they believe deep down that ease-of-use versus power is truly a zero-sum game, and you just can't get more of one thing without giving up some of the other. Also, I think that many of them are afraid of losing some of their masculine programmer identity if they adopt an easier way to accomplish things. Also, many of them have invested such an enormous portion of their life and identity to becoming fluent in all of the complications that it is nearly impossible for anything to come around that would make them give up that investment.

But it boils down to the fact that selection of base technologies, like all of the most important human decisions, is generally a NOT rational process, but rather an emotional and subconscious one.

One thing that's interesting to me, and I know this will be hard to buy/comprehend for many Go/C++ programmers, but a similar thing is actually happening with JavaScript versus CoffeeScript.

Its amazing because the languages actually have the same capabilities and the syntactical advantages are so obvious.

Here is an example rationalization against the adoption of CoffeeScript from [http://oscargodson.com/posts/why-i-dont-use- coffeescript.htm...](http://oscargodson.com/posts/why-i-dont-use- coffeescript.html) :

`` You really need a transpiled language to save you some time from learning the right way to write JavaScript in the first place? Learn JavaScript's pain points and just don't do them.

It's like that C/C++ quote goes:

"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." \-- Bjarne Stroustrup. ``

<comment><USER23> Some people don't trust black boxes because they have been burned too many times in the past. I don't want to make this an age thing, but in my observation the people who are chomping at the bit to jump on the next big thing are generally those who haven't yet really suffered because of someone else's mistake.

Cryptography's got the right attitude. Don't use things that are proven to be broken, but at the same time don't trust anything that hasn't been under the harsh glare of professional scrutiny for a while.

<comment><USER22> I'm 34. I started teaching myself software development when I was seven. I have done PC assembly, C, C++, OpenGL, Win32, MFC, OCaml, .NET, PHP, Python, Twisted, AS3, JavaScript, WordPress, CoffeeScript and other types of programming. I have suffered because of mistakes in the underlying platform implementation in some cases, but in my experience more often I am suffering because of fundamental design limitations of the platform.

People move on to the next thing because they know it solves fundamental engineering problems built in to the platform they are on that are causing constant problems and they are tired of suffering through that. Such as manual memory management or traditional threading.

For example, back in my C/C++ days, I worked on a number of projects that were threaded and manually memory managed. No matter how genius the team members were we always spent a significant amount of time either guarding against those types of issues or diagnosing them, or working on Make scripts or other build-related distractions.

So that was one reason why I moved to C#/.NET many years ago. The advantage of being able to access source code in open source projects, cost benefit and lack of vendor lock in moved me away from that.

Or for example my main project right now is based on Etherpad which was originally written in Rhino which is a Java-based JavaScript. They saved a lot of lines/characters of code by doing it in JavaScript originally which was good software engineering since less code means fewer defects and JavaScript runs on both the browser and server which is also helpful. However, it was built on Java which has dated overly complicated APIs and Rhino is an inferior JavaScript engine. And we can't get it to stop freezing up/crashing at random times, which according to one of the former Etherpad team members is normal.

So we are following the lead of Etherpad and converting the application to be based on Etherpad Lite which is a running on Node.js which is another next big thing. There are no threads, so I know that can't cause any freezing. The V8 memory management and code generation is state of the art. The system will use an order of magnitude fewer resources than the old one. The asynchronous Node execution model and APIs are obviously superior to Java. At least its obvious to me.

<comment><USER24> > _So we are following the lead of Etherpad and converting the application to > be based on Etherpad Lite which is a running on Node.js which is another > next big thing. There are no threads, so I know that can't cause any > freezing. The V8 memory management and code generation is state of the art. > The system will use an order of magnitude fewer resources than the old one. > The asynchronous Node execution model and APIs are obviously superior to > Java. At least its obvious to me._

All of those assumptions are broken, some more heavily than others...

</comment></comment></comment></comment><comment><USER25> I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.)

The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ is more concerned about people labelling non- exception things as exceptions (so what?) or that try/except/finally is ugly. I agree with the latter, but even worse is littering code with if statements doing the manual equivalent of try/except/finally.

<comment><AUTHOR> The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about.

In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.

In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?

<comment><USER15> I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno.

I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks implementing a half-assed exception catching mechanism makes me sad. (Okay, Java only gets half credit here, since its checked exceptions inflict a different kind of boilerplate, but my larger point remains.)

Lack of exceptions is half the reason I'm not interested in writing Go code yet. The other half is that anything that seriously intends to replace C++ does need an escape hatch to allow manual memory management for when the GC's one-size-fits-all approach is simply a poor fit. For a language whose goal was explicitly to replace C++, this is an odd place to be tone deaf. I'm disappointed to see an attitude of "haha stupid C++ programmers don't understand that programmer efficiency is more important than CPU efficiency," instead of realizing that there are valid use cases where you do need to care about this and addressing them.

Which is unfortunate.

<comment><USER26> Did you miss the part where he says: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

<comment><USER15> You're missing the forest for the trees. The topic of the article is about how good was motivated by creating a better language for systems software than C++, and hypothesizing why it's nevertheless getting more traction with the scripting crowd than C++ programmers.

"We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care."

</comment></comment></comment></comment></comment><comment><USER27> Hm, to summarize what Go does better than C++:

      * Easier to learn
      * Faster to compile

On the other hand, C++ provides

      * Better performance
      * Better abstraction
      * Mature tools

Well, I can understand why C++ programmers do not switch.

</comment><comment><USER28> Huh, they actually made Go to replace C++. I always figured it had a deliberate intent to be a better C.

I find that being able to define your own numeric types and use them as stack- allocated things that use the standard operations is a pretty big deal in C++. I guess it depends on what you're interested in programming.

Also, having a high enough level that you can actually try writing a general- purpose algorithm library without losing noticeable performance to custom- written versions is something C++ at least tries to make possible. The template system is hairy enough to make it a bit questionable just how well you can pull this off in practice though.

Go doesn't attempt either. The arithmetic is what you get in C, implementor- blessed select types and only regular function syntax for the rest of the stuff. If you want to work with interesting mathematical constructs and write in a system-level language, off to C++ you go. The generic algorithms approach is also pretty much what you get in C with void pointers, with some run-time type information added in. You can get more of both expressivity and efficiency if you write your algorithm to handle a specific type, even when the algorithm doesn't have much that depends on that specific type.

I guess C++ is a different subset of the language for different people. Operating system programming doesn't involve mucking around with tensors or quaternions, and it might also involve more hand-tuned choice structures than an armory of genericizable general-purpose algorithms and data structures. My take on Go was that it's a really nice-feeling higher-level replacement for C, and does most everything except the very nitty-gritty hacky raw-memory juggling better than C, but I run instantly into very obvious stuff I can't do which I'd want to be doing with C++.

One thing I also found very tricky to do neatly in Go was a programming style similar to Unix pipes, where you can deploy single or combined general purpose tools to operate on streams of data. Go does have support for first class functions, which handles the tool bit and can even do the combining part (actual pipe characters would need operator overloading though), but the lack of genericity and a stream idiom kill it. There was the exp/iterable package that provided something like this using goroutines, but that got deprecated as non-idiomatic. I don't know if any replacements have shown up.

I do wonder if I'd like my C++ more if it used the duck typing interface thing from Go though. OO in C++ tends to feel a bit of an awkward fit to me.

</comment><comment><USER29> Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles.

Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places that use lots of C++?

So at least for me, while I'd love to get the benefits of what Go is trying to achieve, until it solves the problems I personally need to solve it's unfortunately off my list.

When I am on a project it fits I'm looking forward to checking it out.

<comment><USER30> I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

<comment><USER8> The interest in a language with even more features than C++ is a mystery to me.

If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.

<comment><USER30> The lack of generic programming in Go is a huge deal. It's vital for modelling complex systems without a mess of runtime checks, and generally leads to clean and reusable designs.

      With D, you can get very close to the generic ideal, "This
      is the last implementation of linear search I'll ever need
      to write." Or binary search. Or stable matching. Or
      Levenshtein distance. I searched around, and it looks
      like D is the only language offering Levenshtein distance
      on UTF strings without copying the input and without
      special-casing per encoding. D just has the abstraction
      power to deal with variable-width entities efficiently
      and within a unified definition (that works with many other
      inputs, such as linked lists of floating point numbers, if
      you want). It's really the last Levenshtein implementation
      I need to write. Now, you may not care about that particular
      algorithm, but there are benefits of that power for many
      structures, algorithms, and design artifacts that might be
      important to you.

<http://www.informit.com/articles/article.aspx?p=1621867>

</comment></comment></comment></comment><comment><USER31> >Less can be more. The better you understand, the pithier you can be.

The one real weakness of this idea is communicating with others, if you don't share the _same understanding_ you will lose parts of your audience. This is part of the problem with C++ I have read repeatedly on HN (I don't know C++ myself), that everyone uses a subset of the language, but too many use _different_ subsets.

<comment><USER32> This is absolutely a problem with C++ and a problem that Go neatly sidesteps via simplicity.

In my career as a C++ programmer (thankfully, I almost never write C++ code anymore), I've met lots of people who used it only as C-with-classes, others who used many more features but avoided templates, others who used templates but only via the STL, others who went whole-hog with template metaprogramming; some who use exceptions for basic flow control, others who avoid that but still use exceptions for exceptional circumstances, some who avoid exceptions altogether, etc.

Having each person use their own subset of the language is fine and dandy if you live in an ivory tower and never need to interface with another developer's code, but of course that is not at all how software development works anymore and eventually you'll be in a situation where you have two chunks of C++ code you need to couple together and they have almost completely alien interfaces to each other (lack of string as a built-in language type also contributes to this greatly, especially since many people avoided the STL for so long).

Go makes a lot of these decisions for you in a way such that doing things in the non-Go way is actively difficult while doing things the Go-way is nearly painless.

If you come into the language wanting to write it like C++ or any other language and you insist that it bend to your will, you probably won't like it. If you come into it with an open mind you start to really appreciate the ways in which it has made decisions for you. Even if you don't agree 100% with the decisions it made, the reasons why those decisions were made can always be reasoned out and the consistency enforced by those decisions is well worth the learning curve it takes to get used to them (IMO).

</comment></comment><comment><USER33> I was at the GoSF meetup. It was great seeing Rob talk and I think many of you are taking this blog post a bit out of context. The gist of his talk was about the philosophy and history behind creating Go.

For me the talk made me more convinced to switch over to Go. I'm a believer that makings things simple is a lot hard than making things complex and I really appreciate the deliberate approach of the Go team regarding adding features. I really hope they stay true to Rob's philosophy of less is more for years to come.

</comment><comment><USER34> I'll believe it when I see it - anyone have examples of well-written Go compared side-by-side to well-written C++ to show how it is "more expressive"?

Anyway, the benefit to small languages is that it's much easier to design and reason about a consistent and reusable set of language features. The result is overall a superior design, but worse in programmer productivity. Saying "less is more" is just a Turing tarpit.

<comment><USER8> > The result is overall a superior design, but worse in programmer > productivity.

Go (or its current implementations) might have many deficiencies, but I think almost everyone that has used it for any minimally sized project will agree programming it Go is much more productive than C++.

Some quotes about how productive people are with Go: <http://go- lang.cat-v.org/quotes>

</comment></comment><comment><USER35> Less is less, but Less might be a better choice if you're particular problem doesn't merit the additional complexity of More.

</comment><comment><USER36> If only good programming meant usage of this language over that. Unfortunately language selection has least correlation to program quality. Better practices, frameworks and above all programmer maturity matters. High time programming community thought about creative ways to pass knowledge across. Don't we have enough hammers already?

</comment><comment><USER37> I'm curious how one can file garbage collection under doing less, especially for a language intended for systems programming.

<comment><USER32> You might be less curious if you had read and understood the talk. Relevant text:

"That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration."

In a language with closures and Go-style goroutines and channels, the amount of programmer effort required to manage memory would be absolutely immense without a garbage collector.

I believe that "less" as Rob Pike means it doesn't have to do with the complexity of the underlying runtime (though I suspect he'd like that complexity to be as small as possible while getting the job done), but rather the amount of complexity the programmer using the language has to worry about when constructing programs in the language.

<comment><USER38> > In a language with closures and Go-style goroutines and channels...

Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

<comment><USER39> There are several of those languages too, but they suffer from the opposite problem: not enough differentiation to overcome the inertia, tool support, and installed base of C.

The most developed attempt that comes to mind is Cyclone <http://en.wikipedia.org/wiki/Cyclone_(programming_language)>.

<comment><USER38> I agree. In the end, it's not really surprising that C/C++ continue on. Replacements either include too much to be a strict replacement or do too little to warrant the change.

</comment></comment></comment></comment></comment><comment><USER40> I have a favorable impression of Go after reading this post, however...

The main argument that less is more is essentially the MIT approach of Richard Gabriel's classic Worse is Better concept. It merits mention.

<comment><USER41> It's not the same argument. Worse is better is about whether it's more important to have a simple implementation (Unix/C/NJ style), or a simple interface (MIT style).

This post is arguing about whether it's important to have a lot of features in a language, or whether fewer features is more powerful.

C++ has a complicated interface and a complicated implementation. So it's neither NJ or MIT style.

My perception is that Go has a simple interface but relatively complicated implementation (relative to C). It's actually closer to MIT style, despite having the Bell Labs/NJ heritage. Examples: garbage collection, segmented stacks, and goroutine scheduling. Not saying that's good or bad, but the "guts" aren't exposed as much as in C. Unix and C let all the implementation details poke out. They have simple implementations but complicated interfaces.

I guess garbage collection should be the canonical example of an MIT style feature. The interface is much simpler, but the implementation is extremely complex. And it does poke through that abstraction boundary and bite you.

<comment><USER8> > C++ has a complicated interface and a complicated implementation. So it's > neither NJ or MIT style.

Yes, in a way C++ is the worst of both worlds.

I'd like to think Go combines from both traditions and comes to a very nice and useful compromise.

</comment></comment></comment><comment><USER42> The most useful information about Go until now for me:

It was not made to replace C++, rather, it seems that it grew out of frustration of using C++ for some specific project inside of Google. That program needed 45 minutes to compile on a computer cluster!

However, Rob seems to wonder why more C++ users didn't pick up Go, but Python users did. But I believe it's more than obvious: I'm sure that he still can't use Go even as the part of the mentioned 45-minutes-on-cluster compiling C++ project. Go is a system, not something that can be _linked_ to the existing C++ or C or Fortran project. To compare, note that C was made to be able to be linked with Fortran or assembly.

Moreover, I believe that even if he had all the time of the world for rewriting the mentioned 45-minute-on-cluster compiling C++ project in Go, his resulting program would certainly compile faster and most probably "look" nicer on the line lieve but would execute bad enough that nobody would like to switch to his variant, just for the speed and memory usage aspects.

And that's all that it's to be said about Go. Good wishes are one thing, but the execution matters. One the pure performance level, it pays out immensely to replace some project written in Python with Go, on the "what compiler does for you" level too. Python is awfully slow whenever the built-in C code inside of Python and libraries like numpy is not executed, and the errors which you can catch with compiler are much more convenient than the run-time errors. But when replacing C or C++, you simply don't get the execution-level control or memory footprint benefits with Go. "But it's easier to write, especially concurrent programs" argues Rob. Yes, you can read it for every language in existence: for people who are used to the language they talk about, when they write exactly that what they are used to write, it's the easiest language to write in. Erlang people would tell him that Erlang is easiest to write for concurrent programs. It's easy to find the scenario where any language is an optimal one.

But being better or as good as C is not an easy task. The only language which was often quoted to produce even faster code was Fortran. Not that Pascal didn't have the possibility to avoid aliasing problems inherent in C, for the given tasks, numerical computing, Fortran was for enough historical reasons more convenient than Pascal.

"The determined Real Programmer can write Fortran programs in any language." <http://www.pbm.com/~lindahl/real.programmers.html> For those who don't get it, it's a joke: I quote it in order to finish with: For decades, languages are marketed as the "silver bullets." Go ain't, just like most of them before. I'm old enough to know, some of the most successful aspects of Go: fast compilation, clean declarations and reduced syntax were present in the works of Niklaus Wirth: <http://en.wikipedia.org/wiki/Modula-2>

Wirth was obviously quite right from the start. And Object Pascal programmers know they had a lot of good sides of Go even twenty years ago. Including not being forced to have constructors.

<comment><USER42> Now, what would be the ideal language that would be "better than C" in my opinion? Let's call it X. In my opinion, X would be some modification of C with the following properties:

\- no headers in C sense -- a limitation that would allow the definitions to be independent of text-based macros.

\- the compiling/linking speed of ObjectPascal or Go. That area was the most ignored by "compiler designers" for years, because "hey we're compiler designers" and "linkers are not sexy, compiler are." In reality, the mentioned C++ monster that compiles 45 minutes could be reduced to be compiled to 4 and have all functionality of current C++.

\- the full "linkability" to C. If I link a bunch of X files, I can get one OBJ which I can link to the C project. Or I can call from X to C. Both must work. Maybe I would need to link some run-time support additionally, but it must be enough.

\- having in compiler "the introspective capabilities" as in D. That is fully ignored by most of compiler writers and I really believe D is on the right track, especially since Andrei Alexandrescu worked for some of such features. If at some point I have some expression and compiler know the type of it, I should be able to query it. If compiler knows the name of something, I should be able to query it and insert the name in my code! If compiler knows some dependency, I should be able to know it in the code, if I need it. Etc.

\- built-in ways for decent strings (with counted sizes, not zero terminated), counted arrays, lists etc. I should be able to use them in the declarations/implementations without the overheads of the STL monster that it became. Again I should be able to link the runtime and access elements of these from C too.

So the logic would be: you can shoot yourself in the foot like with C, but you can have a "safer subset" (the compiler should have the switch "compile as unsafe" which would be off, in order to live you the chance to do low level when you must, but to keep most of the code "clean." When most of the "common" arrays, strings, maps, trees are part of the language, in most common cases, the whole programs could be "safe."

Etc. As you see this probably excludes some of cool features of Go like "segmented stack" and concurrency but it can give something much more convenient than C++ and still be as fast and "low-level-to-the-last-byte" usable like C.

I know, it wouldn't appear too creative, it would appear even less "interesting" than Go but I believe it would make a change: the C basis is sound, we still need the language that we know that it cleanly maps to the assembly.

Go is "something above," therefore not so attractive for those that need the "to-the-assembly" level.

</comment></comment><comment><USER43> It's pretty cool that GO has "regular syntax (don't need a symbol table to parse)." But isn't that most languages don't need the symbol table to parse? Only languages with ambiguous syntax like C++ needs symbol table.

</comment><comment><USER44> Apparently he wasn't talking about the length of the article.</comment>


Textmate 2.0 - All the new features  - <AUTHOR> http://textmate2.com/ <comment><USER2> Duplicate of the post that was killed at

<http://news.ycombinator.com/item?id=2047486>

Oh and as a Textmate user, I do wish it was true :)

</comment><comment><USER3> They forgot the most important Emacs feature: you get the opportunity to grow an extra finger. It comes with the .deb package.

</comment><comment><USER4> Funny, until you think… yep, it's a dick move.</comment>


CES 2011: Internet-connected, "appified" everything & a Google/Apple TV killer? - <AUTHOR> http://www.readwriteweb.com/archives/3_things_we_expect_to_see_at_ces_2011.php?sms_ss=hackernews&at_xt=4d224d296a82a11e%2C1 <comment><AUTHOR> I really expect SnapStick to come out with some stuff that is going to put some of these screen-specific technologies on their knees.

You can't watch network websites or basic Hulu? How long can that really fly?</comment>


Faster-Than-Light Neutrino Puzzle Claimed Solved by Special Relativity - <AUTHOR> http://www.technologyreview.com/blog/arxiv/27260/ <comment><USER2> This is an almost trivial application of special relativity. It was be absolutely shocking if the dozens of scientists involves in the neutrino experiment didn't take this into account.

<comment><USER3> In 1999, NASA lost a $300MM Mars probe due to a metric/imperial conversion oversight. Shocking, yes; unheard of, no.

<comment><USER4> But then they found the error afterward. These physicists _were_ looking for an error, hard.

</comment></comment></comment><comment><USER5> Okay. This should be an easy one but somehow I'm getting stumped.

I understand the difference in frames between the GPS satellites and the ground, but the sats themselves are fixed to each other, right? And the ground stations are also fixed to each other. Each pair is in a separate frame.

But the measurement was on the ground, and the ground stations are not accelerating relative to each other, not from the satellites. So is this saying that the ground stations set their clocks initially wrong because of their relative movement to the satellites? If so, wouldn't this be proven out by comparing the neutrinos time to the time of a photon?

<comment><USER6> I haven't read the article yet. However, the ground stations are deeper in the Earth's gravity well than the satellites. That is equivalent to acceleration in relativity.

<comment><USER7> That's negligible.

<comment><USER8> When it comes to 60 nanoseconds, I'm not sure anything is negligible.

<comment><USER9> The GR effects here is on the scale of 1e-15s, i.e. several orders of magnitude less than observed 6e-8s. 7 orders of magnitude is "negligible" as GP correctly stated.

<comment><USER10> Actually gravitational time dilation on Earth's surface is on the order of 1e-9. But still negligible.

<comment><USER9> >Actually gravitational time dilation on Earth's surface is on the order of 1e-9. But still negligible.

it is compare to zero gravitation far from Earth. The effect i'm talking about is integral of gravitational dilation change along the path of neutrinos. This path is a chord under Earth surface - the 350 km down to 10km depth and the next 350km bringing back to surface. The dilation change is about 1e-16 per meter of depth.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> But the GPS satellites and receivers already correct for these relativistic effects. Specifically:

"The engineers who designed the GPS system included these relativistic effects when they designed and deployed the system. ... Further, each GPS receiver has built into it a microcomputer that (among other things) performs the necessary relativistic calculations when determining the user's location." [1]

[1] [http://www.astronomy.ohio- state.edu/~pogge/Ast162/Unit5/gps....](http://www.astronomy.ohio- state.edu/~pogge/Ast162/Unit5/gps.html)

<comment><USER2> Relativistic effects are only taken into account when determining the position of the satellite itself, and the rate of it's clock.

It can't compensate for the effect in the linked-to article (namely, the fact that the distance and flight time between the neutrino source and destination is shorter according to the satellite, versus an observer on the ground) because that effect depends on the specifics of the experiment.

Consider this: If you flipped the location of the neutrino source and destination, you'd actually get the reverse effect (neutrinos would appear to be going slower than light).

So it's up to observers on the ground to compensate for relativistic effects of this nature.

(As I mentioned in another comment, I would be shocked if they didn't already do that)

<comment><USER12> As I understand it, and I've only read the original OPERA experiment paper, they use the GPS signal to sync some caesium clocks (I'm assuming they're caesium based on their name CS-something) and that they've done a comparison by physically moving the clocks to check the synchronisation. The paper is pretty involved on the points of the GPS sync though so I could have misread that.

I was impressed that they allow for continental drift in their analysis and indeed that they were apparently able to detect the crusts movement by an Earthquake with the apparatus.

> _Consider this: If you flipped the location of the neutrino source and > destination, you'd actually get the reverse effect (neutrinos would appear > to be going slower than light)._ //

Flipped WRT what? They've run the experiment at differing times of the day when the experiment is effectively flipped WRT the _helios_.

They also present a tentative energy relationship with the apparent superluminal speed which wouldn't, it seems, be accounted for by a simple relativistic [time-shift] systematic uncertainty.

<comment><USER13> >Flipped WRT what? They've run the experiment at differing times of the day when the experiment is effectively flipped WRT the helios.

It's "flipped" only with respect to the center of the earth. Since this isn't a point of measurement(the satellites are the ones effectively holding the stopwatch), it's not really worth taking into account.

If the neutrino stream was going west->east(i.e. with the satellites) rather than east->west, the receiving station would appear to be moving away from the starting point of the neutrino stream. That would effectively decrease the speed of neutrinos.

</comment></comment></comment></comment><comment><USER14> If true, this just goes to show how many effects you need to take into account when dealing with numbers that are 2 thousands of a percent. Effects that can normally be ignored because they're in the noise, turn out to be in the signal instead.

</comment><comment><USER15> Link to arXiv paper: <http://arxiv.org/abs/1110.2685>

<comment><USER16> I've never seen "photon" spelled with an F before.

<comment><USER17> I think English isn't the author's first language:

 _The authors of the OPERA paper [5] seem to include a correction for the Lorentz transformations, but they not correct for the change in scenario. And because they project back the time of provided by the moving clock to the baseline they seem to incorrectly assume that the outcome of their experiment should be equivalent to that using a clock in the baseline reference system_

<comment><USER18> Still a little odd, as the Dutch are generally considered to be the best non- native speakers of English in Europe.

<comment><USER19> Foton is spanish for Photon, I guess it's the same way in Dutch. (It is)

<comment><USER20> I'd imagine Photon is spelt Foton in pretty much any phonetic language in the world (or as they would say fonetic lol)

<comment><USER21> You mean _fonetik_?

<comment><USER20> Haha yes, pardon me.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Until the faster than light result can be recreated in an independent experiment, I am treating this like cold fusion. Neat result and absolutely deserving of further investigation, but not definitive.

<comment><USER23> I don't really get why you're being downvoted to oblivion, that's a great stance to take on science in general. So much media buzz is made over n=1 things; you can cut out a lot from your information diet by ignoring things until they get replication. If special relativity is wrong, we'll find out in due course, and the current counter-evidence against special relativity is hardly a dent compared to the massive evidence in favor (both theoretical and experimental). Just a few days ago I discovered this paper: <http://arxiv.org/abs/1005.4172> They assert Events as the only fundamental object, not space, not time. Then: "by asserting that some events have the potential to be influenced by other events, but that this potential is not reciprocal, we can describe the set of all events as a partially ordered set or poset, which is typically known as a causal set" and from there they derive Special Relativity.

<comment><USER24> Actually, while I fundamentally agree with the "ignoring things until they get replication" proposal, I think there's an impracticality there, due to the way information dissemination works.

There will be no flurry of HN links about this when someone replicates it (even assuming, for the sake of argument, that neutrinos really can be fired FTL, all of current physics is wrong, etc etc). Maybe a single link. It just won't have the network effect; too much of the collective audience's interest has already been consumed. And there'll definitely be no HN links when the third and fourth teams replicate it.

Even if that's a wrong claim for this hypothetical result about relativity, consider yesterday's "forced exercise and Parkinson's" link ( <http://news.ycombinator.com/item?id=3106799> ). That result is _completely_ immature (the rat experiments tested something very different from the human experiments, there has only been one human experiment, the causal story is all conjecture, etc), and there's no _way_ we're gonna hear about it when it's usefully mature (i.e. after ten more studies). (Epistemologically, I think the current result is not far removed from alternative medicine - there's some evidence, but no elegant pattern of evidence across multiple contexts, and no rigorous-but-failed attempts at falsification.) It's an interesting subject, and an interesting research programme, and I want to know about things like this, but it's too early to take this into account when making lifestyle tradeoffs.

So it seems to me that my choices are kind of ugly: I can read a LOT of cutting-edge stuff, and read all the follow-ups, knowing that most of the ground-shakers won't actually pan out. Or I can wait 20 or 50 or more years until it starts showing up in undergraduate textbooks. Or... I don't know, there must be other options, but I don't know what they are. Another option is reading Malcolm Gladwell et al, which I think is generally viewed with a certain exasperation by the genuinely knowledgeable?

Is there a blog or magazine or whatever, that popularizes science, with this slightly delayed view? "Exciting science news from 10 years ago, complete with a decade of 20/20 hindsight!"

<comment><USER25> You're on to something here. One of my favorite subjects is 'what happened to 'x'' where 'x' is some discovery or bit of news some time down the line. Most people don't even remember 'x' when asked about it until you jog their memory a bit, I can't seem to help remembering all those things.

So, how did that story with the solar panels made from hair pan out? It was pretty solidly debunked here on HN (as it rightly should have been), but what interests me is what happened to the major players in that episode, if they're still making solar panels from hair or if they came to terms with their error and documented that and published it to negate some of the damage done.

</comment></comment></comment></comment><comment><USER26> This paper: <http://tycho.usno.navy.mil/ptti/1996/Vol%2028_16.pdf> states that "the time rate is appropriate to observers on the surface of the rotating earth, that is, in the ECEF". I'm interpreting that to mean that the issue raised in the OP is not correct, but I am by no means an expert in relativity.

Interestingly, the paper also states ('Missing Relativity Terms?', pp. 195-197) that there has been confusion in the past caused by people thinking the time is measured in the ECI frame. It shows that the uncorrected-for relativistic effects have an error on the order of only 2-3mm for a stationary observer on the earth's surface (the same is _not_ true for e.g. other satellites). 'In short, there are no "missing relativity terms."'

</comment><comment><USER27> Wouldn't an obvious test involve sending something else than neutrinos through the same path, and measure that they are slower?

<comment><USER28> The path goes through the earth, so they can't send things on the same path. The detector is far underground to protect it from interference.

</comment></comment><comment><USER29> Why don't they have synchronized atomic clocks on the ground?

<comment><USER30> They do, and they used a mobile atomic clock to compare the times. The problem is that both locations are in different, accelerated frames of reference, so reasoning about time in those frames of reference can become non-trivial.

<comment><USER31> Apparently they didn't use a mobile atomic clock but a mobile gps clock to compare the times: <http://operaweb.lngs.infn.it/Opera/publicnotes/note134.pdf> So it appears they synchronized both timing sources with an orbiting clock, and the critique from this dutch guy seemingly stands.

</comment></comment></comment><comment><USER32> could someone please explain this, i wish i could say i get it, but i am so confused. i don't understand, are they not using gps just to synchronize the clocks on both ends? what does it matter if in orbit the distance seems shorter or longer if observed (viewed) from the satellites (is this what they are saying?)?

<comment><USER33> Let's suppose you're trying to time a 100 yard dash based on sound. Someone fires a gun, the race starts, and when the first runner crosses the finish line another gun is fired, you determine the elapsed time.

There are obvious things to correct for -- e.g. if you're standing at the finish line the sound from the finish line will take 1/3 of a second (roughly) to get to you, so you need to adjust your calculation.

Now suppose that you are standing off on a barge during the race. You know the distance to the start and finish lines but ignored the drift of the barge because you figured it was insignificant.

We're talking 60 nanoseconds. The satellites are moving at tens of thousands of miles an hour.

<comment><USER33> "the sound from the _start_ line" :-)

</comment></comment></comment><comment><USER34> And Einstein snickers high up in the heavens, his hair as white and woolly as the cloud upon which he partakes his afternoon slumbers.

<comment><USER34> "Fools", he mutters under his breath, "Neutrinos flying faster than light... I pity your indolence." With wiry fingers he taps his pipe on his knuckles, flinging burnt tobacco beyond the edges of the cloud. "Ah well," he sighs, connecting his iPhone to his Macbook Air, "time to install iOS 5. I bet those servers are not running as red hot any longer".

</comment></comment><comment><USER35> What's the general consensus on whether or not this was actually debunked? <http://www.wepolls.com/p/3873491></comment>


Show HN: New app, CHEEKY, connects the contact photo with a photo messenger - <AUTHOR> https://www.facebook.com/thecheekyapp

<comment><AUTHOR> Today I released the first version of my new app (ios only for right now, android is in the works) CHEEKY! It's a photo messenger that connects directly with your address book so you are able to send photos to your friends that will automatically become your contact photo in their phone. There is a download link on the FB page link or you can search the app store for "cheeky!" and its the one whos icon is a yellow wink face. Any feedback would be greatly appreciated!</comment>


What is the revenue maximizing tax rate? - <AUTHOR> http://voices.washingtonpost.com/ezra-klein/2010/08/where_does_the_laffer_curve_be.html

<comment> alan-crowe The title of the article is: Where does the Laffer curve bend? I think it is more interesting to ask about _when_ rather than _where_.

Consider this old argument which purports to show that raising taxes and raising them again will still bring in the revenue. Rich people spend future income. They look at their income and take out a loan to buy a sports car or a boat. Now they are on the hook for their out goings. If income tax goes up, they are going to have to work harder to find extra money to pay the tax and keep up their payments.

I don't like this argument. Which is different from saying that I think it is false. I think it has psychological realism, people would rather work harder than sell the boat and repay the loan. But I don't like the argument because I think it is cruel and short-termist. People who get caught on that hook aren't going to enjoy the experience. Perhaps they pay off the loan and cut back. Perhaps they suffer from stress and have to take some months off work. Whatever. Five years later they will be off the hook, one way or another and they will not forget.

When is the Laffer curve? If taxes rates go too high that might not be immediately apparent as it takes a few years for the decline in revenue to take place as people wriggle off the hook. If tax rates come back down I cannot see people who have be burned before rushing to rejoin the rat-race. Revenues will rise with a demographic slowness as those who have down-shifted age out of the workplace.

There is also a generational aspect with many of the next generation of doctors, lawyers, and businessmen being the children of doctors, lawyers, and businessmen. Building a career takes a lot of discipline and it is much easier if you have a parent or aunt or uncle showing you the way and living a well rewarded life that shows you that it is worth it.

The really tricky _when_ question is: what level of taxation blocks the inter- generational transmission of cultural capital and results in a new 1960's in which young people turn on, tune in, and drop out.</comment>


Texas Explosion caught on Youtube before Cable or Broadcast - <AUTHOR> http://www.youtube.com/watch?v=ROrpKx3aIjA

<comment><USER2> That explosion was really shocking. Lesson - get far away from burning chemical plants.

</comment><comment><AUTHOR> I heard about this via the Circa iOS app and then found this Youtube video while CNN was still just showing a map of the area the explosion happened in. The future of news isn't TV.

</comment><comment><USER3> What the heck is going on in Waco, Texas? It seems like once a year something f'ed up happens there.

<comment><USER4> Just for the record, this explosion happened 20 miles outside of Waco, and the thing everyone seems to conflate with craziness in regards to Waco happened like ten miles away.

Bad shit happens everywhere on a regular basis. Waco is close to Fort Hood, Baylor and Crawford, so yeah... maybe it can on occasion be a nexus of oddness. But it's not like it's Bartertown or something. Mostly it's boring beyond reason.

(disclaimer - I used to live there)

<comment><AUTHOR> On a long enough timeline, anomalies can happen anywhere.</comment></comment></comment>


US diplomats mysteriously go deaf, Cuba suspected of using sonic weapons - <AUTHOR> http://www.independent.co.uk/news/world/americas/cuba-us-diplomats-go-deaf-state-department-sonic-weapon-heather-nauert-donald-trump-raul-castro-a7885551.html <comment><USER2> Something similar happened to the US Embassy in Moscow. The Soviets smuggled a tiny, unpowered antenna inside and were able to eavesdrop on conversations by bathing the embassy in microwave radiation.

During this period, some of the staff reported feeling nausea, some were found to have notably elevated white blood cell counts, and Ambassodors Stoessel, Thompson and Bohlen later died of cancer.

<comment><USER3> There's no evidence that nonionizing radiation like microwaves can cause cancer. I think that was probably more likely due to the fact that everyone back then smoked about 4 packs a day.

<comment><USER4> Plus that bug was a backscatter radio. It didn't actually emit radio waves on its own, it just resonated in response to a carrier wave. The Soviets had to illuminate it with a 330 MHz radio signal from outside, but that's not ionizing.

<comment><USER5> If you look at the design of said device (invented by Lev Sergeivich Termen aka Leo Theremin), you'll suspect that it will require a pretty _powerful_ microwave beam to work.

<comment><USER4> [Probably] not enough to cause any harm. RF isn't dangerous until it is powerful enough to cause local heating and obviously this wasn't _that_ powerful. I can't really find much info on how much power Theremin's bug took, but modern backscatter radios usually operate at very low power, at the level of ambient RF from normal radio etc but can transmit 10 km or more. Based on other designs I've seen I suspect it wouldn't actually take much, though that is just an educated guess.

</comment></comment></comment></comment></comment><comment><USER6> Interesting one. I remember I went to the local One Stop with my son - he was about 15 at the time. He couldn't bear standing outside - he said the noise was unbearable. I said "what noise"?

Apparently they used some kind of sonic device that emits sound that can only be heard by teenagers, and it was incredibly effective - they wouldn't hang around outside the shop more than a moment longer than necessary. I do wonder whether it caused any damage though?

One Stop was later bought by Tesco and they got rid of it.

<comment><USER7> I (31m) can hear high frequencies

\- Last night, an ecigarette's capacitor/resistor (from 20 feet off)

\- Home Depot has high frequency bird detractors

\- A friend has a heart condition and a phone addon to help manage it.

\- TVs w/ bad speakers/signals/lighting

\- Some fluorescent lights.

The worst part is that it hurts, it's like nails on chalkboard you feel it inside when it happens, almost debilitating, and definitely hurts the balance.

<comment><USER8> A few years back I had a monitor at work where I complained to my boss that it was emitting a high pitched whine. I was about 10 years younger than anyone else on the team, and no one else could hear it. The PC technician I called to look at it couldn't hear it. Needless to say it didn't get replaced, that is until we got a summer intern. The first time the intern walked past my desk she asked "how can you stand that sound?" and I had her go to my boss to say the same thing. My boss got another intern from another team to listen and confirm, and I got a replacement the next week.

It's one of those sounds you can never drown out, it's such a unique frequency.

<comment><USER9> Advice for next time: you don't have to depend on a human's word. You can use a real-time analyzer [1], now available in smartphone apps. They display the frequency spectrum of ambient noise.

We had a similar situation at our office, were the smoke detector was emitting a steady whine that only a few employees (including me) could hear. One skeptic was finally convinced by getting out an RTA app and seeing the big spike at 12 kHz.

[1] [https://en.wikipedia.org/wiki/Real- time_analyzer](https://en.wikipedia.org/wiki/Real-time_analyzer)

<comment><USER10> Wow, 12 kHz is not audible to most adults? That's pretty surprising.

<comment><USER11> When I checked this, as a fun experiment to do with kids (they love "winning" this game, after all), is that yes while I'm technically able to hear 15-16 kHz, there's a _very_ steep drop-off in sensitivity already quite a bit below that. I needed to turn up the volume on a pure sine-wave quite high (which the kids hated immediately) to be able to hear it somewhat clearly.

So if you add in ambient noise (in lower frequencies), that could plausibly drown out a 12 kHz noise very well, for older adults (I'm mid 30s myself).

Interesting side-note: Turns out that the low end drop-off (at about 20-25 Hz or so) is not very age-dependent at all (at least when I tested these "against" a 13-year old's hearing). You need quality headphones for this, most speakers will distort/resonate some higher frequency harmonics, which you can always clearly hear. It was very interesting to hear something that was clearly a very very low frequency _tone_ turn into a sort of rapidly fluttering/beating sensation at the cross-over frequency, you can feel it beating slightly on your eardrums, but it doesn't translate into a "tone-like" sensation any more.

And yes we made sure to not do it for more than a few seconds, to not accidentally cause hearing damage--though with good closed headphones we didn't need to turn it that high, as the effect wasn't so much that the perception of the tone "disappeared", rather change into a different type of sensation.

</comment></comment></comment></comment></comment></comment><comment><USER12> There's more to this story. Hearing loss is one issue, but Cuban intelligence will do random things to US diplomats just to mess with them. From what I understand, families of diplomats have been sent back to the US because of the problems. One story I've heard from a reliable source is that they'll break in to your home while you're out and shave your cat, just to remind you they're watching, among a myriad of other things.

<comment><USER13> Hm.

Sounds better than russians, who defecated in living room.

> Breaking in to diplomats' residences and leaving "calling cards" such as > rearranging the furniture or leaving lights on. Nothing is taken, leaving no > doubt that it was not a robbery. In one case, the US defense attache's pet > dog was killed; in another, an intruder defecated on a diplomat's living > room carpet

[https://qz.com/914634/the-tactics-russian-intelligence- uses-...](https://qz.com/914634/the-tactics-russian-intelligence-uses-to- harass-foreign-diplomats-according-to-estonia/)

<comment><USER14> Killing a man's dog should be a capital offense.

<comment><USER15> Cops in the US kill dogs every day.

[https://puppycidedb.com/](https://puppycidedb.com/)

[https://www.theatlantic.com/politics/archive/2017/07/what- do...](https://www.theatlantic.com/politics/archive/2017/07/what-dog- shootings-reveal-about-american-policing/533319/)

</comment></comment></comment></comment><comment><USER16> Curious, I'll be interested to hear what the root cause is if they publish that information.

I played around with 'ultrasonic projection' for a bit, which involved two ultrasonic emitters that were emitting the same carrier wave, then the phase of one gets modulated by an audio signal. At the point where the two beams can be heard at the same time, you get the classic mixing effect where the interference between the two beams is the audible input signal. That "projected" the sound (or transmitted depending on your definition) to a remote location without the intervening folks hearing it. Of course to make it work you need pretty strong carriers and that has the effect of deafening you even if you can't hear it.

Thinking about that experiment though I wonder if you shot a high power beam at a window if you could use the resonance to pull off audio without having a tell tale laser bouncing off of the window. (mix the reflected ultrasonic signal with the echo to extract any modulation from the window).

And all of that has me wondering if it would be useful to create an inaudible sound detector / meter to let you know there was a sound around you that you couldn't hear.

</comment><comment><USER17> Wow. This sounds horrifying. I have mild tinnitus that causes me endless grief (a lot of it mental: "I'll never be able to enjoy my music properly", but also trouble sleeping.)

This is just many levels worse. And bizzare! What possible gain could you derive from harming some poor sods who are only there to do a job?

<comment><USER18> You might want to try some of those :

[https://mynoise.net/NoiseMachines/neuromodulationTonesGenera...](https://mynoise.net/NoiseMachines/neuromodulationTonesGenerator.php)

[https://mynoise.net/NoiseMachines/whiteBurstsNoiseGenerator....](https://mynoise.net/NoiseMachines/whiteBurstsNoiseGenerator.php)

[https://mynoise.net/NoiseMachines/impulseNoiseGenerator.php](https://mynoise.net/NoiseMachines/impulseNoiseGenerator.php)

[https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php](https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php)

I also find that playing a tone that is similar to my tinnitus for a while and then turning it off helps my brain to ignore the tinnitus. I use [http://onlinetonegenerator.com/](http://onlinetonegenerator.com/) and set it around 4020 Hertz

<comment><USER19> Even better, this free implementation of Acoustic Neuromodulation which seems to work on most people with tonal tinnitus : [http://generalfuzz.net/acrn/](http://generalfuzz.net/acrn/)

I don't want to draw too much attention to it though : it's probably infringing on a patent by the original researchers, who sell the official treatment device for a fortune.

<comment><USER18> You can get the same frequencies pattern in the first link that I linked if you click on "Try the original sequence — Neural Hack" in the text or if you set all the slider to 0 except for the yellow one.

The website recommends : "Use this sound generator as you like. It probably makes sense not using all sliders at the same time. Start with all sliders set to zero, then select the slider(s) that mask or blend with your tinnitus best. Set their levels to the minimum setting, mixing to your tinnitus so you can just hear it. You will then achieve the most efficient masking sound and the lowest fatigue. When using all the sliders, make sure to try the Animation feature, set to its maximum speed. The effect is interesting."

<comment><USER19> Yeah, except that the frequency pattern for ACRN needs to be centered around each person's particular tinnitus frequency, which the mynoise generator doesn't allow.

<comment><USER19> I love mynoise though, when I'm fed up with ACRN this generator does a pretty good job too : [https://mynoise.net/NoiseMachines/windchimesGenerator.php](https://mynoise.net/NoiseMachines/windchimesGenerator.php)

</comment></comment></comment></comment></comment></comment><comment><USER20> "US investigators have concluded that the country's diplomats were being hit with an advanced device that can send out sound that is inaudible but can cause huge damage to the ears of a person around them, which appears to have been left either inside or near the diplomats' houses"

So is this an actual device they found or is it something they theorized existed? Does this technology exist now? If so, that is unsettling!

<comment><USER21> "Does this technology exist now?"

Oh, yeah, easily. You could quite easily put together such a device yourself. Just put out a 130dB noise for someone in a frequency they can't hear. You can still damage their hearing.

You can play the same game really easily with eyes, too. Put out a very, very bright light in some parts of the UV spectrum and the eye completely can't detect it, won't even close the pupil, but it'll still be damaged/destroyed. You may recognize this as "the reason why the tell you to be very careful during eclipses".

I can't guarantee someone hasn't found some new "advanced" spin on this, so maybe it is an "advanced" device, but the simple case is trivial.

<comment><USER22> If you break into someone's home with the intention of causing irreparable damage, why not just poison them? What's the point of using a fancy high tech device?

Anyhow, it sounds like a device you can't hear can damage your hearing. It also looks like a device you can't see may damage your vision.

(Edit: Got downvoted, oh come-on, you guys can't take a dad-joke)

<comment><USER23> A $10 PCB is so much simpler than poison. Easier to acquire, safer (for the attacker) to store and deliver, harder to recognize as a weapon (think wifi router case). And perhaps most importantly, you can include a remote kill switch in case you need to abort the op or temporarily evade an inspection.

Wow, this actually is quite horrifying. Makes me want to go full cyborg.

<comment><USER24> Many years of cartoon villains has taught me that including self-destruct buttons on any of your devices will typically cause them to be used prematurely.

<comment><USER23> And not one of those villains ever thought to trap the button. Pull to disarm, push to receive flashbang.

</comment></comment></comment></comment></comment></comment><comment><USER25> Some of the comments:

> Syphilis, if not treated in time, can cause damage to hearing. That is the > most plausible explanation.

> Come on, isn't high tech USA capable of detecting high frequency sound?

And what sense would make for Cuba to invent something like that, and then use it to annoy its biggest enemy so far?

<comment><USER9> Those are really good points. To borrow from the saying, I'd sooner believe that

a) diplomats to a poor country engaged in risky off-books behavior,[1] than that

b) the same poor country deployed bleeding-edge sonic weapons against foreign VIPs during a sensitive, once-in-a-lifetime reopening of relations.

[1] Edit: okay, never mind; syphillis takes way too long for that to happen. Still, b) is very unlikely and needs a lot more evidence before we believe it. [https://news.ycombinator.com/item?id=14980882](https://news.ycombinator.com/item?id=14980882)

<comment><USER26> Bleeding edge? This is just a loud speaker system.

<comment><USER9> Remember, it's a system that they can't trivially detect with audio equipment that shows that "yep, loud sound with high frequency in that room".

</comment></comment></comment></comment><comment><USER27> The Cuban regime is despicable, but I don't see what they have to gain by targeting diplomats -- particularly US diplomats.

I'm inclined to believe the theory that the damage is inadvertent.

<comment><USER23> Perhaps it was not government sponsored, but rather an attack by one or more local extremists, of some sort.

<comment><USER28> Guerrilla radio? Not rebels, decibels.

</comment></comment></comment><comment><USER29> I wonder if this was deliberate?

It could be some kind of spy device, for example an ultrasonic mapping device, inadvertently caused hearing loss.

<comment><USER30> I am not in the industry, but just off hand testing a crazy spy device on embassy staff of another country, on your home turf, in a way they would notice it would seem to sort of let the cat out of the bag.

Maybe they got what they wanted but it seems like it would be strange to test it like this, particularly when the folks using it might be easily identified (assuming it is Cuba).

<comment><USER29> > testing a crazy spy device

I can imagine they had probably tested it well beforehand, just never done extended tests to discover that it caused hearing loss.

</comment></comment></comment><comment><USER31> This sounds less like sonic weapons and more like faulty equipment nearby. US diplomats have been gone from Cuba for decades are now only coming back within the last year.

</comment><comment><USER29> There are lots of devices which emit sounds just outside the human hearing frequency range.

For example, most mobile phone power supplies emit a lot of noise around 25kHz (and a few which are faulty drop down below 18kHz and become audible to young people).

I wonder what hearing issues all these devices together might cause?

<comment><USER32> When my phone is full and still on the charger, the whine is intolerable. Three chargers so far have done this. Not sure if it is the same thing. I consider my hearing sub par and I'm in my mid thirties.

<comment><USER33> "Coil whine": Look for chargers which don't have this problem. I've heard that Anker has chargers without this problem though I have not used them and can not, therefore, personally vouch for them.

<comment><USER34> I've never had this trouble with Apple chargers. I've also heard good reports of Anker products, but never tried them myself.

In extremis, you can open up a charger and pot the coils yourself with hot glue, epoxy, or some other nonconductive polymer. Just be sure to disconnect it from power first, lest you inadvertently get your own batteries charged.

</comment></comment></comment></comment><comment><USER35> Perhaps an overly powerful carrier wave for a passive acoustic bug e.g. a non- RF version of [https://en.wikipedia.org/wiki/The_Thing_(listening_device)](https://en.wikipedia.org/wiki/The_Thing_\(listening_device\)) ?

</comment><comment><USER36> I'm wondering if very low or very high frequencies are used. Either way you could probably build a detector that emits an _audible_ alarm once such frequencies are detected at high intensities.

Are whales and fish suffering similarly due to extreme noise in the oceans?

<comment><USER37> Some evidence suggests sonar may have negative effects on marine mammals.

[https://en.wikipedia.org/wiki/Marine_mammals_and_sonar](https://en.wikipedia.org/wiki/Marine_mammals_and_sonar)

</comment></comment><comment><USER38> One thing not specified in the article (unless I missed something)...is this permanent hearing loss, or temporary?

</comment><comment><USER39> I presume this is very low-frequency sonar that could therefore penetrate walls. They wanted to know whether the diplomats were at home, so they could enter and explore, plant bugs, etc at will. Including planting very small bugs in clothes that would be worn to work, probably.

</comment><comment><USER5> Three words:

MKULTRA electronic warfare.

This program tested many electronic devices to annoy target subjects.

The russian also had their own, google the "LIDA Machine" (also patented in the US).

</comment><comment><USER40> Cui bono?

The US? Cuba? Russia?

</comment><comment><USER41> > You could quite easily put together such a device yourself. Just put out a > 130dB noise for someone in a frequency they can't hear.

Or Real Soon Now™ you'll just be able to buy a uBeam

<comment><USER42> Please don't post snarky comments about flamewar topics.

We detached this comment from [https://news.ycombinator.com/item?id=14980809](https://news.ycombinator.com/item?id=14980809) and marked it off-topic.

</comment></comment><comment> purple-again A bunch of married men contract STD that goes untreated for obvious reasons sounds a lot more plausible then Russia testing out its new weapon on our diplomats.

Anyone know if any of the diplomats were female?

<comment><USER43> Syphilis only causes hearing loss in its tertiary stage, if at all.

It takes years or decades to get to that stage, and it's impossible to get that far without experiencing other, serious symptoms first.

So, no: the chances of this being Syphilis is 0%.

</comment></comment><comment><USER44> What the hell. What possible good for Cuba could this do? (Don't answer that, none, it's time to accept the post-war era is here and you should get your power-game urges out in a video game)

However, I think you could make something to pinpoint high-pitch sounds relatively easily (< $200) and get a little more conclusive evidence.

</comment><comment><USER28> There are lots of things that can cause hearing loss but I think the most _illogical_ reason would be some sort of high-tech spying device or weapon. That's just silly.

A more reasonable explanation would be tropical diseases:

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4222184/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4222184/)

My money's on West Nile Virus (WNV) because it can be completely asymptomatic _until you suffer hearing loss_. Since WNV has been detected in Cuba ([https://www.ncbi.nlm.nih.gov/pubmed/16707068](https://www.ncbi.nlm.nih.gov/pubmed/16707068)) it seems plausible.

Then plain old opiate/heroin usage:

[https://www.ncbi.nlm.nih.gov/pubmed/21586255](https://www.ncbi.nlm.nih.gov/pubmed/21586255)

...but it's not like we have an opioid epidemic or anything!</comment>