It is fast or it is wrong - <AUTHOR> http://tonsky.me/blog/slow-wrong/ <comment><USER5> The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge. Note the word 'viable'. Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it.

This is the point about Clojurescript too: yes it compiles slower and runs slower, but it allows access to what is essentially the world's largest and most complete UI framework, known as the browser. That makes apps cheaper and faster to produce, at the cost of sluggish/bloated performance. The market has indicated that this is an acceptable tradeoff. Until some other solution can match it on these axes, Electron/Javascript/React SPAs will dominate.

I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. It saddens me to see binary sizes and memory consumption balloon, because native development encourages you to care about these things. But even I cannot deny the order-of-magnitude improvements in productivity from hot-reloading, a deep (if byzantine) system for styling and layout (including text), and reuse of modular components across all platforms.

<comment><USER6> > Those who might suggest that Qt covers that role have to explain why, even > though it has been capable of fast, attractive apps for a long time, nobody > built Slack, Discord, Atom or VSCode in it.

Because those are companies dominated by webdevs that can't be bothered to learn anything else.

Even VSCode is probably a side effect of Microsoft trying to be cool and cattering to the new generations that don't know anything else.

For me, it just made me buy a Sublime Text license instead.

<comment><USER7> VSCode grew out of a project to make a browser-based IDE. So, when they decided to make a desktop-like user experience instead, Electron was the natural choice, as a way to make it a port rather than a complete rewrite.

You could argue that it's a similar story for things like Slack - for business reasons, they more-or-less needed to have a web-based UI. If you're already committed to that, then it makes sense to use Electron in order to maximize your code reuse.

I can't speak to Discord or Atom. Those ones make less sense to me, but there might be a reason there, too.

Speaking completely personally, Qt has never felt like a viable option for a commercial project to me. It does have some bindings for other languages, but, at least last I checked, they're all community supported. When you're talking about language binding libraries, it's reasonable to think of "community" as a polite way of saying "poorly". That can quite justifiably influence a person's willingness to rely on them for non-hobby projects.

I don't like JavaScript much better than I like C++, but at least I can more easily think of business cases for why I might accept being locked into JavaScript. The ones up above, for example.

<comment><USER8> At least part of the reason is probably the lack of a good layout engine that's more flexible than rich text and less complex than a web page. An embedded browser gives them everything they need for their highly stylized layout, but at a great cost.

<comment><USER6> You can do quite powerfull layouts with QML.

</comment></comment></comment></comment></comment><comment><USER9> This is a very silly argument: compile and runtime speed is not the only consideration to take into account.

Otherwise we would all be programming assembly, or heck, just write machine code directly and skip the time-consuming assembler.

Speed is important, but so is good debugger support, productive UI tools, developer productivity, training requirements, available libraries, target market, etc. At the end of the day, most people make pragmatic decisions, taking lots of factors into account.

A good historical example of this is Word vs. WordPerfect. There are many reasons why Word won, but one of them is that WordPerfect was written in assembly. This was helpful at the beginning as it was good for performance, but their developer productivity suffered as the codebase increased. This resulted in fewer features, which is also something that customers care about.

Few customers care how quickly you can do something they don't want to do.

Also, he's conflating toy problems, where getting the big-O right is the only important thing, with real-world applications where the constants are also important.

<comment><USER10> The article is interesting food for thought, but there's a fundamental error. In the toy algorithmic problems, having the wrong big O solution is wrong because it doesn't finish in a satisfactory amount of time. From this he seems to infer that anything that takes longer than another alternative is "wrong." But the thing that made the toy solution wrong does not transfer to the other example problems! An editor dropping frames clearly isn't sufficient to render it unusable for a significant slice of the target audience (proof by existence).

<comment><USER11> Replace 'wrong' with 'sucks' and you'll be much closer to getting what the author's saying.

<comment><USER12> Still doesn't make the metaphor make any sense. If anything, it is proving the exact opposite point since when it comes to programing languages/environments the difference in speed is much more comparable to the 10-30ms from the example (negligible) than to the "years" \- the one being "wrong".

</comment></comment></comment></comment><comment><USER13> He's got some good points but it is a garbled argument.

Really I don't know about JS Hell, but C++ compilers aren't slow because nobody has tried to speed them up, rather the nature of C++ is that it is slow to compile. Every so often somebody rage quits C++ and starts a language like Go because of this.

The real data point is that Clojurescript is only slightly slower to execute than real Clojure, but takes two orders of magnitude more time to compile.

He's right though that people have to move on past Electron. Lately I have been building applications in Python/tkinter and I still can't get over how fast it is on both my mac and PC both to start up and when running. There is none of the "spend 30 seconds watching a splash screen" that we're are accustomed to with advanced applications in Java and C++ (eg. PyCharm and Photoshop)

Another thing that impresses me is the size and speed of small GUI applications written in C for Windows such as this little utility:

[https://docs.microsoft.com/en- us/sysinternals/downloads/disk...](https://docs.microsoft.com/en- us/sysinternals/downloads/diskview)

I think MacOS is also part of the problem. Lately I added a new keyboard to my Mac and I thought I was having Bluetooth problems but the main reason it was unresponsive was that the spellchecking baked into the OS would cause keyboard input to lock up for a few seconds periodically.

Later on I noticed that web browsers on Mac OS (Safari/Firefox/Chrome) seem to "go to lunch" and not respond to mouse clicks for 5 seconds every so often. I imagine this impacts Electron apps.

I think people have been "frog boiled" into expecting computers to be slow.

<comment><USER14> Yes, macOS is gradually becoming slow.

Worst thing is the Finder. Moving files between folders used to be instant. Now it sometimes takes a few seconds for files to appear in a folder after you drop them.

I have no clue why.

I tell myself that the problem is that the old, experienced programmers are leaving, and inexperienced young programmers are too busy adding new features (it works! good enough!) to make sure anything actually works well. And of course that never would have happened if Steve Jobs was still alive. (Just kidding. Steve Jobs loved fancy graphics that made everything slow)

<comment><USER15> > I tell myself that the problem is that the old, experienced programmers are > leaving, and inexperienced young programmers are too busy adding new > features (it works! good enough!) to make sure anything actually works well.

You joke, but this is a real issue. It's hard to find any other explanation for why the quality of commonly-used software has taken such a _massive_ nosedive in the latest 15 years, outside the FLOSS world (CADT syndrome notwithstanding!) even as software was supposed to be "eating the world" by now! Windows Vista, anyone? (Or, as some folks in Microsoft marketing used to call it rather presciently, Windows "Mojave"?) I guess it just goes to show that, yes, systems programming _still_ matters, as do projects that attempt to open it up to a far broader audience while keeping and even strengthening its focus on rigor, performance and correctness.

<comment><USER16> I've been a professional software developer for over 20 years.

Commercial software is generally much better than it was 15 years ago.

Yes, Vista was bad but Win7 was good. You should have seen Win3 or 95 though. You'd expect to have the computer crash multiple times a day.

<comment><USER15> Of course, _anything_ was good when compared with vista. Win 3 and Win 95 are not directly comparable, as they were running on severely underpowered hardware (and they could not pursue the sort of simplification that made OSs on other low-end, "home computer" machines of the day more workable overall); Vista does not have that excuse given the growth in system requirements wrt. its predecessor.

(Even Microsoft had to give up not only on Vista but on Windows 7 itself for "low-end platforms" \- they ultimately promoted a "Starter" version of the latter that was specifically built to never even try to launch more than three apps at the same time! I won't bother to attempt even the most cursory comparison with what a proper, FLOSS alternative can still achieve on the same hardware, even today...that would be tedious and ultimately beside the point.)

</comment></comment></comment></comment></comment><comment><USER17> The first half of this article made me think it was going to talk about how clever algorithms can change a 1 year problem into a 1ms problem, think outside the box, etc. Instead it took a nosedive into complaining about electron, which definitely needs to be complained about, but this felt a bit unfocused.

</comment><comment><USER18> Reading through this reminded me a lot of what Jon Blow has been saying [1] about programming as he's been writing his new language specifically tailored for games. He talks about how ridiculous it is that C++ compiles can eat up so much time in a programmer's day, and how programmers are not generally taught how to write efficient data structures and thing about things like locality and access patterns.

And that's when you can reason about the access patterns. When you're running things out of a browser, you are even further removed from the metal and likely using a grab bag of web frameworks and libraries that you don't control (or fully understand). And it's easier to keep using them rather than think about what it would take to make things run well and invest in that future. (You may not even have the ability to make that decision).

Luckily, it does seem that people are becoming aware of the issue, at least in some circles. I've now seen a number of articles with titles like "Why I have turned my back on the church of Object Oriented Programming," and with people like Mike Acton speaking at cppcon [2] to talk about data structuring, hopefully the next generations of application developers will be equipped to make things fast again.

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

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

<comment><USER19> It feels like large parts of the reason C++ compilation is slow could be solved by modules. Maybe some day?

</comment></comment><comment><USER20> I remember when I tried Atom when it was hype, others loved it but it felt so slow compared to SublimeText and InelliJ. I wrote off Electron apps right then and there.

Then VSCode came along and showed that it wasn't all Electron's fault, there's a right way to do it. With faster platforms what you get is the room to do things wrong (inefficiently) with hardly anyone noticing.

<comment><USER21> My favourite text editor is VSCode.

I use sublime as a notepad.

Tixati is my favourite torrent client.

<comment><USER20> Me too. Sublime's always keep text even when rebooted without save makes it the ideal notepad.

Don't think I run any other Electron apps. Used to run Slack and Spotify but now just pin browser tabs. Some devs run Gitkraken which baffles me.

<comment><USER21> Yeaaa i also used git kraken to learn but now i find it bit bulky.

<comment><USER20> It depends on the hardware and what you're doing.

Admittedly I was running 10ish not-so-microservices on a dev laptop so couldn't really spare the cycles or RAM. Now on a desktop machine with 32GB and more cores I probably wouldn't notice but just don't like the idea of it from my previous experience.

</comment></comment></comment></comment></comment><comment><USER22> Not only are these differences not the high-order bit of programmer time, for most applications they're probably the _lowest-order bit_ :

> So what do these numbers tell us? Basically, to process exactly the same > code, you can either spend ~8 seconds, 24 seconds or 78 seconds. Your > choice.

My choice is I don't care _in the least_ about these differences, and would gladly take the 78 seconds if that slow language had _slightly_ better syntax or was _slightly_ more expressive.

If I were working on a google scale code base and the difference was an hour vs 2 days, I might care then. But for the vast majority of programmers and applications, that's not relevant.

<comment><USER23> Yeah, you're basically treating user experience as an externality, though. The point is that the end user of the program doesn't care how expressive the language is, they care how long it takes to run. And the overhead piles up as the dependency stack gets deeper...

<comment><USER24> But the end user certainly doesn't care how long the program took to compile,which is something the author lumped together with runtime.

But end users do care about programs not crashing and losing whatever they were working on, they care about features, and they care about how long it takes for them to get the features they want, all of which are impacted in some way by the language and tools used by the programmer.

<comment><USER25> I thought the article was alluding to the fact that the same code ran 10x slower in JS, vs jvm

</comment></comment></comment></comment><comment><USER26> > there are two types of solutions you end up with: ones that can calculate > the answer in a couple of milliseconds and the ones that would take years to > finish

This is of course a bit of an overstatement, but I generally agree that (depending on the language you're using, and the problem you're solving), there are quick solutions and slow ones. However, based on the videos he posted, the author seems to have stopped just before the Advent of Code problem most likely to make his CPU cry! Day 14 didn't have an obvious optimal solution, so there were quite a lot of correct solutions that took seconds, not milliseconds. (If you're curious, check out this awesome post from /u/askalski [1] on getting it to run truly fast.)

Humans seem to be naturally inclined to pick the "best" option, and naturally frustrated by the fact that best changes so often depending upon the situation. In almost any situation as a programmer, you're deciding between several competing priorities. There's your speed as a programmer, your code's speed for the target hardware, your ability to get people to help you with the code, either via hires or online documentation, etc.

With regards to Advent of Code (which I also completed this year, and really enjoyed!), the "right" solution in Python could often be hundreds of times slower than the right solution in C or Rust -- just check out the benchmarks for similar toy problems [2]. That doesn't mean the solution is wrong, it just means that the author has decided that a couple seconds of the CPU's time are worth the benefit of using a higher level language, which is often a reasonable choice.

1: [https://www.reddit.com/r/adventofcode/comments/a6wpwa/2018_d...](https://www.reddit.com/r/adventofcode/comments/a6wpwa/2018_day_14_breaking_the_1_billion_recipes_per/)

2: [https://benchmarksgame- team.pages.debian.net/benchmarksgame/...](https://benchmarksgame- team.pages.debian.net/benchmarksgame/faster/python3-gcc.html)

</comment><comment><USER27> Part of the problem is that most of the competition has made it from the 80s or 90s unchanged. For all of its faults, the "web stack" has benefited from far more development than tk or wx. I have tried a few things and web development is the best GUI development experience by a long shot.

</comment><comment><USER28> I mean, for some jobs, you could make the argument "it runs in the browser or it is wrong."

But there's no point in turning something subjective into a one-bit moral requirement. Programs need to be fast enough to meet requirements and people have different opinions about what they require.

There is even an argument that slower is sometimes better. The large tech companies put enormous effort into reducing latency, but I'm thinking of writing a browser extension to add latency to some websites to make them less addictive. Where you stand on this is going to depend on what you're trying to do.

<comment><USER29> > The large tech companies put enormous effort into reducing latency, but I'm > thinking of writing a browser extension to add latency to some websites to > make them less addictive.

That's how javascript was invented, stop trying to do dangerous science.

</comment></comment><comment><USER30> > You don't get anything from being on JS, except a 2× performance hit and > astronomical build times.

Erm. How about the ability to run in a web browser? You know. The single reason Javascript is popular. Maybe that?

<comment><USER31> I think the one thing I appreciate about running in a browser is control.

A native app removes any chance to run an adblocker (I guess it might be possible at the network level) and probably means that you won't be able to add keyboard navigation as you'd get from something like Vimium.

I always find it very jarring to be using something like iTunes and to realise that I can't Ctrl click something into a background tab.

<comment><USER32> With a lot of SPAs, you can't control-click have the components because someone either didn't make it an a tag or didn't make the linked page render on its own.

</comment></comment></comment><comment><USER33> > HTML is a pretty inefficient way to put pixels on a screen.

This is completely true.

HTML is also more than a way to put pixels on a screen.

I'm utterly sympathetic to complaints about Electron apps (which I generally avoid because they feel wrong to me too), and to the idea that the web could/should perform better, and even that it is wrong for many applications.

But if one primarily conceives HTML as a pixel placement scheme, one is goig to make some poor judgments about what it's right or wrong for. This arguably works in tandem with the piece at some points -- "the web" in general (and some specific stacks or architecture choices) is/are probably used in situations it is wrong for because the related tech is what people know rather than because all the engineering decisions involve informed matches between characteristics and requirements.

And yet it reveals some limits about any judgment that the web _in general_ is "wrong," and perhaps indicated the author should have demonstrated more of the wise principle of thinking about what one is getting. If there is one place where "it is fast or it is wrong" is often incorrect, it's in thinking.

(See also: Knuth's rules about optimization.)

</comment><comment><USER34> I would rephrase the title: "It runs on the user's platform or it is wrong."

The example discussed throughout the article is Clujure vs. ClojureScript.

The author takes issue with the difference in compile time (6.5 seconds vs. 78 seconds, respectively).

But this really is an apples/oranges comparison. If the user expects to run the program in their browser, then any solution that doesn't deliver that experience is wrong. End of story.

If the user can't be bothered to figure out how to install your native or byte code binary, then your solution is _wrong_. Find a way to give the user what they expect or stop trying to write software for a living.

Here's a common programmer dilemma:

You are familiar with development system X. However, your users demand that your software run on platform Y. Platform Y doesn't support X natively.

What do you do?

One option is to refuse to learn the development tools for platform Y, bringing shims, transpilers and a bunch of other dreck needed to get X running on platform Y.

But the user will notice the difference and not like it.

You're better off learning the native development tools for platform Y, and delivering a native experience.

In other words, drop ClojureScript and write the application in JavaScript if your deployment target is the Web browser.

<comment><USER35> > You are familiar with development system X.

> However, your users demand that your software run on platform Y. Platform Y > doesn't support X natively. What do you do?

Use Electron apparently…

> One option is to refuse to learn the development tools for platform Y, > bringing shims, transpilers and a bunch of other dreck needed to get X > running on platform Y.

> But the user will notice the difference and not like it.

Exactly. I do not like it at all.

<comment><USER36> I don't like it, but do you remember using QT or GTK apps in Windows or the X shim on macs? Was that really better?

<comment><USER37> GTK+ and especially Qt are still used. Both have had native rendering on macOS for a long time. It seems like some people compare the most polished Electron apps to the least polished examples of other frameworks.

</comment></comment></comment></comment><comment><USER38> So true. The only problem there is no really good cros-platform GUI framework so far. If only there was something like WPF (and in no way inferior to the original) easily and naturally usable with a good selection of programming languages on all the major platforms (Windows, Linux, Mac, Android, Ios) I doubt many people would use Electron. The whole thing about browser-based apps is they run everywhere seamlessly while looking eye-candy, being easy to discover, one-click to run and written in a language with a steep learning curve and that all is for free in whatever a case (while e.g. Qt requires an expensive license if you want to make a non-free app).

<comment><USER39> Qt is LGPL, you don't need a license to maje a proprietary app with it (chromium and thus electron are under LGPL too)

<comment><USER38> Good. I've read at least PyQT required a license. Qt Design Studio (which could be a "killer feature" to attract people to the platform) certainly does and even for a free project acquiring a free license for it is either hard or impossible.

<comment><USER37> PyQt is GPL/commercial. Qt for Python is LGPL.

</comment></comment></comment></comment><comment><USER40> Performance is a tradeoff. Sometimes shipping a feature is more important. Sometimes cross-platform support matters more than native speed. Sometimes performance optimizations are a distraction from other, more important, work.

<comment><USER41> I just wish there was something that had it all! But until that exists, performance is one of those things where you just need to be adequate. Very few people choose between applications based on performance, anyway (and it's usually too late to switch if performance becomes a concern).

</comment></comment><comment><USER42> I agree with his basic premise that if a faster solution exists, it is better, and believe that considering how many users a relatively miniscule development team will impact warrants much more inconvenience on the developers' part to make the users' experience better–an extra couple of days for me vs. possible man-months of lost productivity in aggregate for my users.

Some of the truisms in the article rubbed me the wrong way though:

> It's not that they couldn't build faster. They just choose not to.

I'm not sure I agree and I don't see what it's adding to the argument.

> in the end what matters is if you have a working program on your hand and if > it can produce the answer in a reasonable time. It doesn't really matter how > the developer arrived there.

Is this sarcasm? From my opening comments you'll see I disagree with this. But, I originally thought the author did too.

Then they go on to construct an analogy of a shitty train and an awesome plane that _cost the same_. Where did they get this part from? I thought the reason people chose e.g. Electron vs. native is that there is a _different_ cost involved for the developers?

> It's easy to find excuses why things are the way they are. They are all > probably valid, but they are excuses.

I used to assert the opposite when I was young, to my parents: "It's not an excuse, it's a reason." It's easy to dismiss others' arguments out of hand, but the fact is there is a reason for every decision made, even if you disagree with the reasoning. There is always room for more education. I just don't see how we can make any headway if we ignore each other like this. This reads to me more like "I don't understand why C++ or Rust compile slower."

> We know way faster programs are possible, and that makes everything else > just plain wrong.

It's easy to fall into the right vs. wrong argument when talking about programming–binary logic, tests either pass or fail. But we're in the human realm here, where I'm of the opinion that there is no right or wrong, only consensus. In the case of products, like Slack, consensus manifests as what the market will bear. I might not agree, but for the time being, the industry has deemed it "right."

</comment><comment><USER43> In my opinion, the article serves its purpose: It polarizes. And quite rightly so. While it is relatively easy to develop portable websites, this does not work for real Applications in most cases.

After researching how to create a GUI in Java, QT, GTK+, etc., I found out for myself that a platform-independent GUI design can be a difficult topic, especially when it comes to GREAT usability.

I don't think, that Electron Apps provide GREAT usability - they do their job and are cheap to produce. In a world where JavaScript and browser technologies are used to justify low maintenance costs, better portability and the lack of skills, it can be helpful to critically question the arguments for it, which the author does.

Especially when this attitude only shifts costs from the manufacturer to the customer, e.g. under the time-to-market aspect. While the manufacturer is saving time and money, the users and customers pay for it. And this is the real argument for me - manufacturers want to save costs. Costs for:

\- qualified staff \- maintenance \- portable applications \- time to market

In my opinion the only way prevent more and more Web-Based GUIs is doing it better and being successful with it - not an easy task.

So thank you for this polarizing but interesting article.

</comment><comment><USER38> > The same applies to all languages with terribly long build times. It's not > that they couldn't build faster. They just choose not to. C++ or Rust > program compiles for too long? Well, OCaml could probably compile the > equivalent program in under a second. And it'll still be machine-level fast.

> "Wow, wow, slow down! This is even more unfair! Now it's not just apples and > oranges, now it's toothbrushes and spaceships. You completely ignore what > each language brings to the table. There's a reason they spend so much time > compiling, you know?"

So what's the reason if the resulting performance doesn't differ much? C/C++ build times seem insane to me. Every time I try to install an Aur package and see it starts building C/C++ I cancel it and give up the idea as I don't want to wait a day for my CPU load to drop below 100% and my SSD free space usually happens to be not enough anyway.

</comment><comment><USER44> A discrete compilation step is optional. The most sophisticated way to run a program is within an interpreter where runtime analysis is used to determine which parts, if any, of the program to compile, and with what "flags".

Transpilation, however, is by definition not optional. It is frustrating to hear a complaint about someone who _chose_ to write in Clojure, itself a layer on the JVM interpreter, and then _chose_ to support a transpilation target, Clojurescript. If compile times bother you, then pick another stack. However, if you want to write code in a functional way and target both the JVM and JS, then this is the price you pay.

</comment><comment><USER45> It's exactly apples and oranges being compared here. Languages and libraries or framework overhead is nothing compared to the toll of Big oh complexity. In fact the former doesn't even get multiplied that much as your input is pretty much constant. You start your application once unlike the input to your npow3 algorithm taking in a massive dataset. Also languages can make development more productive, which again is debatable but the slowness isn't comparable to Big O complexity. I am all in for leaner and efficient languages or stacks but I can live with bloated languages as opposed to inefficient algorithms.

<comment><USER11> The author's point is that he wants to live with efficient algorithms, efficient languages and tooling.

It is not an either/or proposition - we can have all the things, or at least something significantly better than the current state of affairs.

</comment></comment><comment><USER46> > Electron text editors can't resize their own window in real-time and drop > frames while you just move your cursor around.

VSCode has no problem doing this on my Mac. I was scrolling through a 4000000 line file the other day like butter.

Win32 however can't resize the most basic window without flickering - which is why every decent Windows app uses its own non-native GUI layer. There's nothing wrong with non-native solutions - they're often _better_. We can have the best of both words. Native on some platforms just isn't that great.

<comment><USER47> "Win32 however can't resize the most basic window without flickering - <USER2> is why every decent Windows app uses its own non-native GUI layer."

This is so extremely wrong it's not even funny any more. WS_CLIPCHILDREN and WS_CLIPSIBLINGS are the key here. Of course, many people don't understand them (eventhough it's not hard and the Petzold came out, what, 25 years ago?) but win32 is very well understood by now and it's trivial to make extremely fast (by today's standards) UI's with it, and relatively easily, too.

<comment><USER48> Not OP, but sure, if I spend a few hours as a new Windows programmer I can finally make my native Windows application not flicker on resize, but that's most likely not it, there's probably a s __tload of other things I have to spend a few hours on to get things somewhat properly-working. It 's a massive cost compared to what default web already offers.

Then I have to repeat that same years-long process for Android, iOS, OSX and Linux.

Or I can just make a web application that's slightly slower. The decision was super simple for me.

F* native development of UIs, it's stuck, everyone in it think it's fine - <USER4> probably is if it's all you do - but what matters a lot of the time is the sum of development cost across all supported platforms. _shudder_ That means it's especially horrible if it's just you developing something, the chance that a single developer could support all of the most used platforms (Win, Linux, OSX, Android, iOS) is so unlikely due to the time required to learn just a single one of those platforms.

</comment></comment></comment><comment><USER49> You can choose to die on the proverbial hill that is "performance", but in doing so all you are doing is looking at the world through a key hole.

When making decisions about software in the world, performance is just one of many considerations. If performance was the only dimension, we wouldn't have had reason to move past Assembly.

</comment><comment><USER50> This is by far the weirdest of all arguments ever. The OP compares faster execution of code to being a comfortable aircraft and slower to an uncomfortable train. What he missed out on is, that it's easier to build out code that may execute slow, but works(making it more comfortable - room for quick changes to the product), rather than making something that takes a hell lot longer to make(and then spend proportionately longer when you have to change something)

I'll take Ruby vs C as an example. If I was to test out a weekend project, I'd rather choose ruby, even if it's going to be slow, as I can focus on finishing everything in the few hours that I have

</comment><comment><USER51> Ask HN: How often is time needed to program the most important temporal measure?

[For non-developers, I'd guess 95%]

</comment><comment><USER52> This seems to be more a benchmark for ClosureScript rather than "the web"

</comment><comment><USER53> I'm sympathetic to some of the conclusions here but jeez, this is a really bad argument. A lot of other commenters point out ways that it's bad, and they're mostly right.

The crux of the issue is that the argument really relies on the notion of comparing two things that supposedly do "the same thing", but you really have to ignore almost everything that could ever factor into the decision between them in order to consider them the same, and what the thing is shifts from moment to moment.

The Advent of Code example is fine. Here, we have two different algorithms that perform the same computational task, and there's a performance gap because they're not the same algorithm and have have radically different time complexities.

In the Clojure vs. Clojurescript example, the author has picked a library that can run tests on the JVM or as transpiled JS code in a browser. The end result code is doing the same thing in a different sense because it implements pretty much the same algorithm (modulo technical differences in the underlying intermediate platforms). But the first performance comparison is between the Clojure and Clojurescript compile times. Trust me, there's almost no sense in which compiling the Clojure language to the bytecode it was designed to be compiled to and translating it into a different high level language in a performance-sensitive way can be considered the same task. So it's unclear why that's supposed to be meaningful. And the test-timing comparison is also a little funny, since the JS still has to be JIT compiled to machine code, which is much more complex than the equivalent bytecode compilation - there's a sense in which it's more similar to the Clojure compilation step (which takes 6.5 seconds) and it happens in less than a second.

But anyway, one can argue that all-in-all it's the same code and it's doing the same thing in the end and the one that does it in the browser is slower. But that's only the case because of that specific choice to compare library tests that can target either the JVM or the browser. That's not a choice that makes sense in general.

You don't pick between those two compilers in a vacuum - you're not going to use Clojurescript unless your code needs to run in a browser. And you _can't_ use vanilla Clojure in that case. If running in a browser is a requirement, then the compile speed and runtime performance of vanilla Clojure is meaningless because it doesn't run on the platform your program is being delivered on. The author is comparing a library that can be compiled either way and run on either platform - but the actual real world code that library is used in wouldn't have that property, and the performance comparison is pretty meaningless.

I'm going to skip the next bit because it goes further off the rails in ways that are mostly unimportant.

I think there are some less charitable ways to read the conclusion, but let's go with this: don't build applications (especially things like text editors) on the web platform, because it's super inefficient. You can make faster applications, therefore, you should.

Here's the thing: you won't, and if you do, they won't succeed. We wish our text editors weren't so resource intensive, but the responsiveness of basic text editing operations isn't what most of us look for in an editor. There are slimmer native text editors out there; their development and the development of the surrounding ecosystem moves incredibly slowly because they weren't built on a pre-existing extensible platform that thousands of developers are familiar with and so very few people want to work on them. And that makes them cumbersome for a lot of tasks, which means a lot of people won't use them.

The platform that our bloated text editors are built on is part of what they do. So a faster editor that isn't built on a familiar, extensible platform doesn't do the same thing faster - it does a subset of the things I care about, at the expense of the reasons that cause me to put up with my current editor's bloat.

You can make a faster X for any X that runs on the web platform, but to do that you're going to have to build it on less general-purpose, extensible technologies, and in many (but not all!) cases, that alone going to doom the project.

And if you want to build something that does all the things the web platform does, but more efficiently, good luck. Sure, HTML/CSS/Javascript are built on a lot of design missteps, so it's theoretically possible, but I think the ship has sailed on starting completely over.

<comment><USER37> You make it sound like Python and Java are esoteric languages and that VS Code has replaced all other text editors and IDEs.

Sublime Text became popular because it was a cross-platform graphical editor that used a popular language for extensions. Atom became popular because it was all that and free. VS Code became popular because it was like Atom but faster.

<comment><USER53> I didn't mean to imply that, if I did. That said, Atom and VS Code did gain a big market share of the text editor/IDE space pretty quickly, and the author called out Atom as something built on a web platform that was slow and bad because it was built on the web platform, and further implied that we could build better a better version of it if we abandoned the web platform.

My point was just that the new editors were successful in the ways that they were (e.g. for web developers working with a quickly evolving language) precisely because of the fact that they were built on an extensible platform, and in spite of the performance issues.

I was an Emacs user a few years back. Then I started writing more Javascript than lisp and picked up React. IIRC the point where I switched to Atom was when the emacs syntax highlighting packages were choking on es2015, but I could get support for JSX and stage-0 ES extensions if I used Atom. If Atom had been built with a focus on performance over extensibility, those features wouldn't have showed up as quickly as they did and I wouldn't have had any reason to consider switching. Atom was extensible (and not uniquely so) because it was built on a browser and didn't have to reinvent the language and concepts that browsers already had for building basic UI features. I'm not sure we're going to see a new, successful IDE for quickly evolving languages that does reinvent that wheel, as it seems the author is suggesting that we do, in the name of performance.

<comment><USER37> Even web developers have always used Sublime Text and Notepad++ much more than Atom in Stack Overflow's developer surveys. VS Code overtook Atom in 2017. GitHub completely rewrote Atom's text rendering last year. Both VS Code and Atom are migrating JavaScript code to C++. Maybe performance matters more than you think.

Atom used TextMate language definitions until recently. VS Code uses an RPC protocol designed to let any editor support any language. Emacs just isn't very popular anymore.

What "basic UI features" are easier to build in a browser?

<comment><USER53> That's interesting - I didn't know Notepad++ still ranked so high.

Oddly enough, I'm actually pretty acutely aware of how much performance matters in this space - at my last job, I spent a year developing an IDE for a custom in-house language/environment with some unusual required features. I looked in to extending existing editors/IDEs. The web-based editors were too slow for my application (which required a very large number of page updates from remote sources) but extending the native editors was an unfathomable pain. When I looked into things that didn't use a browser back-end, I was budgeting a month just to learn enough about their plugin architectures to determine if what we needed was possible without rewriting the UI code from scratch, which I really wanted to avoid. From experience, working with raw Java/C++ UI toolkit code is a nightmare compared to html/js and requires orders of magnitude more LOC just to put anything on the screen that can be interacted with.

In the end, I wrote my own web-based IDE from scratch, using a lot of application-specific performance optimizations that would be really difficult for a more generic, modular system (lots more care about what parts of the DOM to touch and when went directly into the parser than would have been possible with Atom/VSCode/CodeMirror/whatever at the time). I spent 6 months optimizing it and it was only barely fast enough that you could type at close to 60fps in big documents, but I don't think I could have made a native version that worked at all in that time.

So I get it: performance is important, and there are cases where web-based things either don't cut it or are barely acceptable.

My point wasn't that performance isn't important, it's that it's not the only concern and pointing to the relative popularity of editors over time still illustrates that. Notepad++ was released 12 years before VSCode (which has only been around for ~3 years) and has had better performance this whole time, but in the 2018 Stack Overflow survey, VSCode beats it in popularity. So performance can't be the overriding factor in its relative popularity - <USER4> became popular in spite of being slower than things that already existed.

The author of the original piece argues that the whole web-stack is _wrong_ and should be thrown out and replaced with something else, because it's slow and people don't care about how easy it is to develop something if it's slow. I don't think that's true, and the easiest way to see that is to note that we already had faster things that were harder to develop and extend and they're increasingly being rejected in favor of the opposite.

</comment></comment></comment></comment></comment><comment><USER54> Put your money where your mouth is. If you think something can be improved, and the cost of that improvement is justified by it's benefits, then you have a valid business idea.

More often than not, somebody with far more domain specific insight than yourself thought about the same thing, and rejected it, constrained by some other more important issue you can't yet see.

That's not to say that no improvement is possible, just that you are in a global competition with millions of other smart people and moving things forward is hard and takes dedication, not just hand waving.

<comment><USER55> > _If you think something can be improved, and the cost of that improvement is > justified by it 's benefits, then you have a valid business idea. Stop > wasting your time bashing Electron on your blog and start working on your > idea, it could be the most important thing you have ever done and could make > you rich and famous._

To be fair, preventing a small group of people from dumping disproportionally large externalities on everyone else, to extract a little extra profit for themselves, isn't a working business model. If it was, we would have solved global warming and ocean pollution by now.

Slow software in general, and Electron in particular, is a collective action problem. Solid, fast software gets outcompeted by half-assed bad engineering, because the latter can get to the market first.

(Also known as the curse of "worse is better".)

<comment><USER56> Irc has been on the market for a long long time, but slack won anyway.

Maybe the extra features saved users more time then they lost from running bloated JavaScript.

<comment><USER37> IRC is a protocol. Slack is a service. That's another collective action problem.</comment></comment></comment></comment>


Attacking Machine Learning with Adversarial Examples - <AUTHOR> https://blog.openai.com/adversarial-example-research/ <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=13662165](https://news.ycombinator.com/item?id=13662165)

</comment><comment><USER3> Since this blog post was written, the same authors have published further research on transferability which is what really makes these hard to defend against. They even present a proof of concept task that is resistant to transferring (although it is not super practical): [https://arxiv.org/abs/1704.03453](https://arxiv.org/abs/1704.03453)

If it interests anyone, I wrote up a bit about this and other threats related to machine learning models, a few weeks ago: [https://matt.life/papers/security_privacy_neural_networks.pd...](https://matt.life/papers/security_privacy_neural_networks.pdf)

<comment><USER4> A note -- if you're linking to arXiv, it's better to link to the abstract ([https://arxiv.org/abs/1704.03453](https://arxiv.org/abs/1704.03453)) rather than directly to the PDF. From the abstract, one can easily click through to the PDF; not so the reverse. And the abstract allows one to do things like see different versions of the paper, search for other things by the same authors, etc. Thank you!

<comment><USER3> Good point, I updated my link.

</comment></comment></comment><comment><USER5> From what little I have read on the topic adversarial attacks are succesfull on neural networks because in order to train them succesfully we design them to operate on a linear regime as much as possible. This linearity compounded with the high dimensionality of the problem (images) is what makes easy to find small perturbations that make the output oscillate wildly. My point is that "attacking machine learning" maybe should be renamed "attacking neural networks"

</comment><comment><USER6> I wonder if one could introduce a secondary classifier which is immune (or more resistant) to this kind of attack as a fail safe. One idea that comes to mind is to back the neural net with a random forest, which I imagine would be very hard to trick with this kind of attack as a collection of independent (key) weak learners are trained on the data. To trick a random forest, you would have to trick the majority of the trees within it.

<comment><USER7> Here is a paper from Bosch in that direction, it uses a second network to classify examples as adversarials: [https://arxiv.org/abs/1702.04267](https://arxiv.org/abs/1702.04267)

Using a fail safe network is hard because adversarial examples usually have a high accuracy at a false class. So using an accuracy threshold in the main network wouldn't work. Using a network as described in the paper and then a different kind of classifier might be worth trying. But it has also been shown that adversarial examples can transfer to different kind of models (don't know if random forests have been tried as well).

</comment></comment><comment><USER8> Apple has a big problem w this in their personalized app store ranking (recommender system) -- people gaming it.</comment>


A workstation that splits the difference between sitting and standing - <AUTHOR> http://www.gizmag.com/focal-upright-furniture-locus-work-station/23177/

<comment><USER2> seems like a good idea.. considering how much time we spend sitting ... in a typical day</comment>


Samsung Galaxy Ace Plus - <AUTHOR> http://www.crazy4cellphones.com/blog/samsung-galaxy-ace-plus-in-india-specifications-features-and-price.html

<comment><USER2> Does it have the same poor battery as the original Galaxy Ace? Also disappointing that it still uses ARM11, even if at 1 Ghz. I would've preferred a 800 Mhz Cortex A8 chip. We've been using ARM11 for 10 years. It's time to get rid of it.

</comment><comment><USER3> Samsung had already launched its Samsung Galaxy Ace in India; it was one of the best and successful budget-friendly smartphone in India.</comment>


New England Journal of Medicine photo series of medical anomalies - <AUTHOR> https://www.nejm.org/multimedia/images-in-clinical-medicine <comment><USER2> These are just interesting cases that appear in the NEJM's Image Challenge and Image of the Week series and are meant to challenge and educate physicians. If you go to [https://www.nejm.org/](https://www.nejm.org/), you will see a new set each week.

These are not medical "anomalies".</comment>


Ask HN: DreamIT Ventures? - <AUTHOR>

Does anyone have any experience with DreamIT Ventures or has anyone been through the program?  I've applied and got a personal recommendation from some grads I know, and have heard my chances of getting in are pretty good.  Obviously I've spoken with the previous attendees I know, but wanted to gather as much info as I can. <comment><AUTHOR> Clickable: <http://dreamitventures.com/></comment>


Presenting Gen 8 of Start-Up Chile - <AUTHOR> http://startupchile.org/congrats-you-are-now-part-of-the-start-up-chile-network/

<comment><USER2> Congrats to all the finalists. Go disrupt.</comment>


Synergy Aircraft Project - <AUTHOR> http://www.kickstarter.com/projects/launchsynergy/synergy-aircraft-project <comment><USER2> the three things that make this new, as far as i can see, are:

\- the configuration. i don't understand what the aerodynamic advantages of a "boxwing" are, but apparently this has those while avoiding problems with stalling. it's also stronger / more compact and places the engine closer to the centre of gravity than a traditional "propeller at the front" design.

\- the engine. initially, diesel, which is unusual for aircraft, and eventually electric.

\- suction of air through parts of the wing to give laminar flow (reduce turbulence) and so increase efficiency.

a lot of the site reads like over-hyped snake oil, they don't have any published papers (never mind peer reviewed), and it sounds like they don't have good numerical results from full 3d simulations (but argue they are limited anyway). on the other hand, it doesn't seem to be complete bullshit - they have a working 1/4 scale model, for example, and seems to have been accepted into some kind of x-prize-like competition organised by nasa.

<comment><USER3> Yeah I'm not sure this project passes the smell test. I don't know much about airplanes but a few things seems off when I think of this design in terms of basic physics.

The "boxwings" seem to be a worst of both world approach. It ads a lot of surface going across the air and thus a lot of drag, without providing the width which would usually make available the torque necessary for stability and control.

Torque is (force * distance) and, for roll control, this distance is usually provided by wide wings. An airplane having shorter wings would probably go through the air more efficiently (provided you didn't add a second set of wings on top of the first one) but would not provide much control to enable safe flight in all possible conditions. Short wings don't provide much leverage on the roll axis.

It also seems like in this design the top part of the "boxwings" plays the role of the tail of the plane. However, it looks like we get the same (force * distance) problem but on the pitch axis. In order for the tail to give a good amount of torque for pitch control, it has to be located away from the wings and the center of the aircraft.

Again, I'm just guessing based on physics here but since there is no tail other than the one located near the bottom wings, it might be difficult to stop the plane from pitching up or down out of control.

If we were to design planes for efficiency only, they would look like arrows or missile. They would have minimal wings or fins to slow them down. The reason, we have to have things sticking out far from their middle, is to add the ability to safely control them in a wide variety of conditions.

This aircraft has both lots of wing, thus a lot of drag and yet the extra wingage doesn't get the wings positioned away from the center where they would add the most stability and control. Unless the "Laminar Flow", "Wake Propulsion", "Open Thermodynamics", "Subsonic Area Ruling" or the other technobably things mentioned on the website somehow compensate for this, it seems like a lose-lose design.

<comment><USER4> IAAAE (I am an aerospace engineer). Actually, long (or wide, to use your term) wings tend to be more efficient. The term you're looking for is "high aspect ratio," which efficient airplanes (see the Global Flyer, for example) have in abundance. It is the ratio of wing span squared to wing area (viewed from above, not the front). The explanation for why this is true is complicated, but this gives a good overview:

<http://en.wikipedia.org/wiki/Aspect_ratio_(wing)>

<comment><USER3> If I understand correctly, this seems like yet another reason why this Synergy design would be sub optimal. The two sets of short low aspect ratio wings are theoretically less efficient than one set of long high aspect ratio wing. Correct?

<comment><USER4> I don't know what their numbers are, but for an aircraft of its class, the lower wings don't look like they have an abnormally low aspect ratio. The upper wings look to be of a higher aspect ratio than conventional elevators. Since elevators are a source of drag (they usually have to provide some downforce to trim the aircraft in level flight, and you can't make lift without making drag), that could be a win. But then they're close to the CG, so they'll need to provide more trim force (short lever arm as you mentioned), and the advantage might be lost.

Of course there are other factors at work. For example, Jet A carries more energy per pound than 100LL and diesels are more efficient, so you carry less fuel for a given range. But the engine needs to be stronger to run a higher compression ratio, so that's some added weight. Every little design feature of an aircraft interacts with every other design feature. Aircraft design can be a tremendously unintuitive affair. That's why it's so fun.

So, the proof's in the pudding. The ultimate arbiter of an efficient aerodynamic design is its lift-to-drag ratio, or how much drag is generated for a given amount of lift produced. (See <http://en.wikipedia.org/wiki/Lift- to-drag_ratio>) They should be getting good data off their scale model, and if the model's L/D ratio is high and they've done their homework to reflect the full size aerodynamics, then they might have something.

<comment><USER5> Actually, if you read their Kickstarter, they claim to be getting better fuel efficiency with higher cargo weight. They claim this is because it somehow lowers their drag. They also claim that L/D is unimportant for their aircraft, which is why a scaled test is useless to them, even in a wind tunnel. This doesn't pass the smell test for this AE.

</comment></comment></comment></comment></comment></comment><comment><USER6> IMO they get at least 5x of their 10x by using a diesel engine, vs. a jet (inefficient at a range of powers) or avgas (expensive fuel, old designs, inefficient). Just putting a diesel SMA, Thielert, Deltahawk, etc. engine into a Cessna 172 would give you substantial fuel economy and cost savings vs. 100LL. 100LL is also taxed, while Jet-A (which a diesel can burn) has no excise taxes by international treaty (there are some other taxes, especially in the US). It's maybe 2x fuel economy improvement and 2.5x on per-BTU cost savings.

So, it's actually kind of plausible -- the problem is the diesel aviation engines have been VERY slow in coming to market. The main market so far has been non certified use (military UAVs), where eliminating 100LL from the supply chain has huge savings on top of performance.

<comment><USER7> You probably have a pretty valid point. One of my aspiration toys, the Diamond Star DA42 (<http://en.wikipedia.org/wiki/Diamond_DA42>) burns diesel or Jet-A in a internal combustion engines. I forget the economy figures, but I think this plane does quite well when throttled back.

<comment><USER6> I'm not a big fan of twins for infrequent pilots (just based on observing and talking to pilots, not actual flying myself except in a simulator) -- they seem to bring with them a lot of problems. You obviously have more cost and more potential maintenance downtime from two engines, and when one goes out, the asymmetric thrust and other issues often end up killing pilots who would otherwise have probably been able to deal with no power. There are exceptions like over water use, but I would have preferred a super reliable single engine (Cessna Caravan) to the less-reliable twins (King Airs and Shorts 330s) I was stuck on -- they had to use a twin for regulatory reasons, but even the pilots thought a single would be better. And those are professional (military) pilots; for someone who flies infrequently, the risks of an engine failure are lower, while the proficiency in dealing with engine out is probably lower as well. Single + ballistic parachute might be the best compromise, unless you're routinely operating over water.)

Maybe with FADEC it makes more sense; eventually it will de-skill some of the engine management and you'll just pay the higher operations and maintenance costs of the twin engines, while getting the reliability benefit if ones goes down.

I really want a CH-801 (extreme STOL, rough field, slow), or a Maule.

</comment></comment></comment><comment><USER8> Airplanes seem to be the original vaporware at times. All sorts of interesting projects that seems to be getting somewhere and then stop and have no updates for years. Like the ElectraFlyer-X. Kudos to whoever makes the first affordable to fly airplane.

</comment><comment><USER9> The issue isn't the airframe, it's the systems. Take the Cirrus SR22. A fast, modern, relatively efficient aircraft with a full avionics suite capable of instrument flying. It's even got a ballistic parachute so that if anything goes wrong you can simply float to the ground. It's really, really dangerous.[1] Cirrus SR22's crash something like 4 times more often than Diamond DA40s (a similar aircraft).

[1]: [http://sr22.wordpress.com/2007/10/24/general-aviation- safety...](http://sr22.wordpress.com/2007/10/24/general-aviation-safety-and- the-cirrus-sr22/)

Why? Pilot error. A combination of Cirrus marketing their aircraft as a transport solution (which attracts relatively inexperienced pilots) and the comparatively unforgiving airframe leads to high accident rates.

What does this proposal do to solve that problem? It's a novel airframe, sure, but it's not _that_ novel. I can't imagine that it will offer huge efficiency boosts over something like a Velocity XP (which has similar construction techniques and can probably be used with the same Diesel engines).

This is solving the wrong problem. The issues are regulatory and electronic.

<comment><AUTHOR> The issue is cost. They are claiming an order of magnitude difference in price (1 /10th).

<comment><USER10> Yes, _claiming_. I'll be shocked if they can hit a price point below $150,000 even as a kit airplane (which then takes 2-3 years to fully assemble). Maybe they're comparing themselves to something like a Cessna Citation, so yes 10% cost but not what I would call affordable.

<comment><AUTHOR> The cessna citation is a business jet. I don't know what price point they are trying for, but they are aiming for more mass market. The design has no moving parts in the wings and they say the design is amenable for mass production.

</comment></comment></comment></comment><comment><USER11> More description (less sales pitch): <http://synergyaircraft.com/faqs.html>

<comment><USER12> Yes!

The kickstarter page needed a short video talking about each of these points. Not photos or just gubbins.

</comment></comment><comment><AUTHOR> Interesting counterpoint to "forget about the lone inventor in a garage". He is aiming to be disruptive and his 25% scale model is impressive.

</comment><comment><USER13> They are raising money to build a prototype, and it looks like they will succeed with the raise. Congrats to them! The donor levels are mostly just about recognition.

Icon Aircraft (among many others) has been working on the challenge of making flight a little bit more accessible for some time now. Check out the icona5 channel on YouTube.

</comment><comment><USER14> "If airplanes are to re-connect with their potential customers- or their potential to society- they desperately need an update."

Wait, what? Airplane travel is thriving more than ever. Passenger rail is dying, the FAA is forecasting a >4x increase in the number of general aviation pilots in the next 20 years [1], and it's increasingly more affordable for the upper middle class to fly charted jets [2].

[1] [http://www.faa.gov/data_research/aviation/aerospace_forecast...](http://www.faa.gov/data_research/aviation/aerospace_forecasts/2010-2030/)

[2] <http://jetsuite.com/suitedeal>

<comment><USER8> So when will pilots not be paid horribly?

<comment><USER15> I was thinking about this recently - piloting used to be a high skill job, but now pilots are largely relegated to takeoff and landing--a technician's job. I expect more of air travel to be automated in the future (like, why do pilots and ATC speak through a radio instead of using something automatic). More automation -> lower skill required -> less pay in the future.

<comment><USER16> ..except for the law of leaky abstractions, which is what get you accidents like AF447. Until the automation has situational awareness, you still need skilled pilots.

Piloting is still a high skill job, it's just that there's a surplus of young people who really love flying and will accept a crappy salary to live their dream.

<comment><USER9> AF447 was caused by a lack of systems understanding by the pilots. If they had simply done nothing, the natural stability of the aircraft would have kept it flying until the pitot tube de-icers had effect and the aircraft could return to autopilot.

The triggering cause of AF447 was the icing of a pitot tube. The reason the aircraft flew into the ocean more or less fully stalled was poor pilot training and poor human interface design.

I do agree with you that skilled pilots are a requirement. Systems are only as good as their sensors, and lack the flexibility that makes a manned system adaptable. However, AF447 is a fairly poor example of why we need pilots, as it was pretty much entirely pilot error which caused the crash.

<comment><USER16> That's true, however I think it's a good example of why we need skilled pilots that maintain situational awareness.

The accident reports mentions that the pilots did not have training in high altitude hand flying, and the common belief seemed to be that it wasn't necessary because of automation.

</comment></comment></comment></comment></comment></comment><comment><USER17> I'm a tech entrepreneur and MIT grad who is an avid pilot and type rated on single pilot jets. I've personally visited John in Montana. This project is doing groundbreaking aerodynamic work in a garage. It's what America is all about. The science is sound and based on real designs and concepts that have been studied at places like NASA but never implemented due to the risk averse hyper conservative nature of incremental airframe design and certification barriers to entry inherent to the aviation industry. This project is worth backing. John has the goods.

</comment><comment><USER18> Why don't these projects offer a remote control, small scale version as one of their rewards? Or even just sell them.

<comment><USER19> Manufacturing, even on only moderate scale, a remote control airplane would be a whole 'nother affair, I expect.

</comment></comment><comment><USER20> Too much technical aeronautical jargon going on here. As a young lad, I built a box kite. I thought it would never fly, but guess what? It flew very well, thank you very much. I see a flying box kite in the synergy, so let it fly, let it fly, and just get out of my way. Case closed. prove me wrong.

</comment><comment><USER21> Looks interesting, but I don't have time to dig deeper into it at the moment. Anyone in the know care to tldr; this? I'd be especially interested to hear what are the innovations that make this different from existing small aircraft.

</comment><comment><USER22> Good morning, everyone! Thank you for your interest. Synergy's premise is that direct air transport from smaller airstrips at lower-than-commercial speeds is presently inefficient, thus not profitable and therefore underserved. Targeted aerodynamic solutions are necessary and beneficial.

Synergy is a double box tail aircraft that obtains high span efficiency by providing its stability and control through induced drag reduction. Since the tails push down, it is not a box wing, and the physics of this alone are worth your investigation.

What's more, and this is the basis for all the hubbub, it provides powered drag reduction at very high speeds. Both natural laminar flow and boundary layer control are utilized in the wake immersed propulsive integration. This combination of strategies provide significant benefits but is outside the practical experience of much of the industry.

Extensive discussion has been taking place for quite some time about this and some of that is linked here below. We look forward to completing our effort to provide flight test results that corroborate our results so far, which are promising.

I am available to anyone via email or telephone if you have further questions. Thank you once again for your comments. John McGinnis, EAA 797858, AIAA 289792, john (~at~) synergy aircraft (dot) commercial. fourohsix, twofive0, twentytwo twenty.

<http://eaa.org/news/2011/2011-04-29_synergy.asp>

<http://blog.cafefoundation.org/?tag=synergy>

<http://www.youtube.com/watch?v=3UNzch0kuOA> (flyby)

<http://youtu.be/MJIi0zIwdY8>

[http://www.facebook.com/pages/Synergy- Aircraft/1123534221815...](http://www.facebook.com/pages/Synergy- Aircraft/112353422181543)

[http://www.facebook.com/media/set/?set=a.1435870654978.20564...](http://www.facebook.com/media/set/?set=a.1435870654978.2056416.1179309664&type=1&l=cd5c3ad317)

[http://www.facebook.com/media/set/?set=a.2269305930339.21157...](http://www.facebook.com/media/set/?set=a.2269305930339.2115716.1179309664&type=1&l=9655b74356)

<http://www.youtube.com/watch?v=nCqk7HUKMug> (Synergy OSH 11 pt1) <http://www.youtube.com/watch?v=CaVCISch7VU> (Synergy OSH 11 pt2) <http://www.youtube.com/watch?v=PlT4V2r4Oz8> (Synergy OSH 11 pt3) <http://www.youtube.com/watch?v=kOdaI4jQ8PA> (Synergy OSH 11 pt4) <http://youtu.be/OC0itjCeGAA> (synergy Osh 11 pt4B) <http://www.youtube.com/watch?v=gAJ9C5570rY> (synergy OSH 11 pt5)

[http://www.oshkosh365.org/ok365_DiscussionBoardTopic.aspx?id...](http://www.oshkosh365.org/ok365_DiscussionBoardTopic.aspx?id=1235&boardid=147&forumid=175&topicid=3339) [http://www.homebuiltairplanes.com/forums/aircraft-design- aer...](http://www.homebuiltairplanes.com/forums/aircraft-design-aerodynamics- new-technology/10117-synergy-aircraft-22.html)

[http://www.oshkosh365.org/ok365_DiscussionBoardTopic.aspx?id...](http://www.oshkosh365.org/ok365_DiscussionBoardTopic.aspx?id=1235&boardid=147&forumid=175&topicid=3339&page=15)

</comment><comment><USER23> I don't think the critical challenge here is how to design a small sexy "innovative" plane. I think the elephant in the room (I love metaphors) is solving the problem of (1) who we allow to pilot them, and/or (2) whether they can be designed to fly in a fail-safe manner. For those folks who've experienced on a daily basis what the average herp-derp car driver is like, you should, I hope, shudder to think what it would be like if there were millions of those kinds of folks flying small planes around you.

In other words, in a world where everybody has a plane we probably want "planes on rails". Whether physically-enforced or software-enforced.

<comment><USER24> I'm guessing that building a self-driving car is a much harder problem than a self-driving airplane, and we seem to be making substantial progress on the car front.

<comment><USER25> The self-driving airplane pretty much exists. Assuming perfect conditions, an airplane can climb to a desired altitude, follow a GPS course, switch to a nonprecision VOR/DME approach, and follow a precision ILS approach (and descent) to within a few hundred feet of the runway. And that's a Cessna 172 with a mildly recent avionics package -- a modern airliner can take you to the runway surface in zero visibility. (Taxiing and takeoff are still manual operations that require more than zero visibility, however.)

The reason a self-flying plane is easier than a self-driving car is because there is much less stuff in the air than on the ground, and everything in the air has a transponder that tells you its exact location and speed. (Not true of small VFR planes, but transponders are becoming more common and if we really wanted to, we could make them mandatory.) Compare this to a car, where there are kids running into the street, traffic lights, other drivers, loads falling off the back of trucks, and so on. The number of things that can suddenly change the driving conditions are dramatic. In the air, that's not the case; the environment is very controlled and you have an extra dimension to navigate in.

With that in mind, we're still a ways away from untrained people getting into an airplane, pressing a button, and arriving at their destination. But honestly, that's details and risk management rather than a fundamental lack of technology. (What happens if the engine fails? What happens if there's a thunderstorm? The corner cases are why you have trained pilots there to assist the computers. If you're willing to die because of a simple mechanical or software failure, then self-flying planes are a reality today. If you're more cautious, then not quite yet :)

<comment><USER26> Every time I read a comment of this quality and look up at the username, it seems to be you. Thank you for your posts!</comment></comment></comment></comment>


The Strangely Underreported Decline in the Incarceration Rate - <AUTHOR> http://www.samefacts.com/2013/01/crime-control/the-strangely-underreported-decline-in-the-incarceration-rate/

<comment><USER2> If you take a look at the report that was linked you can see the following line:

" Persons supervised by the adult correctional systems include those in the community under the authority of probation or parole agencies that supervise adults and those in the custody of state or federal prisons or local jails."

It doesn't look like private prisons are included. Which means prisoners could be offloaded to the private sector making the public sector look much better. I dug around for a few minutes and couldn't find any statistics on the number of inmates in private prisons, so I don't know for sure if the number of incarcerated inmates in private prisons rose from 2010 (the last year of stats I could find) or not. But it is still some food for thought.

<comment><USER3> I would have expected privately-operated prisons to still be classified as "state or federal prisons", but I'm no expert.

<comment><USER2> You are correct. After a little more digging, I found this:

"BJS's official measure of the prison population is the count of prisoners under the jurisdiction or legal authority of state and federal adult correctional officials (1,598,780 in 2011). The jurisdiction population count is reported in Prisoners in 2011, BJS website, NCJ 239808, December 2012. These prisoners may be held in prison or jail facilities located outside of the state or federal prison systems. The prison population reported in table 2 in this report is the number held in custody or physically housed in state (1,289,376 in 2011) and federal (214,774 in 2011) adult correctional facilities, regardless of which entity has legal authority over the prisoners (appendix table 1). This includes state and federal prisoners held in privately operated facilities. The difference between the number of prisoners in custody and the number under jurisdiction is the number of state and federal prisoners held in the custody of local jails, inmates out to court, and those in transit from the jurisdiction of legal authority to the custody of a confinement facility outside that jurisdiction."

from <http://bjs.ojp.usdoj.gov/content/pub/pdf/cpus11.pdf>

</comment></comment></comment><comment><USER4> Perhaps this is related to the decriminalization of marijuana in some states at that time.

I welcome this news. We have far too many prisoners; any reduction in the incarceration rate is a good thing, and we have a long way to go.

</comment><comment><USER5> This was just talked about on EconTalk, a great podcast. [http://www.econtalk.org/archives/2012/12/pettit_on_the_p.htm...](http://www.econtalk.org/archives/2012/12/pettit_on_the_p.html) (link includes transcript if you don't like podcasts)

Ironically, the researcher being interviewed is pretty negative on the whole situation, given that we are still a world leader in incarceration. It's a useful discussion even if you disagree with her, because I think she puts some useful data on the table.

</comment><comment><USER6> It's still higher than any other large country in the world (and probably any other country period): [http://www.prisonstudies.org/info/worldbrief/wpb_stats.php?a...](http://www.prisonstudies.org/info/worldbrief/wpb_stats.php?area=all&category=wb_poprate)

(The article is about the decline in the incarceration rate _in the U.S._ )</comment>


The Tech Industry's Gender-Discrimination Problem - <AUTHOR> https://www.newyorker.com/magazine/2017/11/20/the-tech-industrys-gender-discrimination-problem?mbid=social_twitter <comment><USER2> Regarding Vandermeyden's experience with Tesla, I don't know why companies always give the trump card to their HR department and disregard the stated good intentions of managers and leaders.

The cynical view, that managers are lying when they claim to care about equal treatment, severely diminishes employee morale and engagement. The optimistic view, that managers mean what they say, is completely undermined when employees wanting to improve the organization are ambushed and shown the door.

Managers that care about their organization's future health should have a more active role in the inevitable HR/employee discussion so that HR has a better understanding of the organization's priorities.</comment>


Algorithms in the Real World: Host Matching - <AUTHOR> http://www.anishathalye.com/2015/09/24/algorithms-in-the-real-world-host-matching/ <comment><USER2> Neat.

I wish there were a collection of such things, where data-structures and algorithms are used in real life (or even at places where it's not visible in everyday life, like inside the Operating Systems).

At [http://interviewkickstart.com](http://interviewkickstart.com), we love these little nuggets. They make interview coaching fun and very real.

<comment><AUTHOR> Yeah, one of my friends was talking about that too. It would be really cool to have an "Algorithms in the Real World" series.

At school, people sometimes complain about the seemingly esoteric stuff we learn in algorithms classes, and it would be great for people to see real-life examples where algorithms knowledge is necessary.

<comment><USER3> Kind of like this but with real world case studies: [https://github.com/tayllan/awesome- algorithms](https://github.com/tayllan/awesome-algorithms)

</comment></comment></comment><comment><USER4> Wrong solution to the problem. Matches can be unsatisfying for both parties. "Why do I have to be with this guy". It is much more efficient to let the students browse profiles and choose themselves. They will feel empowered</comment>


Idea: Reversed news - <AUTHOR>

First of all pardon me in advanced if my english doesn't make sense to some but i try to define my ideas that got struck me yesterday the best i can.
Here is it:
news/articles based on people comments, contrary to traditional way which the news/articles that people comments on. In other word, comments that produced a news rather than news that generated comments. It work like this: people will given a specific topic (or any topic at all) to comment on. from all that comments then a selected few that relevant or the best in that sense will be a based on or references as to produced the news or an articles.
I dont know if this make sense, but if anybody got what i mean, please describe it better. Is it something like that? <comment><USER2> If I'm understanding you correctly, how is this different from something like reddit or digg? You can read the discussion on reddit before reading the actual news.

Unless I'm misunderstanding.

<comment><AUTHOR> yes u misunderstood it.

on reddit/digg, people submit the actual news link that generated the comments based on that news

my idea is, people submit the comment first on any specific topic that result people produced a 'news' based on that comments

<comment><USER2> Perhaps "news" is the wrong term to use then?

In my mind, news if referring to an event that has occurred (even if that event is the stating of someone's opinion)

Maybe "article" is a better term, or even "essay".

Someone chooses a topic, people discuss it, and then someone works that discussion into an essay about that topic.

</comment></comment></comment><comment><USER3> This is like contextual advertising, such as Google Adsense.

<comment><AUTHOR> probably but with actual human touch instead of bot

</comment></comment><comment><USER4> Isn't that called a forum?

<comment><USER5> I don't think that is what the OP is saying, but maybe I misunderstood too.

It's kind of like a forum where at the end somebody writes an article describing the pertinent information in the thread. It's an interesting suggestion - not sure what the practicalities are, but you know those forum threads where entry #1 is a question ("How do I do X in Y"), #2-5 are requests for clarification, #6 is an answer, #7 points out the answer is wrong, #8 is another answer, #9 is a caveat on the answer, #10-#12 are ofshoots about whether #6 is wrong, #13-#15 are about somebody's avatar, and so on.

So I think the OP is postulating an "article" that says "In order to do X in Y, and as long as #9, then #8." where this "article" was _caused_ by the forum thread.

<comment><AUTHOR> EXACTLY, thanks for the details :) may be the practicalities is stil unseen but i think it is fun to know that your comments getting buzz. maybe we can call it custom news, similar to threadless doing custom shirt where at the end the highest vote got selected</comment></comment></comment>


Ask HN:Should I Optimize my website if I plan to rebuild it? - <AUTHOR>

I have a website at http:://www.safeb4sorry.com  the person who originally developed it did not do a great job at programming / optimization.  Though I am not the best programmer I did dabble in coding a while back so I know that it wasn't done that great.  I plan to pay a real developer to go in and change it once I get the funds together.
Should I optimize the page still even though I plan to change it, or should I wait until its been re-developed?
The Domain Name will stay the same.
Thanks, <comment><USER2> What's wrong with the way its built now? Hard to tell from the pages

Is there any heavy lifting backend code in this project or is what we see all there is to it?

<comment><AUTHOR> I am not sure how to answer that question. I know that no optimization was done to it during its build and that some of the pages aren't coded the same when I do a Dreamweaver / view source.

<comment><USER2> What kind of optimization are we talking about? SEO?

If its all front-end code you see in Dreamweaver, you'll probably end up cleaning that when you do a next major redesign, you shouldn't waste time on it that you could be using to enhance your product in other ways.

<comment><AUTHOR> So what are some things that I could do outside of Front End SEO. Keep in mind that I sell Life Insurance so the main objective of the page is to Create Real Time Leads.

Thanks,</comment></comment></comment></comment>