Go at Google: Language Design in the Service of Software Engineering - <AUTHOR> http://talks.golang.org/2012/splash.article <comment><USER5> I think the "return an error code" approach is just as unreadable as nested or multiple try/catch blocks when the number of failure states grows large. I think the "Maybe Monad" approach of functional languages and Scala, combined with pattern matching in the language tends to look cleaner, e.g.

some_expression match { case Some(x) => do_something_with(x) case None => no result (e.g. null in C/Java/etc) case Error(x) => handle error x }

One of the nice things about the monad approach is they can be combined together. Consider the following chain of function calls which may return null at any point:

int val = foo().bar().baz().blah();

To deal with this with if/else statements, you need 3 nested if-statement for a single line of expression. In a language like Scala, you can just write:

for (a <\- foo(); b <\- a.bar(); c <\- b.baz()) c.blah();

I think there is an inherent tension between explicitly detailing everything and boilerplate in terms of readability and writeability. I haven't seen enough Go code or written much of anything to say anything about it, except that it worries me. I do think the multi-return stuff can limit the amount of accident ignoring of error conditions, but the Go language itself doesn't provide any high level syntactic constructs to make dealing with the errors less painful, whereas with the Monad approach (which essentially is multi- return), the pattern matching tends to look cleaner IMHO.

<comment><USER6> > "Maybe Monad" approach of functional languages and Scala, combined with > pattern matching in the language tends to look cleaner, e.g.

It looks the same to me.

        case maybeValue of
          Just value -> ...
          Nothing    -> ...

isn't any different from:

        if (val != null) {
            ....
        } else {
            ...
        }

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

> Consider the following chain of function calls which may return null at any > point:

        int val = foo().bar().baz().blah();

Like val = foo.bar.blah.boo rescue nil

Or

        try {
            val = foo.bar().blah().boo()
        } catch(NullPointerException ex) {
        }

Or

        try:
            val = foo.bar().blah().boo()
        except AttributeError:
            pass

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

Personally, I do see Maybe/Option as cleaner, but it isn't novel as people make it out to be.

<comment><USER7> _It looks the same to me._

The key point is that because Maybe is a monad, you can chain things together and handle failure at the end much like a try/catch:

        let result = do
            x <- f(t)
            y <- g(x)
            z <- h(y)
            z
          in
        case result of ...

You are correct that this isn't particularly novel.

<comment><USER6> And as Go lacks both exceptions and Maybe/Option type, chaining or computation expressions will look more clumsy. I am still a Go beginner and am wondering if idiomatic Go designs programs in a different way to make up for this.

</comment></comment></comment></comment><comment><USER8> I continue to be confused by how Go gets positioned. From the article:

 _"Go is a programming language designed by Google to help solve Google's problems, and Google has big problems. The hardware is big and the software is big. There are many millions of lines of software, with servers mostly in C++ and lots of Java and Python....And of course, all this software runs on zillions of machines, which are treated as a modest number of independent, networked compute clusters"_

The author moved effortlessly from "Google's problems" to "servers" that are "networked compute clusters." That's quite a leap, because it's certainly not true that " __all __this software" runs in that manner. Android does not, Chrome does not, Chrome OS does not, the iOS YouTube app does not, Google Earth does not, etc. And there's plenty of not-big hardware that Google writes for, like laptops and phones.

