Show HN: 300k lines of Java UI code running native in browser at desktop speed - <AUTHOR> http://reportmill.com/snaptea/RM15/ <comment><AUTHOR> This uses TeaVM to compile Java to JavaScript. Launches faster in browser than the desktop (once cached). Download is 1.2mb (compressed) - much smaller than desktop version. Runtime speed seems the same as desktop.

[http://teavm.org](http://teavm.org)

<comment><USER2> > compile Java to JavaScript

If we would travel back in time to the nineties and tell them we have technology that compiles Java to JavaScript they would put us straight to a psychiatric hospital :D

<comment><USER3> The technology has been around for over ten years - I believe Google Web Toolkit (GWT) was available in the mid 2000's, which also compiles Java source to Javascript.

<comment><USER4> GWT is a little different in that it didn't use HTML Canvas to render the UI, but rather the DOM.

<comment><USER5> I believe the GWT was aimed at AWT rendered on the web and I am also not sure it was "compiling" it as much as it was translating it.

<comment><USER6> The first statement is false. GWT defines it's own widgets, not AWT or Swing. The second statement is true - GWT is a transpiler. It would be very interesting if GWT could operate on bytecode but that's probably a very different project.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is an impressive feat of engineering. But unfortunately, the resulting UI is completely inaccessible to blind users with screen readers, and probably users with some other disabilities as well.

This will not be easy to fix. AFAIK, if you're using Canvas or WebGL, the only way to make the application accessible is to construct a parallel accessible HTML tree that's completely covered by the canvas via CSS. Note: Don't use "display: none" to hide the accessible HTML tree, because then screen readers will ignore it.

I'm reluctant to rain on your parade, because as I said, this is an impressive piece of engineering. But for the best accessibility and performance, I believe it's better to accept that the Web platform won, and target it directly with a UI that's native to that platform.

<comment><USER8> Um, you can't make paintings accessible to blind people nor can you make downhill skiing accessible for four-limb paraplegigs.

There is a public domain within which most disabilities should be catered for but you can't expect that every non-private thing is made public so it's usable by all.

Just because something is 'in the web' doesn't mean it's a public service, access to which is a basic right.

It's good to be reminded to take into account disabilities, of course, since those are not obvious to people who do not have disabled people nearby.

<comment><USER9> "can't" is a pretty strong term. Up until recently, people would have said that you can't make Olympic sprinting accessible to someone with no feet, but it turns out in fact you can, with sufficient application of technology.

So the real question is always whether the technology to make something accessible exists and whether it can be deployed reasonably in the particular instance involved.

<comment><USER10> They didn't change the race though, they changed the person running it by giving them pseudo-feet. To continue your analogy, in order for a bling person to use this we just need to give them pseudo-eyes.

<comment><USER9> That's a worthwhile goal in itself, sure. But I think you're reading too much into what I said. I never claimed the two situations were identical or analogous, just that "can't" is something that needs to be periodically re- evaluated.

But if you do want to press on with sprinting events, note that they have been using start signals with both an audible and a visible component for a while, to accommodate people who may not be able to perceive one or the other. Back until we had electronically-triggered lights, you "couldn't" have a deaf competitor compete, modulo smoke from the starting gun. Now you can.

</comment></comment></comment></comment></comment><comment><USER11> Compile-to-JavaScript technologies have come a long way and seem well-suited to porting certain legacy applications to the web as proof-of-concept projects, but I think an API-first approach supporting a lightweight, HTML/JavaScript web framework would have required a justifiable, moderate additional effort, and would not only run faster, look and feel more contemporary, and be easier to maintain, test and deploy, but would put you in a better position to add new functionality going forward.

<comment><AUTHOR> I would agree if the goal is just to build a web app, however, if you want to run natively on multiple platforms, Java still has its good points. If you really run a particular app on a daily basis, it can be nice to have an option for a dedicated desktop app.

We may see more of this with WASM. And JavaScript can get a little unwieldy beyond 100k lines of code.

<comment><USER11> It's those multi-client scenarios for which the API-first approach is a perfect fit, actually. Once the API is hammered out, it forms the common foundation for building gui's, cli's and even machine-to-machine interfaces. As a stepping stone, web applications can be deployed as hybrid mobile apps using something like Apache Cordova, even as fully native apps for Android and iOS are under development. Once you've implemented something like this, it's hard to go back to monolithic codebases. Caveat: this is predicated on having an API server and requiring an Internet connection. Writing a connectionless app this way would require some additional effort, though still quite do-able.

</comment></comment></comment><comment><USER12> This reminded me of the talk "The Birth and Death of JavaScript" (2014) by Gary Bernhardt, where he goes into some of the more absurd possible implications of what happens when applications cross-compiled to JS approach or surpass traditional desktop performance: [https://www.destroyallsoftware.com/talks/the-birth-and- death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of- javascript)

</comment><comment><USER13> No, this is definitely not running at desktop speeds. I have a Ryzen 7 2700, and this thing lags often even with basic UI operations (clicking buttons and menus, dragging objects). Now imagine someone with a dual-core laptop CPU... this will be even worse. It certainly feels like this is a web app rather than a native one.

<comment><USER14> Well, it's written in Java, so desktop app probably lags as much. So title does not lie :D

<comment><AUTHOR> Now that hurts :-). Java has been pretty amazing for many years. Many Java desktop apps ran poorly because they were written poorly.

I used to give demos of the Swing version of this app 15 years ago, and people would try to convince me that my app was written in C, because a Java app can't run that fast. Those were weird conversations. I'm not even that clever - I just try to write simple code.

<comment><USER15> This is my experience with java > 7\. The JVM with default settings is pretty excellent these days (see JetBrains IDEs: they're MASSIVE but they run just as well as any other native desktop app.) The issue as far as i see it is that the "enterprise" way of thinking that has and still does dominate the majority of development that results in java code is so bad that it starts to seem like its the language/runtime.

<comment><USER16> >they're MASSIVE but they run just as well as any other native desktop app

Not for me. They're starting up long, UI is laggy. In comprasion to native IDE like Qt Creator they're really slow.

</comment></comment></comment></comment></comment><comment><USER17> I went in with low expectations, but this works surprisingly well on iPad.

<comment><AUTHOR> It even runs reasonably well on iPhone - though squinting required. And an Apple pencil doesn't hurt, too.

<comment><USER18> As long as you don't try landscape..

</comment></comment></comment><comment><USER19> This is fantastic. I tried it out and works very well. I am self taught python and a bit of javascript to put front end to python servers. I have not really ventured outside that landscape as it has worked well for last 4 years or so for me so please excuse ignorance.

My understanding is in this high performance CPU landscape Java apps should work well on all popular desktop platforms and to have it compiling to a web UI like this makes it even more powerful.

How does including existing Java libraries like GeoTools [http://docs.geotools.org/](http://docs.geotools.org/). What are good resources to read to understand the limitations of TeaVM?

</comment><comment><USER20> It's cool, but it runs at about 10 FPS at best for me :P

<comment><AUTHOR> What browser? I get at least 50 fps on Chrome, Safari. Firefox does seem about half that for me though.

<comment><USER20> Firefox. It's slightly better in Falkon, but not much.

<comment><USER21> Firefox always has lacklustre performance on JS-heavy apps.

That's why I still haven't made the switch despite all the claims of "it's just as fast as Chrome in benchmarks!"

<comment><USER22> Yep. We have Atlassian at work and it's pretty much unusable on Firefox because of this. Buttery smooth on the same system with Chromium.

Installed an "app shortcut" with Chromium and couldn't be happier.

<comment><USER9> Is there some public URL that would show that issue? I'm happy to take a look at what's going on with Firefox here, but could really use something to work with...

</comment></comment></comment></comment></comment></comment><comment><USER23> this makes me think of Qt in a web browser using WebAssembly [0]

I find it really impressive that desktop applications can now run quite smoothly in a web browser. In like 15 years we've made it from phpbb forums through 56k modem, to this.

Congratulations

[0] [http://example.qt.io/qt- webassembly/widgets/richtext/textedi...](http://example.qt.io/qt- webassembly/widgets/richtext/textedit/textedit.html)

</comment><comment><USER24> Seemed to freeze up after I loaded a sample and clicked a few things inside it

<comment><AUTHOR> I just got it running in the last couple weeks - still doing some QA to find issues, but in general they have been easy to resolve.

</comment></comment><comment><USER25> Performs better than most websites which intentionally target JS

<comment><USER26> You mean the DOM. The web isn't slow because of JS.

<comment><USER27> Slow is relative, and JS is slow relative to WASM.

<comment><USER28> I can't tell what you are trying to refute in your parent comment.

<comment><USER27> I'm saying that the web _is_ slow because of JS, not just the DOM (though I'm not contending that the DOM isn't the bigger issue).

<comment><USER26> No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT webassembly.

<comment><USER27> Again, slow is relative, and JS is slow relative to WASM. That should be obvious, but here's a source.[0] A demo working smoothly does not mean that a language is not slow compared to another. Besides this point, there are some very processing heavy tasks that we're throwing in browsers these days; this demo is not representative of everything we expect browsers to run. And if you read the other comments here, some people were having lag issues with the demo anyway.

[0]: [https://hacks.mozilla.org/2017/03/why-webassembly-is- faster-...](https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than- asm-js/)

<comment><USER29> No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM _was not designed to run languages like Java_ , at least in version 1.0. Here are the reasons:

* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. _There 's no way in WASM to walk the stack!_ You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).

* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). _This is not supported by WASM_. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.

* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.

* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.

So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to _just give access to stack_ , perhaps in some limited way (for security reasons).

And yes, the lack of access to stack even affects C code. For example:

int i = 23; foo(&i);

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> TeaVM and DukeScript looks pretty cool.

Similar effort in Clojure or ClojureScript - [https://github.com/oakes/play- cljc](https://github.com/oakes/play-cljc)

It's more intended towards Game development though.

</comment><comment><USER31> Related would be JWebAssembly (Java to WASM compiler): [https://github.com/i-net-software/JWebAssembly](https://github.com/i-net- software/JWebAssembly)

</comment><comment><USER32> Serious question, Are the days of native applications UI (be it Windows/Mac/Linux) are numbered? Does it make sense to develop a native application now days? (games and heavy CAD software aside)

<comment><USER33> Cross-platform UIs have been around for ages; QT goes back 30 years.

The pattern that Electron and such are continuing is that they do a base set of things well, but then integrating with OS services is non-existent, even though for any given OS it's relatively trivial.

Don't be too impressed that it can run anywhere at acceptable speeds; Java solved that 20 years ago.

Rather, it's more fundamental: as you add in all the functionality provided by various OS's you have to model all that functionality and it has to be comprehensible to your users and maintainable by you.

Some of that functionality is flatly contradictory and much of it is peculiar to a small audience. You can theoretically engineer around it, but in practice, you won't be able to maintain it and no one will want to use it. That's an intractable problem.

That's why I think cross-platform framework authors have consistently been leaving various bits of functionality out for decades. They'd rather deliver "second class" applications than nothing at all, and that's a smart trade-off.

But that does leave a lot of space for native apps.

</comment></comment><comment><USER34> This doesn't support native high DPI rendering. I think it's rendered at low DPI, and upscaled/blurry on my laptop. Other commenters have stated that it uses canvas.

<comment><AUTHOR> It uses HiDPI on my retina MacBook on Chrome/Safari/FireFox. I haven't tested HiDPI on Windows yet, maybe I'm missing something there.

<comment><USER35> Windows 10 with 125% it is little bit blurry, but so are most of the apps which does not use vector graphics.

Anyway for me it looks good and very fast!

</comment></comment></comment><comment><USER36> This is pretty awesome. The UI load time and responsiveness are vert impressive. I hate web dev with a passion and I've been looking for something like this.

</comment><comment><USER37> Hmm. I have 4-core i7-4770, but the UI on this thing lags a lot, all widgets generally feels sluggish. Such graphics operations don't require a lot of CPU, though, remember that we used to have 200 MHz Pentiums?

On Firefox it's even worse, looks like it was rendered by 4 MHz Apple II. :|

But if it allows easy porting of a Java app to a browser, then this is still great stuff. Not the most responsive UI, but in case of emergency, why not?

</comment><comment><USER38> This is awesome! Great work. How does this work on older browsers? It would have a leg up on current web assembly if it's backwards compatible.

<comment><AUTHOR> I haven't done much testing on older systems. I'm looking forward to WASM, though. TeaVM has an option to compile there, but I haven't tried it. There's a bit of code that should benefit from WASM - and when threading is standard, that will be a big advance as well. Also WASM's ability to compile while downloading should be nice.

</comment></comment><comment><USER39> This is fun. So basically the web browser becomes a sandbox for Java.

Maybe we can get Spring Boot running in TeaVM instead of Docker. ;)

<comment><USER40> This was one of the original selling points for Java back ~2000.

<comment><AUTHOR> I suppose the plug-in/Applet approach is why it didn't fly - same reason Flash has gone away.

It's unfortunate Oracle hasn't adopted the approach of treating the browser as a target platform. TeaVM and CheerpJ have just a couple engineers working on this and they've done great things. A fully supported effort could really make this take off.

</comment></comment></comment><comment><USER41> Very cool! I used to dev Java desktop UIs and applets, really impressive to see this running on a phone

<comment><USER42> I made a game as an applet a long time ago. This makes me want to find that old code and try it in TeaVM.

</comment></comment><comment><USER43> This is insane. The thing actually runs really well. Can it run pure JavaFX Applications as well?

<comment><AUTHOR> No - this app uses a UI kit called SnapKit (available on GitHub). It's kind of a composite of Swing and JavaFX. Like those, it abstracts drawing and user input, so that on the JVM it uses Java2D/Swing and in the browser it uses DOM.

There's a product called CheerpJ that compiles Swing apps to the browser. I'm not sure when/if we'll see JavaFX.

</comment></comment><comment><USER44> Wow impressive! This runs really well on Firefox on a Ryzen 7 1800X.

</comment><comment><USER45> It runs slightly worse than most java UIs for me on a Dell + i7 + Chrome, for me.

I also could not use any keyboard shortcuts, and the edit menu options did nothing at all.

Despite that, it really exceeded my expectations.

</comment><comment><USER46> Cool as a demo but not really something I recommend other than as a way of salvaging low value legacy java applications (of which there are a lot) where the UX is secondary to the ability to keep the application in a functioning state and where it is not feasible to build a replacement.

OpenJdk in wasm might become a thing actually. The download size is not going to be very nice of course but might be acceptable for an intranet type thing that people want to keep alive for whatever reason.

Wasm might soon enable a lot of things that are currently hard and make them both feasible and common again. Flash, silverlight, and shockwave could be kind of nice back in the day and it used to do a lot of things (some of which hopelessly misguided) that are still quite hard to pull off with modern web applications. Most games have better looking and more responsive UIs than many websites. Stuttering laggy divs with broken animations, hover effects, etc. are not a substitute.

I recently got involved in some front end work as I inherited some of that when one of our people left. I must say I find this stuff super tedious to deal with and disappointingly primitive after basically not having done any serious UI work for most of this millennium (usually stick to backend). I suck at this obviously but it seems things could be improved in many ways by rethinking a few things.

IMHO, some native UI kits adapted to WASM combined with modern yet powerful languages like Kotlin, Swift, C#, or Rust should be running circles around most frontend teams in terms of performance, productivity, and quality once this stuff matures a bit.

Scriptable DOM trees as a side effect of browsers exposing their internals to a hacked together bit of scripting language seems to have snowballed into this everything is a document but not really paradigm where you have this unholy mess of nodes and events tied together by a language that is continuously patched up to make this less painful but hopelessly stuck in its own history.

Apologies for the Friday afternoon rant but I've been staring at some example of modern web development the whole day and have a stiff neck from shaking my head in disgust.

<comment><USER47> > _Cool as a demo but not really something I recommend other than as a way of > salvaging low value legacy java applications (of which there are a lot) > where the UX is secondary_

Are we talking about the same app?

The UI here is better than most web SPAs (and where it's not, it's not because of the libraries used), and indicative how more uniform, streamlined, and familiar web apps could be if we had gone with a rich widget set and layout engine (like Java has and this uses) from the get go.

<comment><USER48> Absolutely. Doing "UI's" with the DOM (HTML / CSS / JS) was a big step backwards. We've spent two decades trying to graft an application platform onto a document delivery system.

</comment></comment></comment><comment><USER49> is it possible to port other java project to web version? at my work we are heavy users of jaspersoft Ireport. but anyone working with it can verify that working with ireport is quite a hell... - problems with different versions of java, different jars, problems running report on production etc.... So I got an idea of creating a web based ireport where everyone editing it would be working on the same version of software.

<comment><AUTHOR> It's a bit of work for a typical Swing app using this technology (TeaVM) which has a small runtime. However, there is another Java-to-JS compiler called CheerpJ which handles many Swing apps without much work. The only downside is a larger runtime, so apps can take a bit to launch.

I'd love to hear more about your idea for web based ireport. Send me a note at jeff at reportmill if you want to chat (or call the main line).

</comment></comment><comment><USER50> I have mixed feelings about this. Is that a good thing? Should we now get back to writing Java UIs and then just compile them to javascript?

<comment><USER51> We did. It was called GWT and it was aweful. Lets not.

<comment><USER52> GWT has its strengths (it's been doing the equivalent of tree-shaking and dead code elimination since 2006).

I use it daily at work. It's an impressive feat of engineering with a lackluster ecosystem and inconsistent documentation. Although it's not dead yet (at least technically) as it still has (slow) active development happening.

<comment><USER53> What is your opinion on the compile time though? No matter how I feel about what it actually can do I just can NOT get over the compile time.

<comment><USER52> In my day to day there's about 30 seconds for a cold compile (which is rare, only when I clear byte caches) and maybe 5 seconds usually, less if I've just changed one line or something small like that.

That said we're not using GWT for CSS, so that reduces iteration time where it's most noticable.

</comment></comment></comment></comment></comment><comment><USER54> Please for the love of god, no. Just no.

</comment><comment><USER40> Java applets are back?!

<comment><AUTHOR> This is really a Java desktop app compiled to the browser. Oracle/Sun probably made a mistake by not thinking of the browser as just another target platform (in full-screen mode). The separate Applet concept probably added an unnecessary layer of complication.

</comment></comment><comment><USER55> Interesting as a demo, but nearly unusable in practice.

<comment><USER4> I suspect you're right, but explain your reasoning?

</comment></comment><comment><USER56> So yay? I can write Java again instead of JavaScript? Yuck...

<comment><USER57> Yeah, I hear you. Replacing 10s of thousands of JS lines with 100s of thousands of Java lines doesn't feel like progress. Most Java (only) programmers look at JS as an "inferior, weird" language, but it's actually much more powerful and concise if you dig into it.

However, there are other, better (than vanilla Java) languages that generate class files for the JVM which this tool can apparently convert to WASM. Might have some redeeming features. Clojure to WASM maybe???

It's not like CSS is all that fun — this approach gets rid of DOM manipulation for use-cases where a more pure graphical layout is appropriate.

<comment><USER4> >Replacing 10s of thousands of JS lines with 100s of thousands of Java lines doesn't feel like progress.

In no way is that true.

<comment><USER57> Compare something like Java Spring dependency injection of "service" classes to code using partial function application and higher order functions.

E.g. - [https://ramdajs.com/docs/#partial](https://ramdajs.com/docs/#partial)

Of course, I'm assuming that the JS programmer is exploiting FP and dynamic types, and not just transliterating Java style static OOP code.

</comment></comment></comment></comment><comment><USER58> OP posted the same story two years or so ago:

[https://news.ycombinator.com/item?id=15357394](https://news.ycombinator.com/item?id=15357394)

<comment><AUTHOR> True, but this version is a game changing update - takes seconds to load instead of minutes, runs much faster and is much more complete.

<comment><USER58> Ah, OK. It does seem quite snappy on my system.</comment></comment></comment>


The Fifth Generation Computing Project - <AUTHOR> https://scottlocklin.wordpress.com/2019/07/25/the-fifth-generation-computing-project/ <comment><USER2> This entertaining essay captures things well without getting distracted by some of the really funny stories, many of which cannot be repeated as the protagonists are still alive.

Programming in Japan is typically a low-status job considered a blue collar occupation (Nintendo and SCEI are notable exceptions) despite Japan having produced quite a few globally notable computer scientists. I remember visiting a 5 Gen project om 1984. I was shocked by the open plan office (how did anyone get any work done?). At the row of desks was one ASCII terminal for each two desks (to a KL-20 I assume but can no longer remember). I spoke with one of the developers asking him what he thought of the environment. "Great: I only have to share the terminal with one other person".

The next year I myself was employed at MCC in their AI group (they had a database and CAD group, and perhaps one other) working for Doug Lenat and designing the Cyc system (when I got there they were working in Interlisp on Dandelions, not surprisingly as Doug's office had been around the corner from mine at PARC). The first thing I did was toss the Interlisp implementation and redo it on for a 3600.

5Gen and MCC actually were 2 and 3 of another transformational hype effort, the Center Mondial d'Informatique and Ressource Humaine (World Center for Computer Sciences and Human Resources) launched in France in 1983 on the back of an influential book by a major French intellectual, Jean-Jaques Servan- Schreiber. They had a KL-20, a Vax (with a copy of BSD I carried over there in my luggage) and a few CADR Lispms (two or four, I can't remember). With swanky offices in central Paris around the corner from the presidential palace and a lobby full of Apple 2s that anyone could walk in and try out they didn't do much for the third world I'm afraid, idealistic goals notwithstanding, but they did launch quite a few very good computer scientists, so were probably worth the effort.

So I worked for CMIRH and MCC, and spent some time at 5Gen. Fun times.

<comment><USER3> A funny thing is that both MCC and the Fifth Generation Project were fairly unsuccessful at actually launching the future. My hypothesis is that it's because they were trying to plan research, which is to say, come up with a plan up front for what they were going to do, and then carry it out, rather than improvising based on what was learned in the process. I suspect the massive amount of planning and investment required by modern drug approval is a major cause of the drug industry's dramatic lack of progress in recent decades. Or, as the Goblin Queen put it in her comment below, when industry takes over science, we lose the science.

The 1980s computer systems research projects I think of as the most successful were dramatic advances in semiconductor fabrication, TCP/IP, microcomputers, RISC, Macintosh, Emacs, Postgres, HDLs, GCC, SGI, MOSIS, SUN, TeX, Perl, Plan 9, Cedar, generational GC, OOP, NASDAQ, Pixar/CGI movies, and wavelength division multiplexing. (Maybe my vision is a bit limited and provincial, and I'd be interested to hear what others think.) A lot of these were government- funded, but not with top-down goals. (It might sound ridiculous, but I suspect Perl may have been the most important advance to come out of JPL in the 1980s.). Others were industry-funded. Two were mostly funded by one stubborn idealist, at least until you got involved.

As someone who's worked both on very successful research projects (BSD and GCC) and unsuccessful ones (Cyc) as well as biomedical research, what do you think about what makes the difference? Was it predictable in 1984 that Japan would fail?

<comment><USER2> It seemed likely to me that Japan and in particular MITI couldn't continue on as they had been but I was an outlier and so thought I was probably wrong. Don't forget the US was just emerging from the stagflation of the 70s and while they have addressed that one macroeconomic phenomenon haven't made any progress on any of the things that lead to it.

So having said that, 5Gen was a "moonshot" from a bunch of bureaucrats who could see the writing on the wall, but mistakenly let it get hyped. Compare that to ARPA who used to place a whole bunch of batshit crazy bets that were clearly nonsensical though being done by legitimately smart people: that gave us the Internet, among other things. They also funded infrastructure to get there (e.g. MOSIS).

Since then (the now named) DARPA and corporate labs have lost interest in much blue sky work. "I don't agree that "when industry takes over science, we lose the science." Corp research gave us the transistor, semiconductor, SEM, WIMP interface etc. It could again. Pharma is one of the few fields where fundamental research is still done.

(I wouldn't say regulatory approval has had much of any influence in the cost or output of pharma research BTW; getting meaningful results is _hard_ and if you want drugs that are better than the standard of care you need to do that work. I do think the regulatory framework around marketing and reimbursement has had a much larger impact on which API candidates get advanced into programs.

I'm biased in what I consider fundamental; I'd agree with you on TCP/IP, mpus, RISC, the Mac, generational GC (another corp research result BTW) and fab. (WDM is another corp invention about 100 years old). Some of the others I consider less fundamental or less influential (Cedar? CLU was far more influential even if no real programs were written in it).

The fact is research is hard, and skills in basic research and the skills of translational research are rarely present in the same person.

<comment><USER3> Thank you very much!

Do you think the ARPA approach is better, or better for certain cases? The accounts I've read of the invention of WIMP and transistors resemble "bunch of batshit bets by smart people", if I have the story right, but I don't know anything about the SEM and semiconductors. (Weren't semiconductors Bose in the 1890s?)

A lot of my list clearly was pretty applied; I didn't mean to suggest they were all basic.

Cedar in particular I mentioned because it inspired Oberon, Java (né Oak), in some sense Xi (and ropes in lots of other systems), and maybe sam and the plumber, though maybe that was convergent Blit evolution. But certainly that impact is small compared to the LSP. (Were Smalltalk iterator methods convergent evolution or were they taken from CLU?)

I'm very surprised at your view on pharma. Sounds like my opinions need to change.

<comment><USER2> Well, life is a huge parallel process that requires a diversity of inputs, so you need blue sky, "stupid" stuff, boring spadework and directed development, all at once. (and those definitions change; as fields go through their "stamp collecting" modes, as taxonomy/biology did in the 18th and 19th centuries, _that_ was exciting. High energy physics is stuck there at the moment, again).

So yes, we do need someone like the ARPA of old. Licklider, Bob Taylor, and the like are heroes in my opinion and I don't really see their like today.

</comment></comment></comment></comment></comment><comment><USER4> >> If you want to read about the actual tech they were harping as bringing MUH SWINGULARITY, go read Norvig's AIMA book.

This was still the main AI textbook in 2014 when I did my MSc in the subject. It is what is rightly called a "seminal text" and there is not a single trace of Singularitarianism in it. It's not just "Norvig's book". Its authors are Peter Norvig and Stuart Russel. Is Stuart Russel ignored because he is not at Google?

The article really needs to cool down on the hindsight triumphalism. A lot of people were very optimistic about AI in the '80s (as earlier) because significant and continued progress had been made. Scientific progress, the continuation of the work of the Logicians in the '20s and Church and Turing's work in the '30s. Sure, people in the industry just wanted to make a quick buck, as they always do. But interesting science was being done and it is a big loss that the AI winter disrupted its course. Not because it could have led to autonomous vehicles and conversational agents. What we lost in the winter was the opportunity to discover new knowledge. That is a tragedy.

So I really don't understand where all the schadenfreude comes from, in the article. A big commercial project failed and took with it a whole branch of computer science. Who, exactly, benefited from this?

<comment><USER2> > So I really don't understand where all the schadenfreude comes from, in the > article. A big commercial project failed and took with it a whole branch of > computer science. Who, exactly, benefited from this?

It wasn't a big commercial system; it was a big _government_ system (you probably can't imagine the degree of shock and awe that greeted MITI people or even the mention of the minstry in the US). This was when Japan was going to destroy America and goodamnit, Something Must Be Done.

Of course as happens with such projects it all comes tumbling down, but usually with a whimper. Apollo is another good example: they hit their goal and then what? 5Gen was the more common case: just wasted away.

The schadenfreude comes not just from the central planning hubris but from the American freak-out response to what was really hype and a squib. The author says the same thing is happening today, with the hype-o-meter on 11, again in the AI field, and again with an "asian menace" on the horizon, this time China.

5Gen just rode a hype machine though; it didn't take the field out -- we could all see that coming anyway.

<comment><USER4> >> It wasn't a big commercial system; it was a big government system (you probably can't imagine the degree of shock and awe that greeted MITI people or even the mention of the minstry in the US).

Sloppy turn of phrase on my part.

I do understand the reaction of the US, and not only. I did my CS degree in 2007 and I made heavy use of my university's library that had a solid selection of Prolog textbooks, which I devoured. At some point I noticed that a few of those textbooks (the more industry-oriented) had prefaces that stated Prolog was a very important language to know because it was poised for world domination thanks to the FGCP. Curious, I dug a bit further and found that book- the one from that American journalist woman and the man from the semiconductors business. If memory serves, it portended doom unless the US spent a few billions overtaking the Japanese. Later, I found out what happened after- but I got a pretty good idea of how people in industry in the US saw the whole thing, and it has helped me understand why logic programming was relegated to a mere niche in CS following the abandonment of the FGCP.

The similarities with the present hype cycle are not lost on me, either. However, this is what happens when industry takes over science. We lose the science. There is nothing here to celebrate, or laugh at. Like I say above, missing an opportunity to discover new knowledge because some idiots want to make a quick buck is a tragedy.

<comment><USER3> I wonder if the hangover from this is behind Will Byrd's difficulties in getting tenure despite his truly groundbreaking work with miniKANREN. Maybe people just identify KANREN with Prolog and dismiss it?

(I know it's bad form to complain about downvotes, but this one is really puzzling me. Does someone think Will Byrd doesn't deserve tenure? How could anyone think that?)

<comment><USER5> Is there a good summary somewhere of what miniKANREN is and of the difficulties finding academic support for those of us who work in industry and don't know as much about the tenure system?

(FWIW I tried to help correct the downvotes. I personally believe very very few comments should be in the gray.)

<comment><USER3> As for what miniKanren is, there are a couple of books (one being Byrd's dissertation) and a lot of papers. I think maybe the best summary I've read is actually the interview transcript at [https://www.infoq.com/interviews/byrd- relational-programming...](https://www.infoq.com/interviews/byrd-relational- programming-minikanren/). But also, there's a summary on [http://minikanren.org/](http://minikanren.org/), with links to the papers and talks, and an older summary on [https://kanren.sf.net/](https://kanren.sf.net/). Most of these are a bit hard to understand the significance of if you aren't already familiar with logic programming. The talk on [https://www.youtube.com/watch?v=OyfBQmvr2Hc](https://www.youtube.com/watch?v=OyfBQmvr2Hc) is a popular description of one of the most astonishing results; I haven't watched it but people tell me it's good.

As for understanding academia, yeah, I don't know.

</comment></comment></comment></comment></comment></comment><comment><USER6> My first degree was in Japanese, mostly because I already knew how to program and had, since I was a home computer kid, been doing so for years. I did a Japanese major because Japan looked like it was going to take over the world in 1989, especially in technology. It was a foolish, foolish decision.

However, it gave me a ton of exposure to the 5th generation project, and this article is a wonderful reminder of how crazy it was, though it doesn't quite capture the insane hype around the whole thing.

There's an excellent, if imperfect, book called "The Fifth Generation Fallacy" by JM Unger (who, in a weird circumstance that makes me think the writers of our narrative are just plain lazy, a few years later, became the head of the Japanese department I was in) that talks about the project in terms that I think make quite a lot of sense.

The book talks about it, but I go even further: the 5th gen project was about Japanese beliefs about information technology and specifically that Japanese was such a complex language that the only way to have working IT was to have an intelligent machine.

Japan was still using pencils and xerox machines in the aftermath of the PC revolution in the US and Europe (in practice, this continued into the mid-90s), and had missed mainframes and minis entirely. The idea of a statistically-driven, convenient, modern input mechanism (what people use now when they use an IME, these started to show up in the mid-90s when enough of a corpus was analyzed to make them work) was not there yet; Japanese word processors of that era are incredibly cumbersome and terrible, just barely usable and not usable at all by large swaths of the work force. Japan was absolutely terrified of the technological progress in the rest of the world and a lot of it had (and has) to do with the simple inconvenience of the writing systems and the linguistic isolation.

In the cultural context, especially of the bubble that formed at the same time, and no small amount of vaguely racist beliefs about their superiority (especially linguistic, which had been going on for a very long time and played a role in Japanese relations and eventual behavior post-annexation of Korea), the 5th gen project makes perfect sense.

<comment><USER7> Unger's book doesn't get the attention it deserves, maybe because he is a humanities guy. I just wanted to add that response to his book was (predictably) very hostile, much like with Hubert Dreyfus' _What Computers Can 't Do_. Unger offered well-reasoned criticism early in the hype cycle, but it seems to have had no influence on how people responded to the FGCP.

</comment></comment><comment><USER3> > _somehow they thought optical databases would allow for image search. It's > not clear what they had in mind here_

Oh, well, it turns out that focusing a spatially modulated light beam through a lens gives you the Fourier transform of the original spatial modulation at the focal plane. So if your lens has a focal length of 30 cm you can calculate a Fourier transform of an image of whatever size (1024x1024, 2048x2048, 4096x4096) in 1 ns. This is about six or seven orders of magnitude faster than you can do it on a modern CPU core, and still about three orders of magnitude faster than you can do it on a NVIDIA Turing. It was about eleven orders of magnitude faster than you could do it on digital hardware at the time of the Fifth Generation Project.

But you lose the phase information (as far as I know) so you can't reverse the process. So what's it good for?

Correlation, that's what. If you have a photo of a tank from some angle at some angle and scale, and at some set of phase shifts it has a significant correlation with some other image, that probably means that tank is in that image. You can compute the correlation (disregarding phase, so it's an upper bound rather than the actual correlation) with an electrical SLM, which is slower than the lens but still a lot faster than a VAX. Or an i7.

So it was a plausible attack on the problem of image recognition using massively parallel analog computation. It hasn't panned out, but we had to try it to find that out.

</comment><comment><USER8> "I had friends on that deathstar" basically: I was working in the UK JANET community, with people I knew doing Alvey project funded 5th Generation work. The projects had a very strong "catch up or we will loose the war" feel to them, because the Japanese were pumping money into things which made ICL, Olivetti,Ci-Honeywell-Bull,Ferranti,GEC very nervous. Domestic-Strategic outcomes vested in having strong world-comparable computing manufacturing: What if they "out thought us"

The one I can remember (from 40 years distance) is the GEC4000 project in Newcastle University, which included GEC-Plessy, Newcastle and York and Glasgow University, in a joint computing project. the GEC4000 was targetting (hah) Submarine and AWACS contexts, and this was a huge activity to get ahead of some issues in computing for synthetic radar. (which btw, GEC had some lead in: the work they did in the prior two generations of computing made british radar work world-class which is in part why british materiel sells so well into many armed forces. Also explains why Schlumberger and the like were into the same hardware: synthetic apeture radar is the same problem as Oil Shockwave exploration. Guess which british companies sold to Oil? Ferranti (Argus) and GEC/Plessy)

The standing joke about the GEC system was it had a real "halt and catch fire" instruction because thermal management on the CPU was out of hand, and it needed constant monitoring to prevent fire risk in the machine room.

The UK also had _two_ rounds of "AI is the solution to every problem" remembering the Whitehill report of the 1970s which preseaged many of the same pushbacks in the 1980s and 1990s on ubiquitous AI: the proponents made far too sweeping claims and got a rap over the knuckles about cost-vs-benefit and sweeping up the money.

Alvey made it very hard to fund non-alvey projects. This kind of thing turns collaborative science into competitive science with toxic qualities. Overall, I judge Alvey harshly.

BTW I was a very very junior CompSci research programmer: If this stuff leaked into first-job-out-of-Uni level staff, imagine how loud it was around the Professorial table?

</comment><comment><USER9> It is so easy to make fun of the failed ones and try to predict the past, but once there were other government projects which ended up working and now we see as obvious right just because we know how history has gone, see for example ARPANET.

If the fifth generation would have worked in some degree now it would have some status and if ARPANET would have failed it would have been forgotten.This is how anglosaxon culture often works, making fun and parodies of competitor failures, etc. In other aspects of history the same historical rhetorical approach is often seen.

</comment><comment><USER10> I love history as much as the next guy, and this is exciting writing, but the issue I have with this is that we haven't seen the end.

That is to say, AI is an unsolved problem, and we don't really know what the solution will look like. We are in a (the?) golden age for statistical learning but in the end, symbolic processing and prolog like architecture might turn out to be the key.

I will point to someone much smarter than myself — Jerry Fodor — to make the arguments. But basically it amounts to this: intelligence is the ability to reason and our best model for reasoning is linguistic.

Okay, he says it much better than I do.

</comment><comment><USER11> Perhaps the author has only worked on simple, predictable outcome, projects but in my experience (personal and in generally observing our industry) failure and restarts are often the path forward to success.

I lived through the period of AI in the 1980s, have been a vendor of expert system tools for Lisp machines and the Apple Macintosh, and when MCC was being founded the founder Admiral Bobby Inman gave me a tour of the place.

I also joke about the outlandish claims and thought the AI winters were well deserved but I also believe that the state of our field and business now is very good and those rough times in the 1980s and 1990s are what helped get us to where we are today.

</comment><comment><USER12> >Saying you're going to build an intelligent talking computer in 1982 or 2019 is much like saying you're going to fly to the moon or build a web browser in 1492.

Alex and Siri do a pretty good job of talking, and are almost up to the task of hearing. They are command and search interfaces only - the "intelligence" in them is very limited (hardly there) but it is clear that there is a jump between 1982 and 2019. These devices do exist and to deny their reality does cast a lot of doubt on the other perspectives presented.

<comment><USER13> Well, you should go read the original 5th gen specs; they're all on file sharing. They were not talking about Siri (which is a terrible example, and something that was basically possible even way back in the 80s using vector quantizers and HMMs). They were talking about Star Trek or Hal-9000 type computers that could understand meaning and do human-like abstract design work beyond "hey google spyware, please turn on the air conditioning."

</comment></comment><comment><USER14> In japanese pop culture of the 80s and 90s, you see references to 5th gen computing now and then. Just like as a part of the technobabble in some sci-fi show. Watching sci-fi anime once I heard it a few times I started to suspect it might be a real thing, and looked it up.

If anyone has a recommendation for a book or long article that covers the this, some of the people involved, what they actually achieved, etc. I'd be interested.

<comment><USER15> Look at this [http://xahlee.info/kbd/TRON_keyboard.html](http://xahlee.info/kbd/TRON_keyboard.html)

Then [https://en.wikipedia.org/wiki/TRON_project](https://en.wikipedia.org/wiki/TRON_project) and especially [https://en.wikipedia.org/wiki/BTRON](https://en.wikipedia.org/wiki/BTRON)

If that is not enough, try [http://tronweb.super- nova.co.jp/homepage.html](http://tronweb.super-nova.co.jp/homepage.html) which is the most comprehensive history of that i can find.

In my opinion that is the stuff which influenced sci-fi anime.

Imagine... A specification exactly describing a common platform with different levels of capabilites, but not down to the bits, but more like an API, where anybody is free to implement that in whatever way one sees fit, as long as it conforms to the API. Mandatory interoperability between products of different vendors, be it hard- or software. FAST! All networked. All with code at least a magnitude smaller than contemporary counterparts.

So no BLOAT.

That was the spirit of the time there, i guess.

But the powers of Babylon intervened again, i guess.</comment></comment>


"The 's' is sad": 4-year-old submits Linux kernel doc patch (2014) - <AUTHOR> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=690b0543a813b0ecfc51b0374c0ce6c8275435f0 <comment><USER2> Linus on trivial patches:

[https://lkml.org/lkml/2004/12/20/255](https://lkml.org/lkml/2004/12/20/255)

[ Linux-kernel added back into the cc, because I actually think this is important. ]

On Tue, 21 Dec 2004, Jesper Juhl wrote:

> Should I just stop attemting to make these trivial cleanups/fixes/whatever > patches? are they more noice than gain? am I being a pain to more skilled > people on lkml or can you all live with my, sometimes quite ignorant, > patches? I do try to learn from the feedback I get, and I like to think that > my patches are gradually getting a bit better, but if I'm more of a bother > than a help I might as well stop.

To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel - not just on an intellectual level ("I understand that the GPL means that I have the right to change my kernel"), but on a more practical level ("Hey, I did that small change").

And whether it ends up being the right thing or not, that's how everybody starts out. It's simply not possible to "get into" the kernel without starting out small, and making mistakes. So I very much encourage it...

So please don't stop. Yes, those trivial patches _are_ a bother. Damn, they are _horrible_. But at the same time, the devil is in the detail, and they are needed in the long run. Both the patches themselves, and the people that grew up on them.

<comment><USER3> I really hope that next time when somebody tries to paint Linus as an asshole and a toxic force for the community because of his rants, someone remembers to link this email too.

<comment><USER4> It demonstrates how Linus is not only a good programmer, but also a good leader.

I get the same idea as with the first Gordon Ramsey Kitchen-fixing programmes. Apparently, people said it was insane how he dared to swear on TV. But basically, he notices things are very wrong, makes sure he gets to the bottom of the mess, and hammers the ugly message very publicly into some owner who lost any connection with reality. If the cost is some swearing, that's the least of the problem. The failing businesses get fixed at least as much on a sociological level as on a cooking level.

Linus does the same. A big software project's problems are more sociological than technical in nature. Sometimes, the ugly message has to get trough, an another famous rant is born. But most of the time, work gets done, probably with a reasonable amount of smiles.

<comment><USER5> The US Kitchen Nightmares are completely faked up drama for US audiences. Watch some of the original UK ones and you'll see how he tries to coach the chefs with comparatively minimal swearing and anger.

<comment><USER4> I am indeed mostly talking about the UK versions. The US versions had much more drama and much less cooking, but underlying it had the same theme.

</comment></comment></comment></comment></comment><comment><USER6> Mailing list thread: [https://lkml.org/lkml/2014/11/24/407](https://lkml.org/lkml/2014/11/24/407)

      > When I was reading the documentation, my 4-year-old
      > niece wanted to see what I was doing. After telling her,
      > she noticed that something was very wrong and asked
      > me to fix it. Instead, I helped her fix it herself.

<comment><USER7> Sounds totally plausible. I never cease to be amazed by my 4-year-old's attention to detail. He notices _everything_.

<comment><USER8> Everything they do is the first time while grownups have done it dozens of time.

</comment></comment></comment><comment><USER9> Well, now a 4-year-old has one more kernel patch than I have...

<comment><USER10> There's nothing stopping you, except finding the time.

One of the things I'm most proud of as a dev is a _tiny_ contribution to the Nim standard library. It's a single commit and very simple, but made the PostgreSQL adapter consistent with the other RBDMSs' adapters. At the time, I'd been using Nim for only a couple of days, but that didn't stop me from being able to contribute in a meaningful way.

I'm amused and humbled that despite all of the work I've done over the past decade, it's quite likely that a seven-line change that I did mostly in ignorance will be the thing that impacts the most people going forward.

Here's the change, if you're curious: [https://github.com/nim- lang/Nim/pull/6381/commits/921cc53e40...](https://github.com/nim- lang/Nim/pull/6381/commits/921cc53e40f7d48643c0579ca83dedbfa4c500d0)

<comment><USER11> > I'm amused and humbled that despite all of the work I've done over the past > decade, it's quite likely that a seven-line change that I did mostly in > ignorance will be the thing that impacts the most people going forward.

My most popular open source project, by the numbers, is a ~40 line Rack middleware I wrote when jetlagged at 2am. ~29MM downloads all-time, 984 github stars.

I think about that all the time.

</comment></comment></comment><comment><USER12> So typical of Linux kernel code quality: The commit message refers to a missing '=' but the commit actually fixes a missing '-'.

;-)

</comment><comment><USER13> I kept wondering where to find the change. I didn't initially realize it is apparently included. But this seems to be it here (from the bottom of the page):

       1.9 Ext4 file system parameters
      </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
      +</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-

<comment><USER14> For the love of god I still don't see an 's' with a missing (or newly inserted) "=". I've spent way too much time looking at this

<comment><USER15> it's slightly confusing, because in the change the first dash on the first line is a "minus", indicating that line was removed, not part of the line of dashes. the line of dashes had one dash added to the end of it. (and it was a dash missing, not an equal)

           1.9 Ext4 file system parameters
        [-]</comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>
        [+]</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-

</comment><comment><USER16> I've submitted many such small corrections to OpenBSD to help keep that standard high. No one will place those contributions on the same level as real development but I like that I've helped. And I know I appreciate it when even the documentation is kept at the same bar.

One of the reasons I fell in love with OpenBSD was the commitment to correctness throughout the entire system. This is a lot harder with Linux because they only control the kernel and not the entire distribution.

<comment><USER17> Please keep doing that. I'm still hesitant to contribute to tech@ with code and have yet to find a fixable issue in the man pages/FAQ in my own usage. But I do appreciate that the details are oh so right very often.

</comment></comment><comment><USER18> This uncannily reminds me of how I first learned to program (at ~10 years old, not 4, sadly).

Growing up, at my grandparents house, we had a communal old Mac (running OS 7 or 8, and BeOS for a while). Being a curious kid, I would often watch my uncle play Civilization II, and I would play myself. One day, I went to observe what he was playing, and instead it was programing in FutureBASIC. It sparked my interest, and he taught me the basics. This became a lifelong hobby, and I went from learning FutureBASIC from him, to then discovering a whole world of information online, learning REALBasic and PHP next, and C, Objective-C, and more. As a teenager, I made Mac apps and websites, and eventually when the iPhone came out, mobile apps. This gave me disposable income in high school (from selling shareware) and funded my one-way ticket and move to Silicon Valley.

A simple gesture like that, that sparks the right interest, can give someone an entirely different life and career.

<comment><USER19> The shareware era of the Mac was a magical time to be a teenage programmer. It's one thing to get the validation of an adult's approval, but something else entirely to have them _pay_ you for something you built without knowing your age.

<comment><USER20> I bought shareware once 30 years ago and never got the promised unlock code in response. That stopped me paying individual strangers for software via mail.

</comment></comment></comment><comment><USER21> Love this, but was a bit confused because the patch is 4 years old, a fact which which confirmed my initial misreading of the patch being 4 years old (rather than the correct reading that it was by a 4-year-old)

<comment><USER22> Interesting. I wonder if Maisa has gone on to write any more patches yet!

<comment><USER23> Or if she got corrupted by the dark side and works for FB now!

<comment><USER24> FB employees submit loads of interesting kernel patches.

<comment><USER23> They do indeed! The current state of the open source community owes quite a bit to for-profit companies working on the code.

</comment></comment></comment></comment></comment><comment><USER25> Wonderful story :)

From date in mail list ([https://lkml.org/lkml/2014/11/24/407](https://lkml.org/lkml/2014/11/24/407)) seems like [2014] should be appended.

<comment><USER10> Nice attention to detail! Perhaps, if you have some time later, you could read over the Linux kernel docs?

</comment></comment><comment><USER26> The best part about this story is that it is entirely plausible that a 4 year old found the problem, unlike a lot of stories where we are supposed to think there is a 6 year old wunderkind submitting code patches to some OSS project.

</comment><comment><USER27> And here's how you get junior kernel devs :D

I hope you're still hacking on it and other projects, Maisa Roponen... Now 8 year old!

</comment><comment><USER28> That is cute.

<comment><USER29> My coworkers thought I was making a sarcastic comment (apparently I have a reputation) when I suddenly said out loud "That is adorable!". I then had to explain what I was talking about.

<comment><USER28> Its almost tears in my eyes level. I didn't expect to have that reaction.

<comment><USER30> Yeah, I had the same reaction. I've noticed it whenever I see adults putting in an undue amount of effort 'just' to maintain a child's innocent expectation of a certain kind of universal justice.

It's so not a part of the adult lifestyle anymore that suddenly being confronted with it affects those sensitive to it deeply.

Christmas culture and thematics seems to target this dynamic.

<comment><USER28> I have a son who's a small child so I see and encourage that magical world that we've all mostly forgotten about. Young childhood should be a human being's respite from cold, hard reality. Of course, things don't always go that way for children.

</comment></comment></comment></comment></comment><comment><USER31> the difference between a community and a workplace is its tolerance, and need, for whimsy...

</comment><comment><USER32> And here I am spending my afternoon tracking down a null reference error...

</comment><comment><USER33> I like it. and as a bonus she can add kernel dev to her linkedin.

</comment><comment><USER34> One has to be born with an eye for details... Well done!

</comment><comment> black-tea I'm sure this was fun for the guy who submitted it but in the end just useless noise on the mailing list.

<comment><USER35> "So please don't stop. Yes, those trivial patches _are_ a bother. Damn, they are _horrible_. But at the same time, the devil is in the detail, and they are needed in the long run. Both the patches themselves, and the people that grew up on them."

<comment> black-tea I'm sorry but there's no way the 4 year old learnt anything from this. Maybe the adult did, though. Is that the point?

<comment><USER36> She learned that her opinion is valued. She learned that it's ok to question things. She likely had a sense, based on the activity that followed, that she effected change in some way. I'm sure it was explained to her, and while of course she doesn't understand what a kernel or source code are, she surely had a sense of some positive accomplishment.

<comment><USER37> The world will become a better place if all kids get this golden treatment. I wish we could so easily push trivial changes to society but, in a very small way, this ripple in the ocean did.

<comment><USER23> "See this? We just need to change one little thing. There is a problem with the program and we can fix it: the president variable is orange. Let's work on that"

</comment></comment></comment></comment></comment></comment><comment><USER38> Does anyone else have serious doubts about a 4 year old reading Linux kernel code?

</comment><comment><USER39> Until a 4-year old can deal with the efficacy in which Linus communicates with other humans they should not be allowed to submit patches.

<comment><USER40> It takes some time to get used to Finnish style of management.

<comment><USER41> No worries -- based on their names, I'd say the girl and her uncle are Finnish as well. :)</comment></comment></comment>


Tell HN: Give the "why" behind your feedback, else you'll warp team's behavior - <AUTHOR> There was a time when I was constantly given feedback to the tune of "this isn't good enough, change it to [manager's opinion]". I've worked in tech marketing, where this is extremely common.
I'd ask why, but often the reason wasn't well articulated, or it wasn't articulated "customer-first". This in turn led me to change my behavior so that I was doing things to get my manager's approval, and not because I wanted to communicate clearly/better with our customers.
That was incredibly frustrating... the realization that you're doing something so that the manager approves of it, or lets it go live. And I never knew if I was right or wrong, it would all depend on the manager's opinion at the time of reckoning. I suspect the larger impact of this seeping into a company's culture can be catastrophic, since many teams' north-star becomes "what will he/she think?", versus doing better for their customers.
After I started managing people, I made the same mistake. But at least I can recognize it now, and make an honest attempt to explain the "why" behind any feedback I'm giving.
If I can't give a "why" for a subjective opinion or feedback, then I think harder about it, and try to understand why I "feel" that ways. I think this helps those reporting to me grow, and gets them to think about how the customer will perceive our marketing communication.
So yeah, if you're managing people, please give the "why".
Edit: grammar. <comment><USER2> I love the fact that this hits the heart of the feedback problem in today's super dynamic teams, who relentlessly focus on speed of execution. While that is not a problem in itself, it does sometimes lead to adjacent issues like absence of actionable feedback loops for team members, that'd help the organization much better in the long run.</comment>


A C++ Immutable String class - <AUTHOR> http://blog.reliablecpp.com/2013/09/a-c-immutable-string-class/

<comment><USER2> If you can't access the website, here's the code: [https://github.com/cdmh/cpp_immutable_string](https://github.com/cdmh/cpp_immutable_string)

</comment><comment><USER3> I guess I expected the whole point of an immutable string class would be to have O(1) copies. What does this buy you beyond 'const std::string'?

<comment><AUTHOR> I'm toying with implementing O(1) copies by using a reference counted pointer to basic_string instead of storing it by value within the class. It would mean a small memory overhead and another level of indirection, but probably worth doing. Thoughts?

<comment><USER4> Most implementations are reference counted with copy on write. No point.

<comment><USER5> libc++ (the Clang project standard C++ library) doesn't use COW for std::string, and I'm pretty sure GNU stdlibc++ will also drop it the next time they have to break ABI. C++11 move semantics and the 'small string optimisation', as it's known, blow away any performance benefit of COW for most sane uses.

<comment><AUTHOR> COW is prohibited in C++11 Standard implementations of std::basic_string

<comment><USER5> I don't have a copy of the final 2011 standard, but as far as I can see there's nothing in the latest 2011 draft of C++11 that expressly _prohibits_ COW.

[184.108.40.206] does say "Every object of type basic_string<charT, traits, Allocator> shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed", but that "as needed" most definitely leaves the door open for a COW implementation.

The only other part that I can see that may preclude a COW implementation is the postconditions specified for copy operations [21.4.2], which says data() returns a pointer which "points at the first element of an allocated copy of the array whose first element is pointed at by str.data()". Again though, "allocated copy" doesn't necessarily mean "a copy I just allocated". When I go and get a copy of a book I don't literally go and copy it.

In fact the standard specifies that the move constructor leave the source value "in a valid state with an unspecified value"... which again suggests you could use COW and have the source argument return the same value it had before you moved from it.

In the latest C++14 draft though (N3690), you're right, it is explicitly prohibited because "Invalidation is subtly different with reference-counted strings".

<comment><AUTHOR> 21.4.1 p6 states invalidation of iterators/references is only allowed for — as an argument to any standard library function taking a reference to non-const basic_string as an argument. — Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.

The non-const operator[] in a COW string requires making a copy of the string if the ref count > 1 which invalidates references and violates this paragraph.

<comment><USER5> Hmm true. This is what happens when you let the user violate the iterator abstraction for performance and rely on contiguity and raw refs/ptrs. It's kind of a shame, because the moment you mutating characters in a string you're often doing something silly anyway.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> This is not an implementation I would use. One major reason for using an immutable string class instead of a const string is to get rid of the capacity member. For short strings (e.g words) the capacity member alone can be larger than the contents of the string.

<comment><USER7> A string would have to be short indeed for the capacity to be larger - something like 2 characters, I'm guessing. It's certainly a valid concern in occasional cases, but I wouldn't consider it a major reason to pass on an implementation.

<comment><USER6> The string capacity on a 64 bit machine is usually represented as an 8 byte integer. The average length of a unique english word is 8 and the average length of a word occurrance is 5.

</comment></comment></comment><comment><USER4> The main question I have is, why?

The author also has a rather [confusing article][1] about immutable vs const, that I would discredit personally. He claims that objects accessed via reference to const can modify themselves, which is not true, as you can only access const functions through a const reference.

[1]: [http://blog.reliablecpp.com/2013/09/immutable-vs- const/](http://blog.reliablecpp.com/2013/09/immutable-vs-const/)

<comment><USER8> I think the implication is that since void output(std::string const &msg); takes a const reference, that function cannot change the value of msg. What the function does not know is whether or not anyone else outside of the function could change that value. It doesn't know if the original creation of the object was const or not const.

The example is misleading because there isn't any reason why you would be concerned with such a distinction in this case.

<comment><USER4> Agreed, it is completely irrelevant that it could be modified before or after.

</comment></comment></comment><comment><USER9> This defeats the purpose of

        std::string const s("Hello");

<comment><USER10> You specify that the place s is const, not the value it keeps. You can still do:

        #include <string>
        #include <iostream>

        // not your code
        void innocentF(std::string const& s) {
          (const_cast<std::string&>(s)) += std::string(" I'm evil.");
        }

        // your code
        int main() {
          std::string const s("hello world.");
          innocentF(s);
          std::cout << s << std::endl; // hello world. I'm evil.
          return 0;
        }

<comment><USER11> That code isn't valid C++. Modifying a const object is undefined behavior. You would have to remove the const on your string in main to make the program well-defined.

<comment><USER12> const_cast is undefined behavior? Can you cite the spec?

<comment><USER13> const_cast is undefined behavior if the actual object is const. If it's a mutable object that just happened to be passed as a reference you can const_cast it. Or that's how I understand it.

<comment><USER10> The funny thing is - it doesn't even show a warning compiled with -Wall.

<comment><USER4> Well, the `const_cast` usage is fine, but calling that function on an actual `const` object is not; it's a lot to ask a compiler to warn on that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> This class doesn't seem like you actually get any tangible benefits from it, as it just stores a std::string plain and vanilla inside...

</comment><comment><USER14> I don't really understand why you would want this other than to trick yourself into thinking you are writing java. (I already find it really annoying when people port their Javaisms to C++.)

<comment><USER15> The page is down, but: Most languages have immutable strings.

Also, I hope you're not suggesting immutability is a Javaism...

<comment><USER14> Yes, actually, I don't think it's controversial to say that Java did more to popularize immutable strings than any of the languages you're thinking of. And when people get CS degrees completely centered around Java, bring this kind of "feature" and others to C++, they end up churning out what looks a lot like pretend-Java.

<comment><USER16> Do those CS degrees exist? I pity those students.

Back then when I graduated (1999), at least in Portugal there were lots and lots of languages to use for assignments, during the degree (5 years long).

</comment></comment></comment></comment><comment><USER17> This implies that C++'s std:;string is mutable. I think I'll continue to run the other way, to avoid C++ (and C as well) whenever I can. Mutable strings are insane.

<comment><USER4> Why (are mutable strings insane)?

<comment><USER17> OK, that comment was too light on substance.

The problem with strings being mutable by default is that one has to do a lot of defensive copying to avoid unexpected behavior. Mutable strings do have their place, inside a function that's building up a string, before that string is visible to any other part of the program. But it shouldn't be the default.

See also: "The Value of Values" by Rich Hickey ([http://www.infoq.com/presentations/Value- Values](http://www.infoq.com/presentations/Value-Values))

<comment><USER18> The primary reason when deciding whether a type should be mutable or not is psychological: mutable things are containers with independent identity from their content; things that are identified by their value should be immutable. The prototypical mutable type is an array; the prototypical immutable types are numbers: if you change the imaginary part of a complex number, you don't have the same number with different content, you have a different number. When you think about strings as arrays of bytes like you do in C, it makes sense for them to be mutable; in a higher level language where they behave much more like atomic values, it makes much more sense for them to be immutable – it can be really jarring when some called code deep down in the guts of a program mutates a string and you see the results at the top level. In C++, which is somewhere between a low level and high level language, it's hard to say which way it should be, but the STL approach does seem to treat them more like values than containers, which implies that they probably should be immutable.

</comment></comment></comment></comment><comment><USER19> I was hoping for an optimization of 8char strings to be stored internally as longs.

</comment><comment><USER20> It's immutable but it defines swap? That seems.. odd.

<comment><USER21> It does not. swap() only appears in the documentation as a function not implemented.

</comment></comment><comment><USER22> reliablecpp, maybe, but alas: not reliablesite. :-(

</comment><comment><USER23> Was hoping for ropes. Not bad, though.

</comment><comment><USER24> Benchmarks?</comment>


This is how much Microsoft charges the FBI for your info - <AUTHOR> http://dailycaller.com/2014/03/20/this-is-how-much-microsoft-charges-the-fbi-for-your-info/

<comment><AUTHOR> The original article on dailydot [http://www.dailydot.com/news/microsoft- compliance-emails-fbi...](http://www.dailydot.com/news/microsoft-compliance- emails-fbi-ditu/)</comment>


How Paypal and Reddit faked their way to traction - <AUTHOR> https://medium.com/design-startups/9411fb583205 <comment><USER4> A few years back the major tv companies in the UK underwent a scandal involving faking tv phone-in competitions - runners on the show called in pretending to be viewers, calls went unregistered. Almost none was intended to gain pecuniary advantage but it was fraud. I think people went to jail.

I fail to see why the same scandal should not be seen here

Edit: Reddit is deception, hard to see fraud. Dating sites with fake profiles are likely to be fraud if its a pay site(AFF sounds outrageous). The odd ball is PayPal - if the eBay supplier got less money from the sale than if they had dealt with a normal user with a credit card the I guess there could be a case for fraud. Be interested in a real lawyers view

<comment><USER4> Having had time to mull this over, I was not vitriolic enough. Disruption of sclerotic industries is a Good Thing. VoIP has destroyed the International call market and brought innovation to an industry that was impressed by Caller ID.

But if one company achieved success in the VoIP market over its competitors by dishonest, underhand or fraudulent means then they should be punished - <USER2> to end the moral hazard.

This is why Über and the like are facing opposition from disinterested parties - because "disruption" of an industry by new technologies is a Schumpter style positive - but it is not a Cloak of Immunity for any particular company engaged in that disruption. We do not have a good track record in this - <USER3> that matters.

<comment><USER5> I'm not so sure. Where does one draw the line? A quiet restaurant fills its window seats first to make it look busy. New businesses give out their invoices starting from strange numbers such as 26792 rather than 1 to make things look better. I'm handed 2 for 1 vouchers by shops and food places to make them busier. Amazon sells (sold?) books at a loss to drive others out of business (a technique used countless times in the non-internet. There is a line there somewhere, but I'm not sure where it is. Obviously fraud and dishonesty is not ok, and most my examples I am fine with. However I'm sure that different people have different boundaries.

<comment><USER6> Elon Musk on Erick Jackson (author of Paypal Wars quoted in article):

"The only negativity in recent years was due to a book called The PayPal Wars, written by a sycophantic jackass called Eric Jackson. This guy was one notch above an intern at PayPal in the first few years of the company, but gives the impression he was a key player and privy to all the high level discussions. Eric couldn't find a real publisher, so Peter funded Eric to self-publish the book. Since Eric worships Peter, the outcome was obvious - Peter sounds like Mel Gibson in Braveheart and my role is somewhere between negligible and a bad seed. However, to his credit, Peter didn't realize the book would be as bad as it was and apologized to me personally at a Room 9 board meeting at David Sacks's home in LA."

</comment></comment></comment></comment><comment><USER7> I think we need to distinguish between "faking", "demonstrating" and "supplying". Faking should be reserved for literally providing false data with the intention that it's believed to be true, eg. the dating site example.

Most of those examples were not faking anything. Rentoid actually supplied a serivce, though it wasnt "user-generated". Reddit supplied links their potential users would be interested in.

This is a mixture of demonstrating how the service works, and supplying actual content to potential users.

By way of contrast, what the dating site admins should have actually done, is ask all their single friends to sign up (and any other single people they could get their hands on directly).

It seems a perfectly good and moral business strategy to generate your own content which is representative and useful. I think "faking it" is a bit more questionable.

<comment><USER8> Your examples are mostly still "faking" \- faking consumer interest, faking popularity.

Companies do that all the time.

<comment><USER9> No

In the case of the dating website it is faking. Because there's no way you'll end up dating the fake profile

Not sure how it was in the case of Paypal, if it was a false order or they would just go ahead and buy small stuff then.

But in the case of Reddit and Rentoid, it's not fake. You're getting what you want. Links and the products to rent.

It doesn't matter if it's being provided by the founders, you're getting the service

<comment><USER10> But the founders were lying about their identity when posting the links. If the user considers the service to be "links from other users" then yes, the content is fake. If the user considers the service to be "links", then you're correct. Personally, I consider the service to be "links from other users" and therefore, from my perspective, the content was fake.

<comment><USER11> Lying may be too strong of a word. The users have pseudonyms; there was no reddit real names policy. It seems reasonable for multiple pseudonyms to be controlled by a single person.

Users may have been surprised to find out just how few other people actually existed. But I see this as legit. It would be like a big corporation hiring "Esprit Legal Firm" for their defense, winning in court, and hen finding out that the company was run by a single lawyer. Obviously businesses can't lie, but you're not required to list your own flaws either.

<comment><USER12> Businesses lie all the time. I believe AT&T was busted a year or so ago for misleading consumers that the fees attached to their phone bill were mandates by the government. Bestbuy was busted on using different instore flyers then the ones they shipped out.

</comment></comment></comment></comment></comment></comment><comment><USER13> Missed a couple big ones from companies they mentioned. Yelp paid professional reviewers to seed cities they wanted to establish themselves in. To my knowledge they were honest reviews, but people were still put off by it.

And the Airbnb spam debacle was left out as well. ([http://davegooden.com/2011/05/how-airbnb-became-a-billion- do...](http://davegooden.com/2011/05/how-airbnb-became-a-billion-dollar- company/))

For the record, I use both services frequently, but those are notable omissions.

Really curious how much PayPal dumped into buying eBay items. Doesn't seem like something you could do for long, so I imagine it had to be highly targeted.

<comment><USER14> If I were PayPal, I wouldn't primarily be focused on buying items, as it would be very expensive strategy. I'd try sending sellers email first, indicating that you are interested in purchasing their product and asking them if they support PayPal. Having thousands of sellers just visiting your site to see what this "PayPal" is about is a great way of getting your name out there at no cost.

Also, if I'm not mistaking, buyers have no right to force sellers to accept a payment method that the seller did not support. Of course you could try to persuade them after you've bought their product, but insisting goes way too far.

<comment><USER15> >buyers have no right to force sellers to accept a payment method that the seller did not support.

sure they do. after you've won an auction or otherwise agreed to buy you are restricted to only the accepted payment methods, but before making a purchase you can contact a seller saying "i'll buy this if you can accept paypal"

</comment></comment></comment><comment><USER16> Paypal buying eBay items wasn't actually the primary method for stimulating growth. Initially, Paypal offered new users $20 for opening an account, and $20 for referring somebody to open an account. They then dropped the bonus to $10 for both, then $5, then $0. This allowed them to grow immensely, and they reached 100,000 users in one month. These bonuses weren't "cheap" though: they cost PayPal around 60-70 million.

Here's a reference - an interview between Elon Musk and Salman Khan: [http://www.youtube.com/watch?v=vDwzmJpI4io&feature=player_de...](http://www.youtube.com/watch?v=vDwzmJpI4io&feature=player_detailpage#t=682). It's worth a watch.

<comment><USER17> >60-70 million

Great strategy if they actually worked out they could get it back in x time with y users actively using Paypal. The real step is taking the risk. What if only half of the money returns and there is no further adoption? How did they ever take that step? Or were they monitoring the user growth 24/7 and if it didn't match their planned strategy, they would pull the plug on bonuses? Amazing however they managed to pull it off.

</comment></comment><comment><USER18> I'm usually not bothered by stuff like this, but let's play some role- reversal.

"Dating services know what men want (who doesn't) and seed the network with photos of Latin American models with eclectic interests (not that the latter matters)."

In to...

"Dating services know what women want (who doesn't) and seed the network with wealthy-looking men with genuine personalities (not that the latter matters)."

<comment><USER19> I'd prefer Italian models myself but I mean they already know apparently...

On a serious note, it probably worked. This might come across as sexist, but aren't we as men more easily "gamed" when it comes to dating? We are very visually oriented...more so than females.

<comment><USER20> Counterpoint: [https://www.google.com/search?q=romance+novel+covers&safe=of...](https://www.google.com/search?q=romance+novel+covers&safe=off&source=lnms&tbm=isch&sa=X&ei=T9YYUt2vCJb_4AOw94DoDA&sqi=2&ved=0CAcQ_AUoAQ&biw=750&bih=799)

<comment><USER21> How is that a counterpoint? It only shows covers of romance novels where the men look muscular and the women pretty. If men paid less attention to looks than female why are there so many arguably good looking women with so many arguably plain looking (but possibly wealthy) men?

</comment></comment></comment></comment><comment><USER22> This reminds me of the tactics the music industry used to use to gain initial traction for their manufactured groups and artists who had never built up an organic following before being signed. Case in point is Lou Pearlman's creation, Backstreet Boys, who's first album and titular single was called "Backstreet's Back", with lyrics that alluded to the fact that they had been around for a while and were making a 'comeback'. Their music video was noted for having a mass of adoring, screaming female fans chasing them down the street and going silly over them. This was before they were even known, but eventually became a reality.

<comment><USER23> Sorry, that's wrong.

"Everybody (Backstreet's Back)" is the first single from the Backstreet Boys' _second_ international album from 1997.

They were huge thanks to their 1996 international album called "Backstreet Boys":

>becoming one of the biggest debut albums ever and contains a number of the band's most memorable singles

<comment><USER22> Ubershmekel, you are dead right! Sorry, I stand corrected. After reading the Wikipedia article I guess they really were 'back!'. (I was listening to Smashing Pumpkins at the time in all honesty!)

In another example of the music industry seeding their own success, I remember when it wasn't uncommon for a major label to ship a number of initial releases to record stores and then buy them back to push their artist up the charts (which were all based on record sales). The result was that the album or single rode high up the charts getting more rotation on terrestrial radio and MTV, until it became a self-fulfulling prophecy and eventually outsold the buy-back investment and then some.

Thanks for the BSB correction :)

<comment><USER24> Buying your own products to ultimately boost sales is pretty common in the media industry that has best-selling lists. New York Times Best Sellers, music charts, and more recently app stores.

Not that I disagree with your comment, just adding a bit of detail.

</comment></comment></comment></comment><comment><USER25> I think that this is an obvious extension of what new businesses have been doing for decades. If you open a storefront, you would do a soft opening to test the idea and then a grand opening to generate traffic.

If I was having a grand opening, I would get every friend there, even if they would never shop at my business, to make the place seem full and busy during the "party".

Obviously this is not on the scale of a start up, but I think the idea of faking initial interest is actually common for any business.

The article hints at how sinister your faking is seems to affect how much backlash you get from it.

</comment><comment><USER26> Another way of looking at what reddit did, is to think of them as hacking a way to provide value to the initial users. Faking doesn't necessarily have to be about lying, it can be used to provide value, even though the system is designed to work well only when there is a significant userbase.

</comment><comment><USER27> So the meta-story is that that's what medium.com is doing right now, right?

</comment><comment><USER28> I forget where I read it, but "Pud" of F _ckedCompany and Adbrite fame explained how he used to run a BBS back in the day and the techniques (similar to the blog post) he used to get traffic carried over into how he got traction for F_ ckedCompany.

</comment><comment><USER29> This is the kind of bullshit advice you get from (non-pg) mentors at YC and places like 500-startups. Such advice has a few traits:

* It's too general to be of any use to you.

* It's too specific to be of any use to you.

* It's stuff so obvious you've probably already tried it and it obviously hasn't worked for you.

If there was a formula that worked, everyone would do it. There isn't, so general, vague sounding bullshit is the order of the day. They might as well be prescribing hanging garlic from your door. You get a couple of people who have seen success one way or another, usually through being at the right place at the right time with the right idea in a situation of extreme uniqueness, and they are never helpful. At least not strategically. They probably are helpful in terms of the business of startups: management and fundraising etc.

I think the real lesson is to just build your idea as best as you can and if there's traction it'll work, if there's signal follow it, if you don't get anywhere quickly, try harder or try something else. Or give up.

</comment><comment><USER30> So should every startup fake their way to traction?

<comment><USER31> There doesn't seem to be much drawbacks to this strategy.

I can think of very few startups that failed because of shady early tactics, as long as it stayed only a way to get to traction, and wasn't a decisive part of the business model. If you're small, nobody will care enough about you to learn about your tactics. If you're big, you should have enough money to rebuy a reputation with marketing/PR.

<comment><USER32> Except for being genuine, authentic. You can't be 90% genuine - that's not possible.

<comment><USER33> Mmm, I think you may be confusing perception vs. reality. As much as we'd like to think the two are inseparably joined and it's impossible to fake being genuine (or vice versa, impossible for a really genuine thing to be perceived as inauthentic), I don't think the facts support that idea.

</comment></comment></comment></comment><comment><USER34> I remember years ago, I had a blog entry hit the homepage of Reddit: [http://baus.net/rails-wrong-language/](http://baus.net/rails-wrong-language/) . I think the user that posted it was Linuxer or something like that. But the account had a ton of karma and there was some question if it was just a bot run by Reddit.

</comment><comment><USER35> This post is perfectly timed for us. We are trying to rise a market place and it´s really difficult to go beyond the egg and chiken problem. Even more if the model is new and there is no data to support our point.

</comment><comment><USER36> Judging from the comments so far, I'm guessing I'm in the minority. But from my point of view, all of the practices described are duplicitous and unacceptable. Yes, there is a differentiation between 'faking' and 'fraud', but this is a legal distinction. Morally, they are equally offensive. Unquestionably, lies and deceit can be useful in achieving business success. This does not mean that they should be condoned, much less encouraged.

<comment><USER37> I see no problems with faking certain things until you have gained a critical mass of users. As long as you're not scamming people out of money or doing anything that would hurt them, it's fine.

Most businesses need to do this at one point or another. If you don't, you will most likely fail.

</comment></comment><comment><USER38> Makes you wonder if that also worked for Tesla

</comment><comment><USER39> Reddit grew b/c of the fall of Digg.

<comment><USER40> This was well before that time. It was already well established when it was a competitor to Digg.</comment></comment>


Show HN: Cyberspace — an iOS browser that fits in your workflow - <AUTHOR>

I posted about my Cyberspace web browser back in November, and received tons of helpful feedback from HN users. My third release is out today, and I'd love to hear your take on it: http://cyberspaceapp.com
If you haven't heard about Cyberspace, and don't bother to open the aforementioned link, here is a rough idea of what it does:
1/ Cyberspace is built for easy reading on mobile devices, with ad blocking enabled by default, text-only mode, Readability bookmarklet support, and shutup.css integration to hide most non-sensical comments you may encounter.
2/ Cyberspace aims to fit into your workflow. If you use any of these services, you'll feel right at home:  Instapaper, Read It Later, Twitter, Facebook, Tumblr, Posterous, Delicious, Pinboard, Zootool, Evernote, and Google Reader. Sharing any content to such services takes no effort, be it links, images or text.
Don't like to share things? You're welcome to use the built-in scratchpad to store notes and ideas collected when you're browsing. Even TextExpander and Markdown syntax support are included so that you can quickly jot stuff down.
Use OmniFocus, Pastebot and/or Delibar? Cyberspace supports sending content to them, too.
3/ Cyberspace is COOL. DuckDuckGo is its default search engine, and Cyberspace automatically gives you !bang syntax suggestions as you type your address. You can also tap-and-hold any text and select Learn more to get Zero-click info from DuckDuckGo.
Cyberspace uses tags to manage your bookmarks. Import your Delicious or Pinboard bookmarks into the app and it will let you browse everything by tags. Oh, and you can tap-and-hold on any bookmarklet to add it to your Bookmarks, too.
If you have an Instapaper subscription account, you can access your unread items right within Cyberspace.
Cyberspace is also the first web browser comes with full TextExpander support and 'Bump to share' feature to quickly share links between your iOS devices.
4/...
5/...
The feature list goes on and on. If you're interested and make it this far, check out my app site: http://cyberspaceapp.com
Feedback is always welcome! <comment><USER2> <http://cyberspaceapp.com></comment>


Battleship Rangefinders and Geometry - <AUTHOR> http://mathscinotes.wordpress.com/2013/08/23/battleship-rangefinders-and-geometry/

<comment><USER2> Related: If you haven't seen this 60 year old US Navy training video on "mechanical fire control computers" it is definitely worth a watch. [https://www.youtube.com/watch?v=s1i-dnAH9Y4](https://www.youtube.com/watch?v=s1i-dnAH9Y4)

<comment><USER3> Ars Technica also did a good write-up on that subject:

[http://arstechnica.com/information- technology/2014/03/gears-...](http://arstechnica.com/information- technology/2014/03/gears-of-war-when-mechanical-analog-computers-ruled-the- waves/)

</comment></comment><comment><USER4> There are some old coastal defense bunkers/stations along the SF coastline that were used for the same techniques. Except rather than a small rangefinder station each location would act as one eye in a network to provide even greater accuracy.

TLDR Stereo vision FTW...

[http://en.wikipedia.org/wiki/Base_end_station](http://en.wikipedia.org/wiki/Base_end_station)

<comment><USER5> The Devil's Slide Trail, a brand new park along the coast south of Pacifica (south of San Francisco), has an example of one of these emplacements.

[http://parks.smcgov.org/devils-slide-trail](http://parks.smcgov.org/devils- slide-trail)</comment></comment>