And the reason I bring this up is because Go was explicitly pitched as a systems programming language - see the PDF [http://www.stanford.edu/class/ee380/Abstracts/100428-pike- st...](http://www.stanford.edu/class/ee380/Abstracts/100428-pike- stanford.pdf). Programming tools, IDEs, web browsers, operating systems ("maybe") are among the tasks specifically called out as suitable for Go. But now this article tells us that Go was designed for "large server software".

So the question is, what changed? Was Go found to be unsuitable for tasks like web browsers? If so, in what way?

<comment><AUTHOR> Nothing changed. The complete list from the linked PDF:

      - web servers
      - web browsers
      - web crawlers
      - search indexers
      - <USER2>
      - <USER3>
      - programming tools (debuggers, analyzers, ...)
      - <USER4>
      - operating systems (maybe)

Of that list, "web servers" and "search indexers" are both the kinds of "large server software" mentioned by Rob in this paper. (Most Google programs are effectively web servers of some kind, even if they don't speak HTTP directly.)

Sorry if our "positioning" of Go is a little confusing at times. We're programmers, not marketing people. We didn't set out to "market" Go at all, and had we set out with a clear message from the beginning we might have done a better job at it.

This paper best describes the initial motivation for Go's existence. However, like any general purpose language, its uses extend well beyond its design goals.

<comment><USER8> Thanks for your reply!

Go was originally presented as a language for servers, system software, and application programming. The last two were what got me excited, because server-side languages are already well represented, but there's not many languages you could consider writing a web browser or an IDE in.

However, from my perspective, Google refocused Go exclusively on server software. For example, at Google I/O 2011, the talk was "Writing Web Apps in Go." and in 2012, Go was organized under the "Cloud platform," and Rob Pike's talk was about "high performance network services." Support for Go on App Engine appears to be a higher priority than fixing its known problems on 32 bit. Rob has also discussed how he was surprised that Go attracted more interest from Python and Ruby programmers, who mainly work on server software, than from C++ users (and had some not-very-kind words to say about C++ users). These are some of the reasons I'm discouraged about Go's future as a systems and application language.

In the end I guess you give users what they want, and if Go is mainly interesting to people writing servers, so be it. Keep on rockin' (but I reserve the right to be disappointed).

<comment><AUTHOR> You're reading tea leaves.

The Go team are not a homogenous group of programmers who can do anything. Each of us has our own particular areas of expertise. That's one of the reasons we work so well, but it also means that prioritizing tasks is complicated. Without going into it too much, the idea that we prioritized App Engine over "the 32-bit issue" is a nonsense.

Incidentally, that issue, to the extent that it was experienced by some users, will be resolved entirely in Go 1.1. This is timely as a lot of interest has developed in the ARM port recently.

Rob Pike's talk at I/O 2012 wasn't about "high performance network services," it was about concurrency. Network servers are a familiar context in which to understand concurrency problems.

There's no "refocusing" going on. It's just that we're putting our best foot forward, and right now that's in server programs and tools. Writing applications (and I'm assuming you mean non-web applications) requires good UI toolkit support. That's not something we're working on, but it is something that others in the community are doing. We all believe Go will make a wonderful language for writing native apps, it's just not there yet. (And I suspect Rob does in particular, having built Inferno with Limbo, which used Go-like concurrency to great effect in its UI APIs.)

It will come.

<comment><USER9> The reality is that people working on non-google projects keep leaving because the community is being shaped by some toxic personalities. We get hooked by the evangelism, buy the party line, build a proof of concept, become disgusted with the community, leave, and concurrently realize that C++ is the way forward.

<comment><AUTHOR> Wow, you are the first such example I've heard of. Please email me firstname.lastname@example.com. I would be very keen to hear about your experience with the community.

<comment><USER9> No thanks, Andrew. I've already contributed enough and I really don't think I owe your company anything at all.

<comment><USER10> I find it rather rude to publicly say bad things about a community and then not backing it up with at least a subjective detailed report of what happened.

<comment><USER9> And I find it rude to make sudden demands of strangers. Maybe we can agree to disagree.

<comment><AUTHOR> Not a demand, just a request. Your "no thanks," is ok with me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Slide 14 is particularly important for new Go programmers. Go's garbage collector does not have access to certain optimizations because of the requirement to support pointers to internal members of structures and arrays.

The loss of these optimizations are compensated by nesting structures instead of just always using pointers to imitiate pass by reference semantics found in other GC'd languages, such as Java or Python. Using them correctly can reduce the number of objects to be collected and analyzed.

</comment><comment><USER12> From the article:

"In 1984, a compilation of ps.c, the source to the Unix ps command, was observed to #include <sys/stat.h> 37 times by the time all the preprocessing had been done. Even though the contents are discarded 36 times while doing so, most C implementations would open the file, read it, and scan it all 37 times. Without great cleverness, in fact, that behavior is required by the potentially complex macro semantics of the C preprocessor."

"Great cleverness" apparently means "the ability to detect that a file has a standard 'include once' pattern and only process it once". It hardly seems like rocket science.

<comment><USER13> No, that's called "dirty nonstandard corner cutting that will cause you to curse up a storm at $VENDOR who wrote their compiler to be fast but it breaks on $POPULAR_LIB which gets cute with the preprocessor, and yes they shouldn't do that but are you going to rewrite it?"

<comment><USER14> That's incorrect. Optimizing the guard macros works in all cases as long as you use the standard pattern _and_ the C Preprocessor memorizes the name of the guard macro.

<comment><USER15> How does this happen then?

 _"The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times."_

<comment><USER14> An excellent question which deserved an answer in the paper.

<comment><USER16> Walter Bright (who created D to solve some of the same problems Go aims to solve) wrote something a few years back which touches on this topic:

<http://www.drdobbs.com/cpp/c-compilation-speed/228701711>

</comment></comment></comment></comment></comment></comment><comment><USER17> Here is a recent Mozilla talk about the Firefox build system. The speaker, Gregory Szorc, provides LOTS of data about the performance of parallel and recursive makefiles and Mozilla's investigation of new build tools.

[https://air.mozilla.org/the-future-of-the-firefox-build- syst...](https://air.mozilla.org/the-future-of-the-firefox-build-system/)

</comment><comment><USER18> I enjoyed this article. Pike is an advocate for the language, but he openly discusses the trade-offs that were addressed by the language. Too often, the downsides to a language/technology are ignored, leading to technically boring talks.

</comment><comment><USER19> _"For the record, around 1984 Tom Cargill observed that the use of the C preprocessor for dependency management would be a long-term liability for C++ and should be addressed."_

And in 2012 Apple tries to address it: <http://news.ycombinator.com/item?id=4832568>

<comment><USER20> Go is 3 years old. Also, golang addresses more than just this issue, the concurrency approach is interesting for example.

<comment><USER14> D is 11 years old and solves the exact same problems plus it uses a more traditional approach to objects.

The big difference is Go has Google+Pike pushing it and might actually get widely adopted. Getting some improvement is not a bad thing.

<comment><USER21> Considering one of the goals of the language is simplicity, I don't see how D has solved this problem.

<comment><USER22> Because everyone else doesn't want to throw away the last 20 years of language design.

Go's search for simplicity is seen as a solution looking for a problem in the language design communities.

<comment><USER23> _Go's search for simplicity is seen as a solution looking for a problem in the language design communities._

But most programmers are not in language design communities. There is a big potential for a 'safer C' or a 'faster Python'. Yes, that's a simplification, but also how people will see Go.

<comment><USER22> > 'faster Python'

Why throw away Python's capabilities to execute it faster? Just make use of PyPy.

<comment><USER24> PyPy is geometrically about halfway between CPython and Go, performance-wise.

<comment><USER22> For the type of applications Google is showing off with Go, I doubt it matters.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> I found this article really interesting, though I would like to see more information on the design decisions for the syntax (i.e. types/return types come after). They did say it was easier to parse from a human and computer perspective, however personally (being used to C based languages I guess) I find it a little more difficult to parse. I guess I'd just like to see some references to this rather than insinuation. Anyone have any?

<comment><AUTHOR> <http://blog.golang.org/2010/07/gos-declaration-syntax.html>

<comment><USER25> Excellent - thank you for that.

I'm not sure I completely agree with their reasoning: the example only really got complicated when dealing with function pointers, however that could be simplified with a macro (or a delegate in other languages).

I do agree that C can get complex to read, however I'm not sure switching the type/parameter option is the answer. But then again, I've probably become accustomed to this format. The real test will be using the language for a few weeks... I better start some small hobby projects in Go just to see if I end up liking it!

<comment><AUTHOR> Go doesn't have macros, as they're a whole other can of worms, so the simplification one might use in C doesn't apply to Go. :-)

Go has great support for closures, so you tend to use function types more often (or perhaps just more naturally) than in C.

It is just a matter of getting used to it. I switch back and forth between Go and other languages, and it doesn't bother me. (The thing that does get me is forgetting to use semicolons in other languages.)

<comment><USER25> Thanks again, I really appreciate your input! I'm going to have to switch between the two to get a feel for it (and like you say, get used to it). I'm a big fan for language grammars (I enjoy writing them myself) so am looking forward to digging into it some more to see how it all works :)

</comment></comment></comment></comment></comment><comment><USER14> What gets my goat about this paper is the amount of misleading information in it.

Re-parsing files multiple times is a solved problem using the standard header guard macro pattern combined with a slightly intelligent C Preprocessor. Yet quotes about the horror of header blow-up pervade this paper as if this is an exciting new problem that has been solved. It isn't; it was solved more than 20 years ago.

<comment><USER26> Yes, the guard macro pattern works. But it's something programmers manage, so it's a band-aid rather than a solution.

If you change a header you need to recompile all files that include it, even if the include was conditional. Now your build system starts to look inside files rather than just check timestamps. Similar tool bloat happens over and over again in large codebases.

I'm not convinced Go has the right solution. But it's disingenuous to claim that it's competing with the C preprocessor. It's _leagues_ better.

You should enumerate all the information in the paper you consider to be misleading.

<comment><USER27> Can you name a language developed since the 80s that hasn't also solved this problem?

<comment><AUTHOR> Python? Ruby? JavaScript?

There are many more, but I name these three as they are among most popular.

<comment><USER28> How has Javascript even _addressed_ this problem?

</comment></comment></comment></comment></comment><comment><USER29> I've been reading about Go a lot lately, starting with Effective Go, and now the tutorial book Learning Go. (and periodically referring to the FAQ when I'm stumped by design decisions)

It's been enjoyable learning it, though I'm yet to write any code in anger with Go. I find some of the concepts around concurrency and OO design have really made me think about the way I write in other languages.

One thing I cannot quite make sense of though is the treatment of errors/exceptions. This article says: "Exceptions make it too easy to ignore them rather than handle them, passing the buck up the call stack.."

But the example given seems to me to do exactly that:

if err != nil { return err }

Worse still if you forget to do something with err, or don't handle a specific err !=nil situation, it seems easy for control to flow past the error handling and into code that expects no errors.

Are there small, easily understood open source projects written in Go, that would provide tangible examples of the benefit of this error handling approach?

The learning materials thus far have not really convinced me, maybe code in the wild would.

<comment><USER15> The idea, as I understand it, is to use panic/recover in truly _exceptional_ cases to unwind the stack and handle error conditions, but to never do so across package/api boundaries.

So essentially, use panic/recover as you would a much nicer version of longjmp.

(I believe) the only thing panic/recover lack compared to a more traditional try/catch is typed catching, but idiomatic usage is much different.

Honestly, I really like it. The typed-catching would be nice but the idiomatic usage of exceptions in languages like Java has always rubbed me the wrong way. Exceptions crossing package/api boundaries just seems wrong to me.

<comment><USER30> > (I believe) the only thing panic/recover lack compared to a more traditional > try/catch is typed catching, but idiomatic usage is much different.

You can use reflection with recover to do it, the upside is that it's a more general mechanism the downside is that you need to manually rethrow exceptions you don't handle.

BUT the bottom line is that the standard library doesn't throw exceptions. What you do in your code is really up to you, if you really think panicking across api boundaries is the right thing to do you can, there is no go police coming after you.

</comment></comment></comment><comment><USER31> I find the guard macros discussion in this post most amusing. Just use Go and there's no point in talking about guard macros! =P

</comment><comment><USER32> The dependency story becomes significantly less compelling if something like this proposed module system for C/C++ takes off: <http://news.ycombinator.com/item?id=4832568>

</comment><comment><USER33> I wonder sometimes if Go will become to Google what TAL was to Tandem. A language uniquely suited to solve problems unique to the design space in which they operate. In Tandem's case it was non-stop computing, in Google's case its kilocluster distributed algorithms.

I really appreciate watching it evolve.

<comment><USER34> I wrote a fully featured X window manager in pure Go [1] that I use full time. And it was pure joy compared to doing the same in C.

[1] - <https://github.com/BurntSushi/wingo>

</comment></comment><comment><USER35> > _Go is a programming language designed by Google to help solve Google's > problems, and Google has big problems._

I believe that this part of the speech is wrong, or overstated (and Rob did it on purpose). There ARE actual texts about how Go came to be, and none of it involves Google, as a corporate entity, wanting something particular and asking for some specific set of requirements, the way, say Ada was designed by the defence departments, of Erlang might have been designed by Ericsson. The story, as told also by Rob Pike elsewhere, speaks of some guys getting together t hack on a new language on some pain points THEY had, and mostly as a side project.

And, really, Go was never put front and center by Google, or that Google seems to care a lot about it and advertise. They've done far more for V8 and even Dart, including building a large team of full time paid compiler guys to work on those, whereas the did nothing of the sort for Go.

Not much adoption at Google either: some mysql load balancing service in YouTube, a caching layer for Google downloads, a Google doodle served by Go, and beta support in GAE pretty much sums it. Sure there should be some other small projects, but nothing earth shattering, the way C++/Java are used.

<comment><USER36> I think you're fundamentally misunderstanding the way these kinds of things happen at Google. Most projects of this nature have to work to get internal adoption just like any external toolchain. There's almost never an "edict from on high" that a project will use a particular technology (except to the extent that most code in production has to be written in a set of approved languages; a language created by Google itself still has to surmount this hurdle).

Pike, along with other Go team members, have been heavily involved in solving _very_ large-scale problems (e.g., [http://static.googleusercontent.com/external_content/untrust...](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/sawzall- sciprog.pdf)) for a long time now, so they are solving the pain they've personally experienced. But other teams at Google will treat Go just like developers in the world at large do -- with skepticism, until it's proven itself. It's doing so now, but it will take some time before you see heavy adoption, which is the way it should be with any new system of this magnitude.

<comment><USER35> > _I think you're fundamentally misunderstanding the way these kinds of things > happen at Google. Most projects of this nature have to work to get internal > adoption just like any external toolchain._

Well, Dart and V8 are too examples to the contrary.

<comment><USER36> Not really.

V8 was simply a drop-in replacement for existing Javascript VM's, so there was no "adoption" curve, per se. It ran something like 40x faster than the one in WebKit when it was released, so everyone just said "Awesome, thumbs up! Stick it in there."

Google is spending some developer relations resources promoting Dart, probably because it's the kind of project that requires more public buy-in (including a VM that ultimately needs WebKit hooks, which is not solely controlled by Google). But it still has to surmount the same hurdles to internal adoption that other tools and languages do. I'm no longer privy to the details, but I'm fairly certain that there are just a few internal teams trying out Dart right now, to help it get its "sea legs".

And that's really the way it should be. These things don't happen overnight, and edicts from on high that a particular team will use a new technology don't usually work out well.

<comment><USER35> > _V8 was simply a drop-in replacement for existing Javascript VM's, so there > was no "adoption" curve_

I never said anything about adoption curve. I'm talking about money spend by Google on the project and promotion done by them on it. V8 had a large team assembled, with a star compiler guy, was heavily promoted with marketing material, website and even several videos.

Of course V8 was part of their plan to take over the web browser, whereas Go is just a language for them. Well, my sentiments exactly.

</comment></comment></comment></comment></comment><comment><USER37> What is with all these Go articles? I wish Go would Go the way if the DoDo bird. Java rocks client and server, web and think client.</comment>


Study Shows Youth Flag Football May Not Be Safer Than Tackle Football - <AUTHOR> https://uichildrens.org/news/2017/ui-study-shows-youth-flag-football-may-not-be-safer-tackle <comment><USER2> Youth flag football without helmets and no recorded protective gear is no safer (with respect to concussion or other severe injury) than tackle football _with helmets and other protective gear_. Um, okay.

</comment><comment><USER3> 'Rifle football, however, correlated strongly with severe injury rates' the researchers observed.</comment>


The Elusive X-Factor: A 62-Year-Old Mystery Finally Solved (2008) - <AUTHOR> https://www.westonaprice.org/health-topics/abcs-of-nutrition/on-the-trail-of-the-elusive-x-factor-a-sixty-two-year-old-mystery-finally-solved/ <comment><AUTHOR> A history of the discovery and later identification of Vitamin K2 and overview of it's known effects in the human body by Christopher Masterjohn, PhD in Nutritional Sciences.</comment>


Faulkner's Maps of Yoknapatawpha County, the Fictional Home of His Novels (2015) - <AUTHOR> http://www.openculture.com/2015/10/william-faulkner-draws-mythological-maps-of-yoknapatawpha.html <comment><USER2> It's an impressive accomplishment, I think, to write an entire article on this subject without mentioning Lafayette County or its seat Oxford, whereupon Yoknapatawpha County and Jefferson could not more clearly be based. It's a remarkable omission, and the lack of comparison with Lafayette County as much so - one hardly need have grown up there to have the similarity between real map and fictional be either obvious or of interest.

(Edited: I had Mr. Faulkner in the wrong cemetery. I do hope he's not too annoyed with the error.)

<comment><USER3> Faulkner spent nearly his whole life in Oxford, MS. Perhaps the article assumes readers are more familiar with his life than is fair.

<comment><USER4> I think it's a reasonable assumption, since few would read the article at all unless they were interested.

It's why I find it annoying that some of the free IT journals (e.g. info world in its day) spell out every acronym. It's great as a way of providing information to a larger number of people, but sometimes I simply want to read something that can get straight to the point. I.e. something for the expert or aficionado.</comment></comment></comment>


Controversial CRISPR history sets off an online firestorm - <AUTHOR> http://www.statnews.com/2016/01/19/crispr-history-firestorm/ <comment><AUTHOR> Another article, "CRISPR controversy reveals how badly journals handle conflicts of interest," reports how differing accounts of how CRISPR gene- editing technology was developed illustrates the bigger problem of scientists publishing research papers when they have an undisclosed commercial interest in the research findings.

[http://www.statnews.com/2016/01/21/crispr-conflicts-of- inter...](http://www.statnews.com/2016/01/21/crispr-conflicts-of-interest/)

<comment><USER2> > undisclosed commercial interest in the research findings

Where's the _commercial_ interest? The Broad Institute is a non-profit and the University of California, Berkley is a public institution.

<comment><AUTHOR> Nonprofit organizations need sources of revenue, and universities are well known to use patent licensing fees to support their expenses.

</comment></comment></comment><comment><USER3> Personal I think almost by definition if two groups independently invent the same thing seems that the novel part of patentability fails.

<comment><USER4> I really hope this ends up being the case. The entire patient system is broken.</comment></comment>


A random failure: Problems upgrading Ansible and Python - <AUTHOR> https://me.micahrl.com/blog/random-failure-problems-upgrading-ansible-python/ <comment><AUTHOR> The story of a data loss bug I caused at work, how I fixed it, and surprising behavior I found in Python and Ansible.</comment>


GPUs are the Future of Scientific Distributed Computing - <AUTHOR> http://michaelgr.com/2008/08/17/graphics-processing-units-gpus-the-future-of-scientific-distributed-computing/

<comment><USER2> Anyone knows how much heat a GPU nowadays produces compared to a general purpose CPU or a Cell-BE? My guess is that if you measure FLOPS/Energy then the field is a little different.

<comment><USER3> The GPU is higher power but much higher performance and thus more power- efficient.</comment></comment>


Checking Notepad++: five years later - PVS-Studio https://www.viva64.com/en/b/0511/ <comment><AUTHOR> Seriously, how do C/C++ developers ever get anything done with so much memory and pointer maintenance? A canonical "hello world" C program is basically an exploit waiting to happen, let alone 95,000 lines of open source editor code (relying on god knows how much library code...). I'd be terrified of releasing anything.</comment>


Ask HN: Crowdfunding aggregator for suporters' projects. Would you use it? - <AUTHOR>

Crowdfunding aggregator for supporters/backers to share investments from across platforms and have them all in one place. It would also let supporters follow others and see what they are investing in or search according to project criteria to discover new projects and investors/supporters.
It would help projects get initial buzz and/or the last funds needed by letting them reach investors who typically invest in the project's sector.
So to recap:
- Platforms and projects get exposed to more users who typically invest
- Investors can see what projects other people they know and respect are investing in
- Projects can make a push to get either initial buzz or the last funds needed by targeting and reaching investors who are most likely to invest in their project
Note: "investor" refers to a crowdfunding projects backer/supporter who receives perks in exchange for their donation, not equity.
Would you use it? <comment><USER2> When I back projects I think are great, I share with my friends but sharing with other crowdfunding backers would be smart.

I'd use it.

<comment><AUTHOR> Exactly the point. And you'd see what those who you follow are investing in as well.

</comment></comment><comment><USER3> I've seen people ask for this before.</comment>


35% of young adult men in America now live with their parents - <AUTHOR> http://money.cnn.com/2016/07/18/news/economy/nba-player-jeff-teague-live-with-parents/index.html <comment><USER2> > Living with mom and dad is now the most popular housing choice for 18 to > 34-year Americans, according to Pew Research. This is the first time that > has happened since the U.S. Census started keeping records about living > arrangements over 130 years ago.

The US economy starts to look more and more like other ho-hum economies. Nothing really special.

<comment><USER3> And yet people keep telling me that America is already great. The economy is turning to shit, jobs are shipping overseas, and everyday, blacks are being murdered by cops, and yet, people keep telling me that there is no need to Make America Great Again. They keep telling me that America is already great.

</comment></comment><comment><USER4> I don't know that this is such a tragedy _in itself_ , since living together with parents is a more efficient arrangement in a lot of ways and can be mutually beneficial.</comment>


Show HN: Free listing & directory WordPress plugin - <AUTHOR> https://demo.hivepress.co/ <comment><AUTHOR> Hey,

I've built HivePress — a free multipurpose listing & directory WordPress plugin that allows you to build any type of directory or classifieds website.

It's extensible, highly customizable, and easy-to-use. Currently there're 4 free add-ons (favorites, messages, geolocation, reviews) and I'm working on a few add-ons that will be released soon (Facebook login, claim listing, paid listings). I aim to develop the most feature-rich listing & directory plugin for WordPress while keeping it free.

It's in the beta stage so any feedback is highly appreciated. If you decide to use it and find a bug, or want to request some feature please post an issue on GitHub [https://github.com/hivepress/hivepress](https://github.com/hivepress/hivepress) Thanks!</comment>


James Dyson's vacuum cleaner required 5,127 prototypes: In Praise of Failure - <AUTHOR> http://www.wired.com/epicenter/2011/04/in-praise-of-failure/ <comment><USER2> I know the point is accepting the process of failure, but it reminds me of Edison vs Tesla. Tesla supposedly said "If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw after straw until he found the object of his search. I was a sorry witness of such doings, knowing that a little theory and calculation would have saved him ninety per cent of his labor."

<comment><USER3> Edison: _Genius is one percent inspiration, ninety-nine percent perspiration._

Telsa: _If Mr. Edison had thought a bit more he wouldn't have to sweat so much_

(full disclosure: I've never found an original source on the Tesla quote, so it's probably apocryphal).

</comment></comment><comment><USER4> > _it took 5,127 prototypes and 15 years to get it right_

This works out to 341 prototypes a year. I understand this is based on a true story and it's probably a good vacuum cleaner, but - c'mon, give me a little break here.

(edit)

Worth adding - I was buying a vacuum for myself not long ago and looked at Dyson. Their marketing materials are full of exaggerations, inaccuracies and half-truths. One of their central claims is that their vacuums "do not loose suction". A reasonable question here is what happens when a dust canister fills up? Does it keep sucking dust and ejecting it back into the air? They also claim it is _the only_ cyclonic vacuum (followed by some fine print), and this is simply not true.

All in all, it is really well marketed, but otherwise severly overpriced vacuum of an average manufacturing quality (can't lift certain portable models by their carrying handle, because some seal opens up and, ironically, they loose suction) and it was designed by an interesting person. That's about it.

<comment><USER5> I would be curious to know if anyone here has had a good experience with Dyson. The marketing woo, high price, and the flimsy, plasticky look of their vacuums has always turned me off.

<comment><USER6> I happened to need a new vacuum a few months ago, and I asked a professional cleaner friend for her advice (don't laugh - it's a _very_ lucrative business here in Sydney). She said, basically, Nilfisk or Miele, whichever's on sale.

I asked about Dyson since I'd also been at least somewhat impressed by their marketing materials. The response was that while their performance is reasonable in a light use context, they are not at all durable and their use is unheard of in a commercial environment. They also have no commercial products, which is a red flag because while a company's marketing might be able to bamboozle consumers, the professionals are far less impressed with glossy brochures and only concerned with consistent performance, reliability and TCO. Nilfisk and Miele have commercial products.

That was pretty much "case closed" for my decision making process and I bought a Nilfisk. YMMV.

<comment><USER7> Yeah. I've always taken the same view. Dyson's are not used by comercial cleaners _anywhere_. A big brand for pro cleaners is Henry. You can buy for a £100. The suction is immense, they're super durable, you can get the head into the smallest/lowest spaces and they don't really seem to lose suction that i've noticed, even when the bag is jammed full.

</comment></comment></comment></comment><comment><USER8> Every time someone pulls out that tired Edison quote I'm reminded of a response Nikola Tesla gave when he heard it:

"If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw after straw until he found the object of his search. I was a sorry witness of such doings, knowing that a little theory and calculation would have saved him ninety per cent of his labor."

While not giving up after the first time your idea doesn't work is vital, it's equally important to avoid work when a little theory and math will save you the trouble.

</comment><comment><USER9> I suspect the "5,127 prototypes" figure covers the entire development cycle to date, including 35 models and a highly successful business -- not 5,127 prototypes in his garden shed before the DC01 went on sale! (That'd be some shed ...)

Lest we forget, these days Dyson has a research, design and development centre with 350 engineers working for him:

<http://www.dyson.co.uk/insidedyson/article.asp?aID=dysonhq>

</comment><comment><USER10> For those who enjoyed the author's story, there's plenty more in his well- written autobiography: [http://www.amazon.com/Against-Odds-Autobiography- James-Dyson...](http://www.amazon.com/Against-Odds-Autobiography-James- Dyson/dp/1587991705).

</comment><comment><USER11> I have a house with 36 stairs and landings, most of them carpeted. Much of the rest is wood floor, so I needed a canister vacuum which was light yet high quality, and could handle a variety of attachments with aplomb. Being HEPA would be a benefit.

I came to the realization that Dyson's canisters vacuums are terrible machines. They are (except the microscopic capacity DC26) amazingly heavy -- 20 pounds, have poorly constructed plasticy parts, are poorly maneuverable, are very leaky (this is what passes for HEPA?) and are noisy. Did I mention that the usable ones are _unbelievably_ heavy? Does Dyson not understand what canister vacuums are used for?

I thought: this took 5,127 prototypes to produce?

I eventually bought what I think is generally regarded as the best vacuum in this category: a Miele. (In my case, a Neptune with additional Parquet attachment). Exceptionally quiet, only 11 pounds, entirely sealed with high quality filtration, durable, very powerful, and maneuverable. A very well thought out, obviously German machine. The difference between the two is very much like a BMW versus a Pontiac Sunbird. The BMW is obviously a more refined machine, but the Sunbird is the flashiest thing you'll find at Best Buy.

<comment><USER12> The best answer is not a better vacuum you lug around. Rather, install a whole-house vacuum. It will cost as much as a few decent vacuums, but will also last as long as a few of them. More importantly, it will eject all the air (laden with all manner of things you'd prefer not to breathe) _outside_.

<comment><USER11> Well, a whole-house vacuum's not an option here. But as it turns out I installed a whole-house vacuum for my parents while helping to build their house. And we basically never used it, for two reasons. First, we didn't find its cleaning capabilities as good as a standard vacuum. And second, one should not underestimate the inconvenience and weight of long hoses.

</comment></comment></comment><comment><USER13> I have a Dyson - and after some years I think it's only a hype product. I couldn't realize for a long time I've fallen for a 90% marketing, 10% product thing. My next vacuum will not be a Dyson.

</comment><comment><USER14> My mom's Royal has been working for 20+ years without losing suction, although it's heavy as shit because it's all metal. She bought it when she worked at a sewing and vacuum place.

My friend got a used kirby for $350 that kicks any dyson's ass all over the place.

<comment><USER15> > My friend got a used kirby for $350 that kicks any dyson's ass all over the > place.

As long as you never have to carry it up or down stairs. Or need to replace the bag. Or use cleaning attachments. Or disassemble to remove something stuck in the works.

Granted, Kirbys are built like tanks, but I'll choose my Dyson DC14 any day.

<comment><USER14> It's still heavy, but the newer ones are a breeze for attachments, bags, pushing it around, and all that other stuff.

</comment></comment></comment><comment><USER16> If you're not failing, you're not trying hard enough to push yourself to the boundary-of-ability where you learn.

There is actual basis for this in learning theory.

</comment><comment><USER17> I've always thought Dyson make terrible _products_. The innards of a Dyson vacuum cleaner are no doubt ingenious, but the early models all weighed a ton and were incredibly difficult to lug around the house and actually clean stuff.

Same with the AirBlade. Clever idea, but it doesn't dry your hands, and the blast of air knocks your hands into the sides, negating all the claims of better hygiene.

I'm sure the Dyson process involves tons of prototypes, but I don't for a second believe they actually spend much time looking at people _using_ the damn things.

<comment><USER18> Never used a Dyson vacuum but I've used the Airblade and it worked astonishingly well.

<comment><USER19> I like the Airblade, too. It does dry your hands quite fast. And I've never had my hands knocked to the site by it.

(I can't say anything about the economy or hygiene, but it's one of the hand driers I actually use. I am much to impatient for the conventional ones.)

</comment></comment></comment><comment><USER20> I loved this one. Maybe the best example yet of a great idea being necessary but totally insufficient for a great outcome.

</comment><comment><USER21> I have to imagine in this day and age they did it 5000 times because they didn't know how to use flow-modeling software?

<comment><USER22> er, yeah, this was late 70's. Don't think using flow modelling software was a viable proposition (this is one guy, living off savings, working in his shed)</comment></comment>


Bay Area housing activists plan to sue towns for NIMBYism - <AUTHOR> http://www.modernluxury.com/san-francisco/story/city-housing-activists-test-out-brazen-new-battle-cry-sue-the-suburbs

<comment><USER2> > San Francisco Bay Area Renters' Federation (SFBARF)

I wonder if they realized that when naming it?

Name aside, this needs to happen. Given demand, that area needs a lot more high-rise apartments and far fewer houses; there's no reason not to build them except the vetoes of busybodies who already have a house in the area.</comment>


Chris Granger on the LightTable architecture - <AUTHOR> https://groups.google.com/forum/#!msg/light-table-discussion/2csnnNA1pfo/693EWDJVhuwJ <comment><USER2> FWIW a friend and myself were very inspired by Light Table, Chris Granger and Brett Victor. We've been working on applying these ideas to C#.

We've built [http://codeconnect.io](http://codeconnect.io) for a function-by- function view of C# code.

Now we're currently finishing up live coding: [http://imgur.com/2QE5Bkw.gif](http://imgur.com/2QE5Bkw.gif)

People have expressed sadness about the current state of Light Table. I think Chris did a phenomenal job demonstrating some of these ideas and exposing them to the developer community at large.

<comment><USER3> Interesting. What's your plan for dealing with state?

<comment><USER4> seanmcdirmid I just checked out your paper about live coding (with pacman video). Did you see [http://worrydream.com/LearnableProgramming/](http://worrydream.com/LearnableProgramming/) ? Do you guys consider collaborating?

<comment><USER3> I saw that in 2012 (I started my own research in 2007). At the time...I sent an email to Bret Victor, but he never replied (I hear he is busy).

</comment></comment></comment></comment><comment><USER5> I am sad that LT didn't succeed as I hoped (I was a backer), but this email highlights a very important feature for succesful open-source projects (which LT was meant to be from the start), which is to make them accessible to other contributors.

Building your project in a niche language (not just Clojure, but ClojureScript) is a risk. Making it tough to follow the code/data flow is indeed a terrible decision (though usually a silent one as a side-effect of other architectural choices). Etc...

I'm an Emacs user, and I'm still waiting for the Next Great Editable Editor. (Though since it moved to Git [thanks ESR!], maybe Emacs itself will get a new wind)

<comment><USER6> What would it take for Emacs to become "the next great editor"? It extremely extensible now. Packages like Helm and Company mode have made emacs more competitive, for example.

[https://github.com/emacs-helm/helm/wiki](https://github.com/emacs- helm/helm/wiki)

[http://company-mode.github.io](http://company-mode.github.io)

<comment><USER5> Yeah, Emacs may already be the Next Great Editor and not know it yet ;)

It needs to be more novice-friendly, having pre-CUA [1] shortcuts and terms ("windows" & "frames") is a trivial but powerful obstacle, I think. It needs to modernize its extension language: I still can't believe a 'then' clause needs a 'progn' if it's to contain multiple statements, but 'else' doesn't. I'm crossing my fingers for Guile, which, though still a niche language (Scheme), is at least more modern and standardized. I don't know how robust the interaction between the elisp (which is, like it or not, is here to stay) and Guile code is.

Emacs has a humongous codebase at over 2M lines of code [2] (of which, admittedly, 1.5M of that is elisp), with some deep black art as legacy from what it needed to run on when it started (thanks to ESR's work, the git history actually spans the entire 30 year history of the project! Here's the very first commit: [3] [Though admittedly because of RCS's per-file semantics, the early history is a bit weird).

But more importantly, it needs more mindshare. I'm hoping the git transition can help that.

[1] [http://en.wikipedia.org/wiki/IBM_Common_User_Access](http://en.wikipedia.org/wiki/IBM_Common_User_Access) [2] [https://www.openhub.net/p/emacs](https://www.openhub.net/p/emacs) (slow server) [3] [http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...](http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584125c44a1a2fbb46e810459c50b227a95e2)

<comment><USER7> Does vim really have an order of magnitude more users than emacs? Is emacs really lacking in mindshare? I have no real reason to doubt those claims but I find them kind of mind-boggling. I'd have guessed they were close to parity (for the first).

<comment><USER5> And then some.

I can't immediately find the survey that struck me, but here's a Quora answer [1] that cites O'Reilley selling twice as many Vim books than Emacs, the Debian PopCon results [2] that are rather striking (but Debian PopCon has quite the preselection bias, and the data may not cover all sub-packages properly), and Ubuntu's results [3] are a bit harder to parse but also striking, with vim-common at 2714181 / 25488 installs / "votes" (regular uses), vs emacsen-common (the highest-placed "emacs" package) at 330647 / 1669.

[1] [http://www.quora.com/Are-there-more-Emacs-or-Vim- users](http://www.quora.com/Are-there-more-Emacs-or-Vim-users) [2] [https://qa.debian.org/popcon- graph.php?packages=vim%2C+emacs...](https://qa.debian.org/popcon- graph.php?packages=vim%2C+emacs&show_vote=on&want_percent=on&want_legend=on&from_date=2010-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1) [3] [http://popcon.ubuntu.com/by_inst](http://popcon.ubuntu.com/by_inst)

<comment><USER8> Well, I'm an emacs guy, and I've bought a vi book (O'Reilley's in fact) and not an emacs book, because I needed a book to figure out how to use vi and I didn't with emacs. Just throwing that out there.

<comment><USER9> Same here. I got _Practical Vim_ and then moved to emacs+evil because I liked some of the vim concepts but wasn't willing to trade the usefulness of emacs. Never bought an emacs book either, after all "emacs is the extensible, customizable, _self-documenting_ , real-time display editor."

C-h (+ k or m) is probably one of the first key chords you are to learn when starting emacs, from there everything is downhill.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> "Even with a principled approach, I think I managed to build a system that only I can really get around in."

Interesting. Power vs difficulty in debugging.

" BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins."

BOT is described here: [http://www.chris-granger.com/2013/01/24/the-ide-as- data/](http://www.chris-granger.com/2013/01/24/the-ide-as-data/)

<comment><USER11> >Interesting. Power vs difficulty in debugging.

Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

<comment><USER3> This is all too harsh though. When you are doing something new, you aren't that sure what kind of extensibility and modularity you need internally, so you wind up over engineering and over architecting. Imagine you wanted to build a bridge without no one ever doing that before. It is an open problem, the resulting bridge might work, but it won't be pretty and probably used way too many materials, meaning it will be difficult to repair and upgrade.

But your next bridge will be better, benefiting from the experience of the previous one, and you might be able to even do some design up front for the third one that actually sticks.

Tl;dr get started on your first bridge early.

<comment><USER12> Your second bridge might not be better if this turns out to be true: [http://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_seco...](http://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_second-system_effect)

<comment><USER13> The error is not building the second bridge, it's trying to create a new design from the ground up rather than improving on the first one.

</comment></comment></comment></comment></comment><comment><AUTHOR> Even though I make a competitor (Cursive) I'm still sad to see LightTable languishing. It had some interesting ideas, even if they never came to fruition.

But the point about the code being incomprehensible is definitely true. I've tried a couple of times to follow a simple flow through the code to see how something worked, and it's difficult-to-impossible. It would be great if the community could pick it up, but this email makes that look very difficult.

Interesting comments about using alternative languages, too. However I suspect that in the same way that ClojureScript wasn't really that much of a benefit compared to the architecture, it probably isn't the main impediment to outside contribution either.

</comment><comment><USER14> This is what happens when you create a project. 99 times out of 100, you make something that isn't what you'd hoped it would be.

So what?

The key is to recognize that failure is not the lack of certain project XYZ being at certain state QPO. Most people will not have the lifespan long enough to see a project they work on go perfectly. This notion of failure, that it is the lack of some future state of being showered in dollars/accolades/kisses- and-hugs, means that every project, ever, is a failure.

Failure is giving up.

Failure is letting that experience, where you didn't magically achieve your hopes and dreams, and letting it drive you back into the warm bosom of punching a clock at a gigantocorp or cargocultup. Instead of relying on yourself for your livelihood, your purpose, your mark on society[0], you go somewhere safe where you get told what to do and you just bide your time, collecting a paycheck, until you escape that particular bouncing dead cat on to the next one.

Success is not giving up. It's taking your lumps, "oooh, I made a shitty thing, woe is me, I'm not as smart as I thought I was" [1] and telling yourself that it doesn't matter, that you'll try again.

Chris, if you're reading here: start another IDE project. Use what you've learned. If you really, actually cared about the things you said, don't let your perceived failure with LightTable[2] prevent you from starting something new. It won't be the same story all over again, because you aren't the same person now as when you started LT in the first place.

In the end, no project is a failure, unless we let it have no impact on us, unless we learn nothing from it. Don't squander the lessons learned through bad projects by choosing to not continue onto new ones.

[0] And don't for a second think you don't owe society a mark or two

[1] Check my username

[2] I wish my projects have failed so well as LightTable

<comment><USER15> Did you see this about what Chris it up to currently: [http://techcrunch.com/2014/10/01/eve-raises-2-3m-to- rethink-...](http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink- programming/)

</comment></comment><comment><USER16> Wow.. Am I the only one that actually likes using LT? I don't always write Clojure but when I do, I use LT. I dream of creating ClojureScript single page apps with OM in LT nearly every day.. :)

I find the insta-RPL to be absolutely fantastic. I wish F# had insta-repl instead of just repl. I wish everything had insta-repl.

<comment><USER17> I love Light Table too. The inst repl is a killer feature!

</comment></comment><comment><USER18> Chris's post on the LT mailing list 1 year ago[1]:

        Depending on how things play out, it might make sense to try and merge
        [with atom.io]. [...]

        The main value of LT isn't about being a better standard editor, it's
        taking that editor and making it do things that standard ones can't do.
        [...]

        From the outset, our goal has been to make programming better and I've
        honestly come to the conclusion that LT on its own can't do that. [...]

        The truth is that I think we can do orders of magnitude better and I have
        some evidence of that already, but it's going to take more than a new tool.
        It's going to take a different way of thinking about the problem. That is
        what I think will end up being the ultimate legacy of Light Table -
        a version of programming that is meaningfully designed for humans. You've
        heard us mention "Aurora" a number of times now and I think that's the best
        description for this crowd of what we're out to accomplish; programming
        designed for humans. This often comes as a surprise to people, but
        I honestly don't like to program very much - it just happens to be the only
        way to create the things I want.

It should have been clear by then that the LT author had lost interest. That's when I decided[2] to concentrate on making Vim/Emacs better instead of trying to find (or make) a "perfect" foundation upon which the _already existing Vim /Emacs plugins_ could be _rebuilt_. There's a reason why Sublime re-uses Textmate themes; and Java is useful (tons of libraries) even though it's boring; and Linux is widespread even though it's inelegant compared to Hurd or whatever: there's a giant mountain of existing, working _boring_ tools already built--tools that you _will not_ want to rewrite after your perfect platform is done.

Neovim popped up around that time and for the above reasons it made sense to me. If the foundation is imperfect, do the dirty work to make the foundation less-imperfect. With 10% of the work[3], I think Neovim can enable 90% of the goodies I (we?) wanted in LT (and 100% of the visual appeal).

[1] [https://groups.google.com/d/msg/light-table- discussion/YTuCH...](https://groups.google.com/d/msg/light-table- discussion/YTuCHoOym1E/PNSnlYsM1i8J)

[2] [http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_re...](http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_replace_vim/cfx0kyq)

[3] Remember: don't discount the work of writing plugins.

<comment><USER19> Based on what he said just now, I do not think it is accurate to say he has "lost interest":

 _In my particular case I 'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can._

That is, he's still working on it all the time, which I take to mean he is still interested in it. Rather, he is giving a frank assessment for why LT has not gotten more traction as an open source project.

</comment></comment><comment><USER17> I am quite amazed that so many people think that Light Table failed. Far from it, Light Table changed a whole industry:

1) Chris Lattner, the creator of Swift publicy acknowledged that Swift, used to develop all future IOS and Apple Watch apps is inspired by Light Table:

[http://nondot.org/sabre/](http://nondot.org/sabre/)

2) It inspired a whole generation of people and tools to move away from heavily typed and compiled languages like Scala to dynamic and repl based languages

<comment><USER20> That's interesting - so who moved from static to dynamic languages because of LightTable? Actually I'm not seeing any movement from static typing to dynamic typing in recent years, so wondering what you're talking about.

<comment><USER17> LinkedIn for one:

[http://www.quora.com/Is-LinkedIn-getting-rid-of- Scala](http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala)

<comment><USER21> That doesn't really seem definitive. That page also includes a link to this[1] page, from a month ago, stating that LinkedIn is moving part of its stack to Scala.

[1] - [https://engineering.linkedin.com/frontend/new- technologies-n...](https://engineering.linkedin.com/frontend/new-technologies- new-linkedin-home-page)

<comment><USER17> Well, in the conclusion they do seem to indicate that Scala use is being re- assessed with Java:

We built the new version of the home page using Scala because the language adapted itself better to asynchronous programming. With the incorporation of lambda functions in Java 8, it's possible we'll be utilizing Java more.

We will have to wait for more people from linkedin to weigh in on this, but it does seem to indicate at looking at other solutions than Scala when they can.

</comment></comment></comment></comment></comment><comment><USER22> He makes a very good point about understandability in system design:

 _Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges._

</comment><comment><USER23> I think the way forward is to add the Light Table main features to the Atom Editor as plugin. It has a bigger community (and facebook $$$ behind) and is a very good candidate for "the next Emacs".

</comment><comment><USER24> It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It's architecture is horrible, and its catering too much to other languages.

Once it's dead the space it frees up can be filled again by something that actually works.

<comment><USER3> Failed experiments can lead to great results down the road. I'm predicting that LT was probably totally worth it.

<comment><USER24> LT didn't bring any new inventions, emacs, self, morphic, CL, they've all done some aspect of it 30 years earlier.

LT has shown however that you can make a load of money of kickstarter without delivering a product, but people will still throw money at you for building the next big unfinished thing (see their new pet project with a broken architecture called EVE).

<comment><USER3> This is why academia sucks so badly: they think because some features were released in some projects that "there is nothing new under the sun." Bull! There is still a lot to be explored and none of those projects you listed contain much of the live programming story at all (Chris Hancock at MIT did flogo II, which is more relevant than the Lisp and smalltalk projects).

To make any progress at all, we just need to stop listening to those who are living in the glory of a past that wasn't so great anyways.

<comment><USER25> But LT hasn't achieved either half. It's not an innovative research project. And it's not a polished consumer product.

<comment><USER17> Did any of you guys even use Light Table. I bet you didn't as it did some pretty amazing stuff that no other IDE could touch!

<comment><USER24> Yes, I also dug into its codebase. Have you actually used Self for example?

<comment><USER17> I guess if you are trying to use Light Table as "the uber clojure IDE" then it was never a goal for Light Table. Intellij Cursive is probably a better editor for that. Light Table's aim was for a form of interactive programming. Anyway, using an editor as an end user is very different to just playing around with its source code, although I applaud that you have done that. I will look into "Self" some more as I don't know enough about it. Do you have some good links on Self to get me started?

<comment><USER24> [http://www.selflanguage.org](http://www.selflanguage.org)

You should watch the videos on the introduction page and play a bit with the system, it's interesting to see how much interactivity and liveliness was already achieved in the 80s/90s,

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> > architecture ends up being far more important than the specific language > used

Good insight.

</comment><comment><USER27> > The industry has also changed pretty drastically since I started LT. During > its creation CPS gained traction, React was created, the Clojure ecosystem > basically rewrote itself...

The software industry has not changed drastically for several decades. To call the introduction of a system (React) that is basically a workaround for a problem that should does not exist at all in a sane environment (DOM) a drastic change for the software industry is a bit much.

</comment><comment><USER28> Is this article restricted material? If not, could somebody please make it accessible in some way? Apparently, there's a google account necessary in order to read it...

Thanks!</comment>


MailGirl – A RESTful service for sending templated emails upon request - <AUTHOR> https://gitlab.com/GCSBOSS/mailgirl <comment><USER2> So, MailGirl is just a nail merge tool implemented in JavaScript and running on Node, right?

Why call it Mail _Girl_ , anyway? Why not "MailAssist" or some other gender- neutral name?

<comment><USER3> _MailHuman_</comment></comment>


Student files lawsuit after coach distributed private Facebook content - <AUTHOR> http://www.splc.org/newsflash.asp?id=1938 <comment><USER2> I'm pretty amazed that demands for logins and passwords are ever honored. It's one thing to confiscate notes passed in class, but this is the technological equivalent of letting a teacher open the locked doors of your house, listen to your phone calls and crash all your friends' parties.

<comment><USER3> indeed. Clearly the teacher deserves everything coming to him in the suit.

But hopefully the student has learnt an important lesson about privacy too!</comment></comment>


Real life flying toaster - <AUTHOR> http://flitetest.com/articles/flying-toaster

<comment><USER2> I'm waiting for the real life dancing badger.</comment>


It is a Sunday evening in the year 2018 - <AUTHOR> https://twitter.com/claymill/status/1023772999013597184 <comment><USER2> I'm not really gathering what this is supposed to be about.

Is it TV (like NBC, BBC) or Twitch?

Is the author trying to say, "Why are 1000 people watch someone basically doing nothing when she's supposed to be playing video games"?

If so then you just need to find a better streamer of which there are certainly thousands</comment>


Former OAuth 2.0 editor releases alternative auth protocol - <AUTHOR> http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/ <comment><AUTHOR> I kept a close eye on Eran's blog over the past years after he announced he would be working on an alternative. Happy (no pun intended..) to see its release.</comment>


Ask HN: How can I make this page convert better? - <AUTHOR>

Currently 30% of visitors to this page click and go to the signup page. (Which I think is pretty good) Then about %3 of that convert to paying customers.
www.ownzee.com/demo
I think something about this could be optimized better, Im not really sure what, just a gut feeling.
Any thoughts? <comment><USER3> OK, I spent 30 minutes with it. I didn't sign up, but only because I have no particular need to publish right now. It might be a good thing to have a freebie thing that only lets you do, say, 5 pages; but I appreciate that there's a risk some people will abuse that to suck down the results and re- upload them elsewhere. Maybe a 'try it for 30 days free' option?

I would change up the front page a bit. Currently, the 4th element (the subheading in the caption to the picture under the headline) is what tells me I can edit-in-place. The animation is great, but I opened the page in another tab and then clicked over to it a moment later, by which time the animation had completeed. I didn't see what the big deal was until I read that. Instead, I'd make that the headline: _This is your editor_. Because the immediate editability is the big win. I _loved_ the UX and how responsive it was.

Minor caveats: some of the fonts don't render right in Chrome, but have the bottom of the letters (descenders etc.) chopped off. I'd really like some toolbar widget to turn on a grid for those times when I want to line things up or maintain a vertical symmetry.

Last issue, the _Learn More_ page. Visually and semantically, it's great - <USER2> makes a compelling argument and does so in a humorous fashion. But you don't tell me anything about what I'm publishing - is this flash? HTML+CSS? Something else? That information should be there so I understand whether I'm buying into your hosting walled garden, or renting a general-purpose tool that I can then deploy and further develop as I see fit.

I also think you should put the $ cost up on the _Learn More_ page and offer a link or argument for the price. I hate hate hate not seeing the price information until I get to the sign up screen, it always feels like a gyp. Wear your price on your sleeve; that establishes that your product has value from the outset, and doesn't confront me with an expensive surprise when I try to sign up. Invite me to put my hand in my wallet _before_ signing up, otherwise I feel like there's a little bait-and-switch going on.

Don't take these criticisms as bitter medicine - I think this is a fabulous offering, and that's why I've critiqued it in such detail.

<comment><AUTHOR> Wow thanks for all your time and feedback. I really appreciate it. I'm going to add the price to the demo page immediately, great point. Im going to let the other points sink in a bit and figure out how best to implement them.

drop me an email if you want a complementary account at hv at ownzee.com You have been super helpful!

</comment></comment><comment><USER4> First of all, I quite like it. There's a few things that came across to me as a little awkward though.

• On a small screen [1], the edges of the page get a little smushed up. I'm also not sure if the "learn more" button is supposed to be transparent (it looks like it shouldn't be).

• This window [2] felt like I could move it, but I found that I could not. It's by no means a problem usability wise, but it felt strange that it wasn't possible.

• I sort of expected there to be a "preview" button in the title bar. I realise that it is a WYSIWYG editor, though I'm not sure how the page will look when it's fully published.

• The two sign up buttons look out of place, typically a page like this has one big and loud call to action. The one in the top bar isn't centred vertically either, which looks a little strange.

• The spelling of the buttons "Sign Up" and "Signup" should probably be made consistent too.

It's all nit-picky stuff, but I hope some of it is useful to you.

[1]: <http://i.imgur.com/UhyOrdT.png>

[2]: <http://i.imgur.com/EpG8Jkx.png>

<comment><AUTHOR> Since you edit the actual page, what you see there is the preview/actual page, I should probably do a better job of explaining that. Maybe have a preview button that says that when you click it... The other UI stuff is just laziness in my part. I'll fix it. Thanks!

</comment></comment><comment><USER5> I second the free trial with minimum functionality. Take a look at <https://www.easel.io>. It's somewhat similar (in browser design for bootstrap instead of blogs) and offers a limited trial of being able to create three different pages.

By offering the trial and shrinking the signup form to an email address and password you have less friction, your visitors playing around with it, and you have their email address.

<comment><AUTHOR> Easel.io is great, I've followed them a bit.

I see what youre saying about the free trial, the part Im trying to optimize is getting more people from the demo page to the join page. Adding a free trial on the join page may(or may not) improve signups but only if they go to the join page... Maybe I should combine the demo and join page... Thanks

</comment></comment><comment><USER6> That mouse came out of nowhere and scared me.

I think conversion is based largely on who it is visiting your site. It's aimed at the nontechnical type of person, so getting traffic from somewhere like HN is going to kill your conversion rate. What are your traffic sources?

<comment><AUTHOR> Most of the traffic that signs up comes from google. I had some dumb luck with ranking on the first page of some good related keywords... Other unrelated traffic just bounces off this page... The mouse is really the only idea I can think of to show it's editable right there. I tried a video but most people didnt watch it. It's pretty funn too <https://www.youtube.com/watch?v=yBo4nxoWTes>

</comment></comment><comment><USER7> Your numbers are good. The landing page seems to be working well. Your payment form needs work. From experience it is one of the most crucial parts of your sales ladder.

<comment><AUTHOR> I have some mixpanel tracking on the join page and if a visitor types in a username they will usually click sumbit (even if they dont enter their credit card or have any intention of paying). Since this is the case, my thinking is I need to get more people interested in it before they get to that page. Just thinking of how I buy online, I made my decision to buy well before I pull out my CC

<comment><USER7> You need to reduce the friction to join the service. Right now, you are like a door to door salesman who asks for the sale right from the get go. By breaking up the sales process you can argue away any objection the user may have to paying, and close more sales. I suggest offering a free trial with limited functionality. Have them use the service, and at the end of the trial close the sale. You should gain more sales due to allowing those who are interested to see how it works, and then converting into customers.

</comment></comment></comment><comment><USER8> I got a chrome ad. I would have just left the sight.

<comment><AUTHOR> The created content is viewable in older browsers but to use/create you need a modern version of IE</comment></comment>


Ask HN: Translating Android - <AUTHOR> I would like to translate Android into my native language (Swazi). I am not referring to translating the text in a specific application. Instead, I am interested in translating the core UI/system.
Additionally, I would like to improve the translation for my second language, Zulu, which exists in Android, but would do with some improvement.
Does anyone know how to go about doing that? Searching the web seems to only give me results related to app translation. <comment><USER2> In the Android world, translations are usually found in string resources. See [1], for example.

AFAIK, if you want improved translations, 1) you'd need to either fork AOSP, build a custom ROM, and your users would need to deploy that custom ROM on their devices. or 2) convince Google to accept your changes [2].

Edit: There may be other hacky approaches I'm not aware of. You might find something useful if you trawl the XDA forums [3].

[1]: [https://github.com/android/platform_frameworks_base/blob/nou...](https://github.com/android/platform_frameworks_base/blob/nougat- release/packages/SystemUI/res/values-zu/strings.xml)

[2]: [https://source.android.com/source/contributing](https://source.android.com/source/contributing)

[3]: [https://forum.xda-developers.com/](https://forum.xda-developers.com/)

<comment><AUTHOR> That GitHub link was very useful! Thanks. I will see how far this gets.

</comment></comment><comment><USER3> Consider asking this question on the Android Platform mailing list.

This post seems to be relevant: [https://groups.google.com/forum/#!topic/android- contrib/XKqt...](https://groups.google.com/forum/#!topic/android- contrib/XKqtfeMBMUU)

</comment><comment><USER4> Look at the Zulu translation first to see how it is implemented.

<comment><AUTHOR> I have not been able to figure it out (or any other language translation for that matter). Or Google translates this in-house with no possibility for outside contributions?

<comment><USER4> There has to be a file somewhere that has the translations in it.</comment></comment></comment>


T460s QHD reviewed - <AUTHOR> http://www.notebookcheck.net/Lenovo-ThinkPad-T460s-Core-i7-WQHD-Ultrabook-Review.161028.0.html <comment><AUTHOR> I discovered the thinkpad line about 3 years ago when i started using my company issued W530,before that i was using an EliteBook fan. Lenovo is getting is a lot of criticism from for the direction they are taking on the T series, i for one am a fan.

size and poor screen were my main concern with the T450s , looks like lenovo heard me :)</comment>


AMA with Pia Poppenreiter, Former CEO of Ohlala and Peppr - <AUTHOR> https://womenmake.com/posts/JZy0rtbjFI/ama-with-pia-poppenreiter <comment><AUTHOR> Hi HN, today I'm sharing an AMA we did yesterday with Pia Poppenreiter. She's the former CEO of Ohlala [1], a paid dating app. Although she can't reveal much from her new venture, she answered questions about the sex tech industry among others.

[1] [https://news.ycombinator.com/item?id=12106072](https://news.ycombinator.com/item?id=12106072)</comment>


Why Events Are A Bad Idea (for high-concurrency servers) - <AUTHOR> http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html

<comment><USER2> This article has been on Hacker News in the past (to be fair, I think this post might be about a new venue for it).

The problem with the article is that it's superficial. At its core, it's premised on the idea that threads are inherently easier than events, because they produce straight-line code and automatically handle tracking the state needed across a transaction. If that's true, then the article says threads are just as good as events once we solve all the problems that make threads dangerous or slow.

But it's not a given that threads are easy. In particular, as anyone who has spent time doing high-performance threaded code will tell you, there's the effort you have to put in to make sure your threaded code is _correct_ , and then the 2x more time you have to put in to make sure that it's _efficient_ ; in particular, you have to do synchronization without effectively serializing all your threads. Which is a huge pain.

I think this is gradually becoming a moot point, as modern languages --- all of which have some kind of anonymous function and some approximation of closures --- allow us to write evented code that looks and feels like straight-line code. jQ callbacks in Javascript are the most vivid illustration of this idea (I suppose the node.js people are carrying that even further; I haven't played with it).

<comment><USER3> I think what he's really getting at is that user-space threading is effectively underrated. There are models for cooperative threading using coroutines, such as Ruby's Fiber that are underutilized. One just has to be careful to make sure all blocking operations will suspend and swap coroutines.

<comment><USER2> "Userspace threading vs. event programming" is a fake controversy. Event advocates tend to be userspace/nonpreemptive thread advocates.

<comment><USER3> Not always. Node.js is very opinionated on advocating a closure-based model versus user-space threading.

<comment><USER2> "Closures" and user-space threads are two different approaches to the same end-state, which is code that is scheduled on I/O events instead of timeslices, and that implicitly manages all the state involved in the request.

<comment><USER3> I can agree with you on this abstraction :)

</comment></comment></comment></comment></comment></comment><comment><USER4> In their evaluation it appears they are comparing their server written in C or C++ (since they call OS functions like poll) to SEDA which is written in Java. In the original SEDA paper, if I remember correctly, the authors noted SEDA wasn't as fast as one of the servers written in C that they used for comparison reasons, but the authors were just trying to demonstrate a proof of concept of the architecture.

This doesn't seem like a particularly fair comparison of architectural ideas. A better one IMHO would have been to implement their server in Java or re implement SEDA in C.

</comment><comment><USER5>
      Using the newer sys_epoll system call with Knot avoids this
      problem and achieves excellent scalability. However, we
      have used the poll() result for comparison, since sys_epoll
      is incompatible with Haboob's socket library.

WTH? I admit I didn't read the entire thing (just skimmed), but are they actually comparing threads to poll() and declaring victory instead of epoll()? Intentionally? epoll() is radically different from poll(). Nobody uses poll() for heavy-duty event-based servers. They might as well not have said anything at all.</comment>


Editing distance clusters: a greedy string classification algorithm - <AUTHOR> https://wjholden.com/clusters <comment><USER2> Edit distance for syslog message classification. Interesting!

One notable caveat is that there's no clear axis of classification. Sometimes things may be classified together because they talk about the same resource (with a long name). Sometimes things may be classified together because they have the same message template. Sometimes thing will be classified together because they share a lot of digits of time (not necessarily _close_ in time).

Odds are you get some of each type of clustering.

</comment><comment><USER3> Was just about to say that it doesn't work well with large lists of words because at some point the gaps between words are small enough there's a path right through the entire set which causes them to be "clustered".

      holden
      golden
      golder
      colder
      corder
      border
      bonder
      wonder
      wander
      warder

But I see that once you get longer strings then it works great. I like the log message processing.</comment>


Ask HN: Machine learning careers - <AUTHOR>

I am interested in machine learning and natural language processing, but am slightly put off from devoting a significant amount of time towards it because I am under the impression that to make a career doing this, it is seemingly mandatory to have a PhD and you will be working in a research lab at a large corporation, the government, or a university. Is this true? <comment><USER2> I've worked in image processing and pattern recognition my whole career (~20 years). My last position was as principal software engineer. I don't have a graduate degree so it is certainly possible to work in the field without one.

Many places divide the work between two groups: an algorithms group and a software group. It's going to be harder to get into the algorithms group without a graduate degree (without experience anyway). But if you join a software group, there will be lots of opportunities to solve pattern recognition problems. And if your love is machine learning, you can move in that direction as you prove yourself to others.

I know nothing about natural language processing, but that's my $.02 from my pov.

PS. Hey jbooth: I took a look at your web site. You guys do cools stuff!

</comment><comment><USER3> As many here have answered, you don't need a graduate degree to get into this field and make money. Both myself and my partner at Repustate (<http://www.repustate.com>) have undergrads in CS, but other than that, we just read a lot of published papers from well known experts in the field, like Bo Pang @ Yahoo. She's a great source of information if you're interested in SVMs (support vector machines) and contextual polarity, that kind of stuff. Generally speaking, Cornell University has a really strong library of research in this area.

</comment><comment><USER4> You can easily make a career in machine learning with a Master's degree, and a thesis that focuses on a ML problem.

To work as a scientist in a research lab, you do need a PhD, very few Master's candidates can make it there.

But to work in startups and some large companies doing Machine Learning mostly is not that hard.

I have worked in various companies as a "Research Engineer" and "Data Mining Engineer". I know someone who is a "Scientist" doing NLP in Yahoo Research and has only a Masters.

<comment><USER5> Why do you have scientist in quotes here?

<comment><USER4> Just quoting job titles, since they usually don't mean much usually.

</comment></comment></comment><comment><USER6> If you're in NYC and know more about machine learning than just being "interested in" it, drop me a line at firstname.lastname@example.com. We (along with several other startups) apply machine learning algorithms to big datasets for a business - most of us don't have PhDs.

</comment><comment><USER7> Instead of framing this from the negative, can you frame it in the affirmative. In other words, I know that you don't want to work in a large corp, the gov't, or a university. Where do you want to work?

<comment><AUTHOR> I was a bit unclear, but what I mean is that can I live a life where I build things and get paid for it as opposed to spending time writing research papers and attending conferences, which I am under the impression requires getting a PhD to be taken seriously.

As far as where to work, anything from a startup to a large corporate company could potentially fit the bill.

<comment><USER7> In that case, yes; I think there is plenty of opportunity to use machine learning (from relatively simple implementations to more advanced stuff) in many businesses. For example, I run a simple college admissions website, and we use some basic machine learning techniques. If we're using it, I imagine that nearly every field could take advantage of it in one way or another.</comment></comment></comment>


Apple acquires Shazam - <AUTHOR> https://www.apple.com/newsroom/2018/09/apple-acquires-shazam-offering-more-ways-to-discover-and-enjoy-music/ <comment><USER2> Nice, I heard about this a while ago but it's nice to see an actual press release about it.</comment>