Lucene: The Good Parts - <AUTHOR> http://blog.parsely.com/post/1691/lucene/ <comment><USER2> Here is a bit of interesting history that I bet few people know about.

Doug Cutting worked on VTwin at Apple long before he wrote Lucene. This was a codename for Apple's search technology they were building into the OS. I knew about it because at the time I was building computer labs for my college and bought a lot of Apple hardware (about a million dollars worth) and my rep added me to the private beta.

Many years later, when I saw the Lucene project being worked on and saw that Doug was behind it, I immediately reached out to him and asked him if he was interested in joining the Jakarta group, as I thought this would be a great addition to our growing community.

Needless to say, the rest is history, but I feel like if nobody had reached out to Doug, he may not have gotten as much exposure and may not have been motivated to start the rest of the amazing projects that he's worked on, including Hadoop.

=)

[1] [https://www.google.com/search?q=apple+vtwin+codename](https://www.google.com/search?q=apple+vtwin+codename)

</comment><comment><USER3> > SQL was not then, and is still not now, a very good blob or document storage > system.

What does that even _mean_? SQL is a wire protocol for relational queries. Document/blob/key-value stores can be made to speak SQL. Most of them just choose not to implement SQL support for some weird reason.

<comment><USER4> (Author here.) As others have pointed out, I am here referring to SQL as a broad term for "SQL RDBMSes". When I say that it is not a good blob or document storage system, what I mean is this: You can plop unstructured data into a SQL RDBMS using something like JSON serialization, but it's not generally a good idea. Document storage requires flexible schemas, so SQL schemas are also not generally a great idea -- you end up with tables with lots of nullable fields that are usually empty.

As an example, imagine a single database where you want to store actual desktop documents, such as the formats supported by Apache Tika: [https://tika.apache.org/1.8/formats.html](https://tika.apache.org/1.8/formats.html) \-- If you try to model this using a SQL schema, you'll likely be in for a world of pain. From a UX standpoint, a user just wants to "search across all documents", but you have hundreds of heterogeneous types with varying degrees of field-level compatibility.

<comment><USER5> What do you mean by "not generally a good idea"? In the past I've had little cause to complain about using XML fields to store and search semi-structured data in MS SQL Server.

I have read that it doesn't scale out as nicely as document stores do, and knowing SQL Server I don't have trouble believing that. Personally I'm a very long way away from needing to worry about scale out[1] in the applications I use a DBMS for, though, so that's never really kept me up at night.

Word I've heard on the street is that the story's similar for PostgreSQL.

[1]: [http://yourdatafitsinram.com](http://yourdatafitsinram.com)

</comment></comment></comment><comment><USER4> I was just informed today that this article, "Lucene: The Good Parts", which I wrote a few months ago, was also just published in Hacker Monthly for this month's print/digital issue (June 2015):

[http://hackermonthly.com/issue-61.html](http://hackermonthly.com/issue-61.html)

</comment><comment><USER6> I still don't understand why lucene can't use the original document for aggregations ? I undestand that it will be slower if the field isn't indexed, but it should be doable like rdbms do.

<comment><USER7> It can, as long as you store all the fields that will be needed for aggregation. Stored, non-indexed field retrieval can be slow as it might involve a lot of random seeks, so it might be slower than relation dbs.

What use case do you have in mind?

<comment><USER6> I mean in the case of _source field that elasticsearc uses. But seems that is separate. My usecase is I want to do querying+filtering on all fields of the document. In this case you have to:

1.store the field or document so you can get back the value (ex: when querying the document)

2.index the field for filtering

3.separately index the field for aggregation(doc_values)

While in rdbms you only need(1).

</comment></comment></comment><comment><USER8> Great article! Never even knew about Lucene.

</comment><comment><USER9> _sigh_ HTTPS mixed content... really?</comment>


The Commodore 65 - <AUTHOR> http://www.zimmers.net/cbmpics/c65.html <comment><USER2> Neat! It looks kinda like an updated version of the old C=128 that was my first personal computer as a kid. My dad picked that one up used from a guy at work along with a pile of floppies. I wasn't allowed to hook up the modem that completed the "package" so I didn't quite understand what a lot of the programs were for or why so many of the games had weird (but awesome) intro screens with flashy graphics and music better than anything in the actual games. That was my unknowing introduction to the world of BBSes and crack demos. Either way, that was a really fun computer to learn with. Came with a couple of massive manuals and booted straight into Commodore BASIC so I was making my own flashy screens and bleeps and bloops soon enough (god I loved that SID chip). Never did get the Amiga I wanted later on and by the time I could afford my own used computer, it was a beige box Intel machine running DOS.

</comment><comment><USER3> Reminds me of Miles Gordon Technologies' _SAM Coupe_ \- [http://en.wikipedia.org/wiki/SAM_Coup%C3%A9](http://en.wikipedia.org/wiki/SAM_Coup%C3%A9). The SAM was also a 1989 'second gen' 8-bit machine, offering backward compatibility to a classic 8-bit machine - in the SAM's case, the ZX Spectrum - in a package more reminiscent of the 16 bit Atari ST or Amiga 500.

<comment><USER4> Very much so, I had a Sam Coupe and it was a lovely machine but it came our about a year or two too late and had some firmware bugs. If it had come out in 88 or 87 it might have gained some serious traction and had spectrum users switch to it.

<comment><USER5> Its a bit like my Oric Telestrat, which was an upgrade to the Oric-1 -> Atmos machines, in that it gave a full 64k and had expansion options.

Sure was a wild and woolly period of computing - so many wonderful machines, too many different ways to develop things. Just like today, only cuter ..

<comment><USER3> The Telestrat seems to fit more in the second wave of the original 8 bit era - with the Spectrum +2, the C=128, and so on. The SAM and the C65 which this piece talks about were later (late eighties, not mid eighties) and seem to have been much more capable machines: the SAM, for example, had 256K of RAM, expandable to 4.5M, 6 channel stereo sound, and a 6MHz processor (compare to the Atari ST or Amiga 500's 68K running at 7.1-8MHz - vs. the Spectrum's Z80 at 3.5MHz and the C=64's 6502 at 1MHz). This was really about trying to create 8-bit machines which could survive in the 16-bit era, easing the transition for users and developers.

Then the whole lot got eaten by the PC.

<comment><USER6> I agree with your comment, mostly.

Just mention that comparing MHz is not quite right in that era. For example Speccy's 3.5MHz were not that much of an advantage compared with the 1MHz of the C64 if you take into account that it didn't have hardware sprites and all had to be implemented by software, 48K models didn't have dedicated audio chip, etc.

<comment><USER4> The lack of hardware sprites was easily overcome by the raw speed of the spectrums CPU. Also at anything other than sprite focused games, ie vector graphics or the like the Spectrum smoked the C64. And even with sprites the C64 hardware was limited to 8 before you had to do strange multiplexing.

Sound wise the C64 was better but in terms of speed the Spectrum dominated.

<comment><USER3> I am just delighted to have sparked a Speccy/C=64 'which is best' fight, on hacker news, in 2015. Keep that flame alive!

Of course, it goes without saying that the spectrum was best.

<comment><USER6> I didn't say what was best, I said that comparing "only" MHz is missing part of the picture. Today machines are easier to compare because they have similar functionality, but back in the day it was different.

I had a ZX Spectrum +2A back in the day and I've programmed several games for the speccy, and the attribute clash was a pain :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> my HAD comment:

'design started in 1989? Commodore was so mismanaged its not even funny :( Another pointless pet project like C128 (I had one, what a piece of shit, there was pretty much no c128 soft so you ran it in c64 mode all the time, at twice the price). They were already selling Amiga 500 in 89, and you could go out and buy 386DX 40MHz or first 486s. What were they smoking to come up with 3MHz 8bit computer when market moved on to 16/32 bit? Commodore didnt know what they had when they took over Amiga :( and kept wasting money and R&D on pos like this.'

Just to reiterate, post Jack Tramiel Commodore hired new CEO with industrial construction background who knew F-all about computers or business. This new CEO canned completed and almost ready for production Commodore laptop project because Tandy CEO told him there is no money to be made in laptops (while selling HUGELY popular TRS-80 Model 100) ... This is like GM calling Musk, and convincing him to cancel Model 3 because there is no money to be made in ~30K electric cars, while selling Volt and planning Bolt.

<comment><USER8> > What were they smoking to come up with 3MHz 8bit computer when market moved > on to 16/32 bit?

I think the A500 cost more than 8-bit money, and back then a barebones 386 from a computer shopper ad cost about the same. Add VGA, monitor, sound card, hard disk and you far exceeded the A500 cost and there still weren't many good arcade type games for the PC.

They probably wanted to sell to gamer-pirates. I remember thinking NES users were getting shafted buying $40 rom chips, when 100 floppies cost $25 and some of my friends had huge libraries to copy and trade.

Edit: I liked the C128. I used CP/M on it at times. Ultima V was cooler to play in 128 mode. 80 columns, wow, I used that all the time with a 128-mode terminal (was it "desterm?"), some word processor I can't remember now, and GEOS was better except that it did not know how to handle the display aspect.

</comment></comment><comment><USER9> Here's the blog of a guy who's building a machine based on it: [http://c65gs.blogspot.com.au/](http://c65gs.blogspot.com.au/)

</comment><comment><USER10> I remember reading about the c65 in zzap!64 back in the day.

This (old) page has a bit more info.

[http://www.floodgap.com/retrobits/ckb/secret/65.html](http://www.floodgap.com/retrobits/ckb/secret/65.html)

<comment><USER11> The complete issue on the Internet Archive: [https://archive.org/details/zzap64-magazine-079](https://archive.org/details/zzap64-magazine-079)

</comment></comment><comment><USER12> It is just a prototype they only made 50 or 200 of them.

It is backwards compatible with the Commodore 64 but runs a different CPU that runs a 3.4Mhz that can go into 6510 mode. Then a Vic-III chip that has graphics like the Amiga but backward compatible with the Vic-II chip in the C-64.

Had they made the Commodore 65 instead of the Commodore 16 and Plus 4 it would have done well. But by 1990 the 8-bit market was bottoming out as the PC Clones took over.

</comment><comment><USER13> Here's one for sale. [http://www.ebay.com/itm/Commodore-65-64DX-C65-Engineering- Pr...](http://www.ebay.com/itm/Commodore-65-64DX-C65-Engineering- Prototype-/111595140820?pt=LH_DefaultDomain_0&hash=item19fb96b6d4)

<comment><USER14> And here's a more complete one that just sold on eBay - for $22,000...

[http://www.ebay.com/itm//171673209321](http://www.ebay.com/itm//171673209321)

</comment></comment><comment><USER15> Amazing! I wish I had seen one at the Commodore tent during the 2010 TNMoC event. I guess they are very rare indeed. Would be good to get one in the The National Museum of Computing in the UK.

Also, slightly strange timing - this came up in last weeks B3ta newsletter.

</comment><comment><USER16> Nice, lol</comment>


Lucid Software uses Typesafe for next generation platform [pdf] - <AUTHOR> http://typesafe.com/public/case-studies/Lucid%20Software%20Case%20Study%20v1.0.pdf

<comment><USER2> I'm sorry but I fail to see much value in this pamphlet. It's just the same old message from Typesafe (productivity! scalability!) wrapped with buzzwords and anecdotical data.</comment>


My Lisp Experiences and the Development of GNU Emacs - <AUTHOR> http://www.gnu.org/gnu/rms-lisp.html?

<comment><USER2> _The interpreter we wrote in that actually wasn't written for Emacs, it was written for TECO. It was our text editor, and was an extremely ugly programming language, as ugly as could possibly be._

For proof, see the source code here: [http://pdp-10.trailing- edge.com/mit_emacs_170_teco_1220/inde...](http://pdp-10.trailing- edge.com/mit_emacs_170_teco_1220/index.html)

It is certainly heavily annotated for good reason.

<comment><USER3> TECO was so ugly because the command language and the programming language were the same thing: You programmed TECO by entering the same commands you used to do editing with it, and those commands were both terse and made heavy use of control characters.

On the other hand, it was also a high-level programming language with native support for strings and regular expressions and, of course, the editor qualified as an interactive interpreter. TECO-the-language actually got reasonably popular within the communities that used it as an editor, especially the ones that had the more advanced TECO variants with all the bells and whistles.

<comment><USER4> Here's a relevant article by MarkCC (PhD, Google), on "The Glorious Horror of TECO". [http://scientopia.org/blogs/goodmath/2010/11/30/the- glorious...](http://scientopia.org/blogs/goodmath/2010/11/30/the-glorious- horror-of-teco/)

</comment></comment></comment><comment><USER5> _Once I stopped punishing Symbolics, I had to figure out what to do next. I had to make a free operating system, that was clear — the only way that people could work together and share was with a free operating system._

 _At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode. That's what made it possible to run programs as fast as other computers would run their programs and still get the benefit of typechecking. Without that, you would be reduced to something like the Lisp compilers for other machines. The programs would be faster, but unstable. Now that's okay if you're running one program on a timesharing system — if one program crashes, that's not a disaster, that's something your program occasionally does. But that didn't make it good for writing the operating system in, so I rejected the idea of making a system like the Lisp machine._

Is this something that is still relevant to modern attempts at making a Lisp operating system?

<comment><USER6> No. Actually, the reverse of that was one of the reasons why the Lisp Machines (<http://en.wikipedia.org/wiki/Lisp_machine>) ultimately failed (among others): commodity hardware could run Lisp as fast or faster than custom hardware.

Nowadays, the hardware doesn't limit the creation of a Lisp OS, but many other things do. 1) Getting people that want to do the work (<http://linuxfinances.info/info/lisposes.html>) 2) The fact that you can run perfectly good Lisp implementations on top of general purpose OSs significantly decreases the need for a Lisp OS. 3) Lisp isn't as popular as it once was (or should be :)

<http://lists.tunes.org/mailman/listinfo/lispos/></comment></comment>


Bunk bed is $1,200 a month, privacy not included - cadence- https://www.cnn.com/2019/07/05/success/podshare-co-living/index.html <comment><AUTHOR> Somehow I just don't see sexual assaults or even sexual activity not happening in a place like that.</comment>


TypeScript 3.7: The Biggest Features and How to Use Them - <AUTHOR> https://httptoolkit.tech/blog/5-big-features-of-typescript-3.7/ <comment><USER2> If you're too impatient to wait for first-class optional chaining in TS, there's a nice open-source library for it that's been around for a little while:

Repo: [https://github.com/rimeto/ts-optchain](https://github.com/rimeto/ts- optchain)

Blog post with some details: [https://medium.com/inside-rimeto/optional- chaining-in-typesc...](https://medium.com/inside-rimeto/optional-chaining-in- typescript-622c3121f99b)

(I don't work for Rimeto, but a close friend did, which is how I stumbled on that blog post.)

<comment><USER3> Hadn't seen this before, but I've been using a library from Facebook called idx:

[https://github.com/facebookincubator/idx](https://github.com/facebookincubator/idx)

Idx is a bit more verbose because you have to write an arrow function for each invocation, and it doesn't support default values.

</comment></comment><comment><USER4> The "Assert signatures" feature looks _excellent_. The biggest issue with typescript has always been validating external inputs actually meet the type contracts that your code says they do. With this, it looks like this could be written as library!

<comment><USER5> How do you verify it now? I've been using typeguards, but since i haven't found a good way to generate interfaces from typeguard functions or typeguard functions from interfaces I have to do each manually:

      interface ContactInfo {
        address_1: string;
        address_2?: string;
        city: string;
        state: string;
        zip: string;
        phone: number;
      }
      function isContactInfo(arg: any): arg is ContactInfo {
        let valid = false;
        const contactInfoFields: { readonly [key: string]: string[] } = {
          address_1: [ 'string', ],
          address_2: [ 'string', 'undefined' ],
          city: [ 'string', ],
          state: [ 'string', ],
          zip: [ 'string', ],
          phone: [ 'number' ],
        };

        if (typeof arg !== 'object') {
          return valid;
        }
        for (const key in contactInfoFields) {
          if(!contactInfoFields[key].includes(typeof arg[key]) || arg[key] === '' || Number.isNaN(arg[key])) {
            return valid;
          }
        }
        valid = true;
        return valid;
      }

<comment><USER6> Not related to the new assert signatures feature (which is great!), but IMO the two best approaches to do what you want today are:

\- io-ts[1]

This requires you to write your types as a runtime value, and allows you to extract static types from those, e.g.:

        const ContactInfo = t.type({
           address_1: t.string,
           ...
        })

        type ContactInfo = t.TypeOf<typeof ContactInfo>

You can validate objects with `ContactInfo.decode(someObject)`

Note that we can have the same name for the type and value because they live in different namespaces. When you do ContactInfo.decode, you're calling the decode property of `const ContactInfo`. When you use `ContactInfo` in a type position (e.g. `function x(arg: ContactInfo)`), you're using the `type ContactInfo` declaration

\- typescript-is[2]

This uses TypeScript's transformer API. You can use it with [https://github.com/cevek/ttypescript](https://github.com/cevek/ttypescript). It generates validators for your interfaces/types/etc at compile-time.

[1]: [https://github.com/gcanti/io-ts](https://github.com/gcanti/io-ts)

[2]: [https://github.com/woutervh-/typescript- is](https://github.com/woutervh-/typescript-is)

<comment><USER5> typescript-is looks like it can be a drop-in solution since we're only dealing with PODS. Thanks!

</comment></comment></comment></comment><comment><USER7> My wishlist for Typescript is:

1\. Pattern matching switch against types(like Scala, Haskell, Ocaml)

2\. Input validation based on the already defined typescript interfaces

<comment><USER8> 1\. Use discriminated union types: [https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced- types.html#discriminated-unions) \- TypeScript these days sticks with the runtime semantics of JavaScript, and discriminated unions are a very natural way to express algebraic data types in JS.

2\. Use [https://github.com/YousefED/typescript-json- schema](https://github.com/YousefED/typescript-json-schema) to generate a JSON schema, then use a json schema validator to do runtime validation. That's how [https://github.com/Polymer/tachometer](https://github.com/Polymer/tachometer) handles config file parsing and it works very well.

<comment><USER7> My only problem with 1. is that it desn't work that well with Error

<comment><USER9> Also, (1) won't be exhaustive.

<comment><USER10> There are a few ways to get exhaustiveness checking in TypeScript when using tagged unions. The way I usually do it is an assertNever function like this:

        function assertNever(value: never): any {
          return value;
        }

Then if you call assertNever on your variable in the default switch case or the last else block, TypeScript will error if you didn't handle every case, since it expects the variable to have been narrowed to the "never" type since there's no remaining value that it can take on. That's also a good place to do a runtime check since TS types aren't guaranteed to match runtime values.

</comment></comment></comment></comment></comment><comment><USER11> This is really starting to remind me of Swift.

Coming from Swift, undefined and null handling always felt clumsy in both Javascript and Typescript.

Glad I'll finally get my optionals and nil coalescing back; I've missed them ever since I moved from iOS development to FaaS.

<comment><USER12> it feels like the new features for recent languages are starting to look the same because they're nice. Kotlin has this stuff too. Rust and Kotlin have a similar style of null handling.

<comment><USER13> Point well made. I've spent some time with TS, Rust, and Kotlin recently and I really enjoy how they all have these kinds of features. Really feels like they see how well it works elsewhere and learn from one another.

</comment></comment></comment><comment><USER12> I don't really care for typescript much but the optional chaining and null coalescing for vanilla are very nice.

<comment><USER14> Yeah I was going to say the same thing - love that optional chaining syntax... Would cut down so many checks and balances needed to avoid those errors.

</comment></comment><comment> lf-non Availability of recursive-types is a great news for users of libraries like Mobx state tree [1] which heavily lean on inferred & derived types.

Circular type references among MST models have so far required quite a bit of ceremony [2] to deal with. Really looking forward to get rid of that boilerplate.

[1] [https://github.com/mobxjs/mobx-state- tree](https://github.com/mobxjs/mobx-state-tree)

[2] [https://lorefnon.tech/2019/08/15/dealing-with-circular- type-...](https://lorefnon.tech/2019/08/15/dealing-with-circular-type- references-in-mobx-state-tree/)

</comment><comment><USER15> These are all amazing features

I am really hoping for private properties and compiler support of class properties (it supports the syntax, I think, but doesn't compile them down from what I understand).

I also hope they update their decorator support to be in line with [https://github.com/tc39/proposal- decorators](https://github.com/tc39/proposal-decorators)

I know its stage 2 (and it was stage 3, I think) but I think the reasoning behind the major(ish) changes are solid ones.

Thats pretty much it. Now tc39 just needs to acceept Reflect.metadata :)

</comment><comment><AUTHOR> [https://www.reddit.com/r/programming/comments/d38rp9/typescr...](https://www.reddit.com/r/programming/comments/d38rp9/typescript_37_the_5_biggest_features_how_to_use/)

</comment><comment><USER16> Nice to see optional chaining. It was the one feature I missed the most from CoffeeScript. The null coalescing is also nice - I've been bitten more than once with falsy values reverting to defaults on assignment.

</comment><comment><USER17> Anyone have some book or course recommendations for learning Typescript??

<comment><USER18> The TypeScript Handbook [0] is where I've learned the most from. The New Handbook [1] is starting to come together as well, it's not complete though.

[0]: [https://www.typescriptlang.org/docs/handbook/basic- types.htm...](https://www.typescriptlang.org/docs/handbook/basic-types.html)

[1]: [https://microsoft.github.io/TypeScript-New- Handbook/outline/](https://microsoft.github.io/TypeScript-New- Handbook/outline/)

<comment><USER17> that's pretty good actually, thanks!

</comment></comment></comment><comment><USER19> I may not be the sharpest, but isn't top level await just shoehorning synchrony into a language that has been laughing at synchrony for decades?

<comment> lf-non top level await doesn't make async operations synchronous.

It mostly eliminates the need to have immediately evaluated wrapper async functions that we would have needed so far.

(async () => { await foo(); })();

The added benefit is that imported scripts would be implicitly awaited upon, which has been clunky to do otherwise - you'd need to have a module that exposes an async function and expect the consumer to await on them. But the moment you do that you'd no longer be able to directly run the script through node, so you'd end up needing one more file that imports this module and runs it directly.

Availability of top-level await makes experimenting with (promise-returning) APIs in REPL much easier. It is also a bit step forward in making typescript more useful as a general purpose scripting language (outside webdev context).

<comment><USER19> > top level await doesn't make async operations synchronous

No, it just lets us write them like they look in synchronous languages.

So we're jumping through even more hoops to avoid the realities of asynchronous JS. IMO it's better for the asynchrony to be explicit. A whole generation of frontend devs aren't going to have any idea how their code is actually running.

</comment></comment></comment><comment><USER20> Does anyone know when TypeScript plans to introduce dynamic typing for function/method parameters? It would be very useful if TypeScript could infer the type of variables at runtime so that you never have to specify it.

<comment><USER21> I may have missed your point, but wouldn't this be essentially useless? You then have no type information about the parameters at all. Wouldn't this just be the same as the existing implicit "any" type when not in strict mode?

<comment><USER10> Strongly typed functional languages (including Reason) can often figure out a function's parameter types based on how the variables are used in the function. For example, given `(a, b) => a.push(b * 2)`, it could figure out that `b` must be of type `number` and `a` must be of type `Array<number>`, so the function author wouldn't need to write the type annotations.

I think it's likely that TypeScript will never implement this (at least not at the level of sophistication of typical functional languages), given that it adds a lot of complexity to the language, and making types explicit at boundaries is usually good practice anyway.

<comment><USER22> It's arguable that they might, actually, add this in the future, but ... it would probably show up as part of how you can use TypeScript to type-check your JavaScript code such as when it infers types from JSDoc.</comment></comment></comment></comment>


10 Questions for John Gruber Regarding H.264, WebM - <AUTHOR> http://www.osnews.com/story/24245/10_Questions_for_John_Gruber_Regarding_H_264_WebM <comment><USER2> First, these aren't 10 questions for John Gruber; it's 5 questions, with one of them phrased slightly differently 5 times, and another phrased two different ways.

Second, virtually all of these questions take as an axiom that H.264 is IP- encumbered and WebM/VP8 isn't. Technical analyses (by people who have actually implemented H.264 and are familiar with the patents) suggests that that simply isn't the case. That the author of this article thinks that VP3's release prior to H.264 might invalidate any part of the H.264 patent pool suggests that he may not be at all familiar with the patents in play.

Similarly, support for a "known patent troll" isn't germane to the debate if that patent troll is in the mix one way or the other, which appears to be the case.

Third, the fact that the H.264 patent pool hasn't been brought to bear on On2 tells us nothing at all about how successful H.264 would be against WebM; it's not at all unlikely that MPEG-LA sees nothing worth suing in Xiph/On2, and if that's the case, it is surely a different situation once Google pushes adoption.

Fourth, an "open pledge of support" for WebM from chip manufacturers is worth exactly nothing to the people who have spent many many hundreds of millions of dollars on mobile devices with hardware-accelerated H.264. One can reasonably argue that those people don't matter, but they can't with a straight face suggest that a "pledge of support" in any way mitigates the problem.

There's nothing wrong with this post as a contribution to the WebM/H.264 Apple/Google debate. But one gets the sense that the author sees it as some sort of devastating argument. I'm not sure he realizes that handwaving around "known patent trolls" and "decades of threats by MPEG-LA" and "is it because said codec isn't promoted by Apple", he's actually making a fairly weak sounding argument. He sounds emotional.

I'm gonna go with the analysis of the guy who said his B-frame implementation gave x264 the project's single greatest encoding quality improvement over the guy who thinks the release date of VP3 determines which patents encumber VP8, thanks.

<comment><USER3> By "people who have actually implemented h.264 and are familiar with patents", I assume you mean Jason Garrett-Glaser from his x264dev blog ( <http://x264dev.multimedia.cx/archives/377> ). There aren't any patents explicitly mentioned, just that vp8 "feels" a lot like h.264. In that post, there was only one reference to a specific feature, the intra prediction, which was updated with "Update: spatial intra prediction apparently dates back to Nokia's MVC H.26L proposal, from around ~2000. It's possible that Google believes that this is sufficient prior art to invalidate existing patents — which is not at all unreasonable!".

The idea that VP3's prior release making AVC infringing is pretty stupid.

<comment><USER2> You make a valid point that I should have acknowledged. That said, what I'm doing is comparing _this_ post, which seems deeply uninformed, to Garret- Glaser's post, which isn't.

I'm not expert on video patents either. The overarching issue is, this post seems to think the IP situation with WebM is virtually cut-and-dry, and we have every reason to believe it isn't.

<comment><USER4> I don't think "it probably infringes software patents in the US" is a reasonable argument against using a specific piece of software. Aside from the arguments against the legitimacy of software patents, it's practically tautological to say that non-trivial software infringes on patents, somewhere.

<comment><USER5> Here's the problem with that line of argument: while it may hold true for software patents, when it comes to online video one of the fastest growing categories of end-users are people viewing video on mobile and embedded devices. These devices use dedicated hardware to decode video without killing the available power budget. If there is anything behind the claims that WebM infringes upon MPEG-LA patents then you are not going to see the lawsuits drop until real devices are shipping with dedicated hardware decoders. Such devices are easier to nab at borders and by getting an injunction against the importation of these devices the MPEG-LA would also start the process with an action that will directly hurt the bottom-line of the alleged infringing party.

<comment><USER6> If I understand correctly, the h264 license would protect these device makers from lawsuits since the devices probably decodes both h264 and WebM. Thus they already have a license to the patents and the MPEG-LA can't do anything about them.

</comment></comment></comment></comment></comment></comment><comment><USER7> Maybe I missed it, but I don't recall Gruber taking issue with the webM move, in and of itself. I read his posts as just being part of his continued critique of Google's pitching itself and its various business decisions as "open" and/or "good".

I mean that's been the recurring theme on that site re: corporate Google for years now. He's not throwing darts when Google does something in their own best interests. He's throwing darts when Google tries to spin those moves as being moves made in the interests of users, 'open development', free puppies and hugs for everyone, etc.

<comment><USER8> Yes and he also takes issue when Apple slightly improves a technology that's been available for years and markets it as "revolutionary."

Come on. It's marketing. Too many black kettles and pots to count.

edit: second paragraph of parent post has been slightly edited since I posted this. Originally it only mentioned "open" without users, puppies, and hugs.

<comment><USER7> Saying "We're the best" is qualitatively different than saying "We're the good guys".

<comment><USER9> And outside of poorly-written movies, the 'bad guys' never think they're bad guys. They always have reasons for what they do, and whether those reasons make sense to us or not, it's enough for them. Likewise, a lot of 'bad guys' lie because they think it's in everyone's best interests. For example, telling the public that there are WMDs in Iraq - it's a lie, but Saddam Hussein is dangerous so we need to lie to people so they'll support us, because otherwise they _just won't understand_.

I feel the same way about Google. They spend a lot of their time trying to convince people they're the good guys, except that, like any corporation, they're wholly self-serving. I find it less than difficult to imagine them having reasons that make them feel like the good guys, while those reasons would make us feel like they're the bad guys.

In this case, they're trying to cram WebM down everyone's throats, supposedly because it's better for us. They're doing so by removing support for de-facto standards in their browser, and talking up a lot of rhetoric about free and open standards, but what they're really doing is trying to move from a format that a consortium controls to a format that _they_ control. Until they submit WebM to a standards body, I can't believe that this is all for our benefit.

</comment></comment></comment></comment><comment><USER10> To get clarity of thought on the debate, go back and read <http://x264dev.multimedia.cx/archives/377>

Everybody seems to be crying "but hardware support is coming soon!" without seeing it's difficult: "The unfortunate problem with this is that it's a nightmare for hardware implementations, greatly increasing memory bandwidth requirements."

It comes down to WebM/VP8 being inferior (in specification and implementation) to an existing widely deployed (in bits and gates) codec.

Feel free to argue the fallacies of the osnews questions if your time is worth nothing.

<comment><USER3> Does anyone else feel it's weird that there's only one blog that everyone happens to link to whenever something related to vp8 springs up? It's been half a year, you would think there are independently arrived analyses by now.

Most people could probably agree that taking everything that John Gruber says as the truth without any other sources is a bad idea, but that's exactly the landscape of evidence presented for/against vp8. Thankfully, Dark Shikari's writeup is great, but there really needs to be more evidence.

<comment><USER10> It's strange everybody points to the same source, but it's not unusual there is only one source.

Break it down: How many codec developers do you know? How many of those people do open source implementation comparisons? How many of those write it up? How many of _those_ write it up intelligently for public consumption?

<comment><USER11> Also, there are probably many people (myself included) who are familiar with implementation details of video codecs, but after reading Jason's articles decide that he basically said everything there was to be said.

</comment></comment></comment></comment><comment><USER12> Gruber's post wasn't about being a proponent of H.264. It was asking why Google was being so hypocritical with (1) Flash still bundled in Chrome and (2-3) their flagship support of H.264 with Android and YouTube.

It's one thing to be a proponent of the open web. However, it is just amazing the length people will go to in this "debate" to justify Google's hypocrisy. This is a corporate strategy move aimed at controlling the market and jamming up Apple and it's hundreds of millions of devices that play H.264. Gimme a break.

<comment><USER13> These scenarios are just not analogous so there's no way to be hypocritical or not hypocritical.

On the one hand you have Flash, which has been around for ages and you can't just take it out without breaking a lot of the web. If someone found an open way to render Flash (like if Flash Gordon somehow got good enough to do it), I _guarantee_ you that Google would remove Flash. They would much prefer this to having to bend over backwards to render it in a different process and blah blah blah. The only reason Apple was able to remove Flash was because they entered the mobile landscape, where having a browser that couldn't render Flash still rendered more of the "real web" than most competing mobile browsers at the time. However, you don't see them dropping support for it in Safari (and not including the plugin on some macs is not dropping support). If you _couldn't_ run flash at all on a Mac, ever, it would be disastrous.

H.264 on the other hand is a brand new technology, there is still time to make the right move before we end up in the same position as we are with Flash today: everyone wanting it gone but it not being easy to remove it (similar to the GIF situation as well). On top of that Google controls the biggest video supplier of the web, thus they have the additional ability to make the transition less painful.

<comment><USER12> _> On the one hand you have Flash, which has been around for ages and you can't just take it out without breaking a lot of the web._

Google does not need to bake Flash into Chrome. Somehow browsers have survived a decade without the need. Google's stance is bullshit corporate strategy. You bending over backwards to justify it is just comical.

 _> If you couldn't run flash at all on a Mac, ever, it would be disastrous._

For Adobe. It's not going to affect anyone's purchase of a Macbook just as it didn't affect anyone's purchase of an iPad.

 _> H.264 on the other hand is a brand new technology_

Wrong. H.264 has been around for 7 years. It has hardware decoders in nearly every mobile device. It encodes 2/3 (and probably more now) of the web's video. It's used by almost every single major content provider.

It is WebM that is the new technology. Released 8 months ago to be precise. No hardware support yet (sorry, releasing VHDL designs doesn't count), almost zero content support, etc, etc. This isn't even close.

 _> there is still time to make the right move before we end up in the same position as we are with Flash today: everyone wanting it gone but it not being easy to remove it_

Except no one wants H.264 gone. It's a high quality standard supported by devices everywhere.

 _> (similar to the GIF situation as well)_

The GIF situation turned out fine. Thanks for the great counterexample to your logic.

<comment><USER14> > Google does not need to bake Flash into Chrome

Might I inquire where I can find Google Flash in Chrome? I only have Adobe Flash. Until you can show me a Google developed Flash, it's merely Google shipping an Adobe plugin, which is not the same as actively supporting H.264.

</comment></comment></comment></comment><comment><USER15> It's doubtful Gruber will address this, as it would be a bit like hammering a square (logic) into a circle (Apple).

My personal fav:

      If Apple were to switch to WebM and drop H.264 tomorrow,
      would you then herald it as a great move?

Most likely. PowerPC to Intel, anyone?

<comment><USER16> Apple supported PowerPC for 2 years after the transition. Ignoring that fact, well said.

<comment><USER9> And PowerPC content (applications) worked fine on Intel Machines for years (and still does if you install Rosetta).

The same couldn't be said if Apple dropped support for H.264. Old content would cease to work immediately.

<comment><USER16> Well, you could use VLC or an application that does not rely on system codecs or quicktime, but you are exactly right.

</comment></comment></comment></comment><comment><USER17> " _Are you aware of the fact that On2 released VP3 before H.264 was released (2000 vs. 2003), and that therefore, the MPEG-LA most likely infringes on On2 (now owned by Google) patents?_ "

That does not follow at all.

edit: I should say that it only follows if the patents in the patent pool apply exclusively/specifically to H.264.

<comment><USER18> Your point is excellent.

The thing to remember is that when two systems each have patents, it's a false dichotomy to ask which set of patents trump the other. It's entirely possible that VP3 infringes on MPEG-LA patents _and_ H.264 infringes on On2/Google patents.

The chronology of the two is nearly irrelevant.

<comment><USER19> >The thing to remember is that when two systems each have patents, it's a false dichotomy to ask which set of patents trump the other.

Where is the false dichotomy?

The current talking point on the h264 versus WebM war is that WebM is a patent landmine, while your back is covered with h264. There is some sort of broad belief that h264 is a universal got-your-back patent defense, and that is simply ludicrous.

<comment><USER20> The false dichotomy is exactly as he said: that one or the other has to be infringing on the other.

As to your point, h264 has been on the market for a while now and is implemented by some seriously deep pockets. If you were the captain of the submarine patent ship, you would probably have fired the torpedos by now. If you're a new company, you'll feel pretty safe standing with Apple and all of the other MPEG licensees who have a vested interest in fighting. This is not the case with WebM.

</comment></comment></comment></comment><comment><USER3> The argument with the licensing fees for Mozilla to implement h.264 is probably a non-issue, and it doesn't do justice to frame it as such. The Mozilla Corporation does have a revenue stream (largely from Google) and MPEG- LA would probably be willing to allow Mozilla to license without paying the fees given their pivotal role in the fate of the de-facto standard. Operating systems often provide h.264 decoder APIs, like in QuickTime and Windows Media Player that they could use to circumvent the licensing fees.

Mozilla is doing it entirely out of ideology (and sticks to their ideology much more than Google usually does).

<comment><USER8> Cool. How about licensing fees for Opera? For any other browser maker?

<comment><USER21> Why would Opera get a special deal? It's not like they make an open source browser. It seems misplaced to give handouts to a publicly traded company, with offices in ten countries, and who receive $80 million in revenues a year.

<comment><USER8> But that's exactly the point. You can give Mozilla special treatment, but that only underlines the fact browser makers will have to pay unless you specifically exempt them.

</comment></comment></comment></comment><comment><USER21> _"# 10 [...] If Apple were to switch to WebM and drop H.264 tomorrow, would you then herald it as a great move?"_

I bet it would help, but I don't see Apple doing that anytime soon.

Currently, Apple uses PowerVR and nVidia chips for hardware decoding in iDevices and Macs, and those companies have already shown interest in building chips that offer WebM support. But Apple would have to find some way to support WebM hardware decoding on current devices, something like a Rosetta layer for video playback.

If Apple were to only include full support on new devices, it would feel the wrath of the entire tech press, not to mention organizations like Consumer Reports and Greenpeace. Apple only risks that kind of bad press when it's about a technology they've authored themselves.

<comment><USER22> I doubt Consumer Reports or the tech media would have much to gripe about WebM hardware decoding support being added to new iDevices, since there is no compelling WebM-exclusive content to which current device owners would be deprived access, (we'll leave Greenpeace out of this, as it's often difficult to rationalize their behavior). There is little risk to Apple's reputation with their customers by hedging their bets and including WebM support; only potential increased component costs, less optimal power consumption and patent litigation.

On the latter, I'd estimate the risk that the MPEG LA would go after an MPEG 4 licensee (and member of the MPEG organization) for violating the patents they have already licensed to be fairly slim; one might expect them to focus more on non-MPEG-licensed vendors distributing WebM decoders and encoders. So if the power usage and component costs are reasonable, there should be little obstacle for Apple.

<comment><USER21> The author's proposal is that Apple adopts WebM and drops all support for h.264.

That would mean that (amongst other things) all video content from the iTunes Store would have to be reencoded for WebM and the YouTube app on iOS would stream WebM instead of h.264. But that way, older Apple products won't have access to the majority of online video, or if Apple provides software decoding, battery life will suffer significantly.

I can't imagine Apple even considering such a move, but if they did, don't you think the press would have a field day?

<comment><USER22> The article's author was simply trying to make a point, not implying that Apple was in any way likely to actually drop support for h.264. The post I was responding to never addressed the possibility that Apple might do such a thing. Let's get real here.

</comment></comment></comment></comment><comment><USER23> The author seems to want to frame Google's WebM move as a question of Good vs. Evil (as does Gruber btw.), which is not very helpful. As with most everything, there are both costs and benefits.

The main benefit is that Google's move may reduce the risk that the MPEG consortium goes crazy in the future, and starts to charge every possible user, causing havoc in the process.

The main cost is more certain: a huge inconvenience for content producers that were hoping to get away with going H.264 only, causing havoc in the process.

The interesting question is the usual one: is the benefit worth the cost?

<comment><USER24> I don't think Gruber is framing it as "good vs evil".

More - "why are you dropping support for H264 on grounds of openness but not dropping support for Flash (and MP3 and AAC) on those same grounds?"

</comment></comment><comment><USER25> The only problem I see is the iPhone and iPad.

All other browsers are open enough to get native support or have a plugin. Android phones will have support. Who knows or cares what happens on WP7...

Google is taking a stand. It is annoying that Google is removing existing support for h264. It will be annoying if Apple is completely against adding a software WebM decoder for current gen iOS devices, and ignore hardware solutions on next gen ones. But both companies are free to do whatever.

I also think this will have negligible impact in the real world. Youtube will always work on whatever. Content providers can just upload stuff there if they don't want to manage multiple formats themselves.

</comment><comment><USER26> I may feel more sympathetic to the author of these questions, but they are ultimately just as rhetorical and passive-aggressive as Gruber's - i.e. not a particularly useful contribution to the debate.

</comment><comment><USER27> With mobile being more important in the long run than desktops, and Android gaining ever more importance over the iPhone, we just need Google adopting their open codecs in both Android hardware and YouTube, and it's game over for h.264.

<comment><USER28> Yes, most definitely, I mean who would want to cater to a giant install base of people who you know actually _buy_ software and are willing to pay a premium for UX.

Google cant put hardware into most Android _devices_ because they don't make them. Heck, you can barely upgrade your Android software on most carriers/devices. Google should first figure out how to prevent carries/manufactures from installing crapware on their handsets.

<comment><USER29> Well, the upcoming generation of mobile chipsets supports VP8. Tegra 2, for example, supports both decoding and encoding of VP8.

<comment><USER30> I hadn't heard that (and thought I'd been paying attention), so if anyone else was doubting _vetinari_ , here's a link:

<http://www.nvidia.com/object/tegra-2.html>

Claims decode for Theora, VP8 and Vorbis, as well as encode and videoconference for VP8.

Basically every Android tablet at CES was Tegra 2 (I think it's the reference platform for Honeycomb) as well as a few of the high-end phones e.g. Motorola Atrix

</comment></comment></comment></comment><comment><USER30> 11\. Why are you quoting random conspiracy theory Slashdot comments to support your take on H.264 vs. WebM?

<http://daringfireball.net/linked/2011/01/12/slashdot-comment>

<comment><USER31> Because they contain a nice argument? Duh!

</comment></comment><comment><USER32> Ugh, I'm so sick of seeing arguments to or from Gruber. He's like a constant Apple soap opear. Google is a business and they're allowed to make decisions. Switching to WebM saves them money, pushes their codec, and their users (Chrome) lose ZERO functionality. Google obviously feels that this switch is beneficial to them and their users in the long run. If you disagree, don't use Chrome.

<comment><USER33> Those who forced you to click the link have been sacked.</comment></comment>


NORAD Chief:N. Korea Has Ability to Reach US with Nuclear Warhead on Mobile ICBM - <AUTHOR> http://news.usni.org/2015/04/07/norad-chief-north-korea-has-ability-to-reach-u-s-with-nuclear-warhead-on-mobile-icbm <comment><AUTHOR> ""[All] that said — should one get airborne and come at us — I'm confident we'll be able to knock it down," he said."

I'm really curious about that quote. What part of SDI got deployed?

<comment><USER2> The Ground-Based Midcourse Defense.

With a <=50% success rate in intercept tests over the last 10 tests, that claim of confidence is surely unfounded.</comment></comment>


Has the biggest Indian anti-corruption movement ended? - <AUTHOR>

Is the decision of Indian anti-corruption movement to become political, a right decision or wrong decision? <comment><USER2> I think Congress has yet again proved herself, that she does not give a damn about "Anna" and "his movement".

I must say with pravin bansal announcing that "lokpal will not even be present among topics to be picked up in the monsoon session" just after Anna quit his fast was a class act.

I guess , politicians are truly afraid of anything not even of people. I suggest Arvind Kejriwal should give up on the jaiprakash narayan's motto.

<comment><AUTHOR> Everyone is sure that there will be an anti-congress wave in the next elections, but is that going to be divided between BJP and Anna party, is an important question.</comment></comment>


Bitcoin: Free Money or Fraud? - <AUTHOR> https://www.coindl.com/page/item/118

<comment><USER2> Title was a bit confusing. You aren't purchasing bitcoins, you are purchasing goods using bitcoin. Big difference.

Great service though, I use it as both a supplier and a customer!

And found a couple new songs for my playlist!

<comment><AUTHOR> Confusing? or genius. 80 chars or less means the line is often blurred.

<comment><USER3> Confusing I would say.

</comment></comment></comment><comment><AUTHOR> Subby here. For a demo of how the purchase process works see [http://www.youtube.com/watch?v=sVBxvnQEy9o&hd=1](http://www.youtube.com/watch?v=sVBxvnQEy9o&hd=1)

In the first couple weeks we have added 40 suppliers and 100 downloadable items. We take a competitive 20% of sales and pay in 48-72 hours. We're looking for feedback on who to approach for supplier relationships, startup mentoring, and funding.

<comment><USER4> > We take a competitive 20% of sales

That's actually pretty high in terms of BTC markup. There are BTC payment solutions out there that take less. Is the proposed value-add here a kind of content discovery service a la App Store?

> pay in 48-72 hours

Surely this can be optimized? 6 confirms is the standard of trust even for enormous transactions, and automatic payouts after such a threshold are simple to implement (yes, I've done it).

The time lag seems kind of artificial here and brings to mind the BS of traditional banking/payment processing. Is there some reasoning behind it?

> We're looking for feedback on who to approach for supplier relationships, > startup mentoring, and funding.

If you'e looking for funding, you're going to hear this a lot: "seems more like a feature than a product". It's too early to be thinking about investments.

Is the idea to become a general for-download BTC marketplace? If so, you're probably doing the right thing in terms of going after the small / independent fish first. Find some sort of niche and eat it. Start worrying about investors when there's so much demand that you can't handle it on your own. You seem to be managing well enough so far, though.

Congrats on the launch!

<comment><AUTHOR> > Is the proposed value-add here a kind of content discovery service a la App > Store?

Yes, the goal is to make it as easy as possible for artists and authors to sell their downloads for Bitcoin. We could make shopping cart software and charge 1-2% but we're covering fulfillment, support and everything else about the process to make it easy for both sides.

>> pay in 48-72 hours

> Surely this can be optimized?

The reasoning behind this is to be able to deal with any complaints, in the app store model there is usually a short return period and in order to be able to provide that we need a little time. The delay also may serve to deter scammers who might want to list someone else's work, promote it heavily and run with the money.

Thanks for the investment comment. This is ycombinator so I thought I'd throw it out there.

</comment></comment></comment><comment><USER5> As far as I'm aware of, the blockchain only gets signed every few minutes or so.

So how can you achieve this low latency? Do you just base your decision "x has paid" on the still unsigned chain? That's quite risky and open for exploits, isn't it?

Also, what do you do if there are orphan blocks in the chain?

(Comment about coindl.com, not the book the article links to.)

<comment><AUTHOR> New blocks are created in a lottery process (mining) that could take seconds to hours for someone to win. We are using unconfirmed transactions but are willing to take some risk while developing strategies to mitigate that risk. Orphan blocks don't concern us so long as the transactions we are honoring make it into the greatest-height chain.

<comment><USER5> Thanks for the answer!

Why don't you focus just on the realtime aspect and create a service that allows realtime bitcoin transactions on any website (and inside every app) trough an API, and ask for a smaller percentage (like ~2%, like a credit card company)?

<comment><AUTHOR> There are already a number of merchant processing systems for Bitcoin including MtGox's payment api and Bit-Pay. Neither one supports instant transactions coming via the Bitcoin network (MtGox is instant if buyer and seller both have funds there), but the cultural aspect of helping Bitcoin users sell their wares easily was also an attractive one for this project.

Still, it's a great suggestion and will be considered for future development.</comment></comment></comment></comment>


Algorithmic trading in less than 100 lines of Python code - <AUTHOR> https://www.oreilly.com/learning/algorithmic-trading-in-less-than-100-lines-of-python-code <comment><USER2> Article is from 2017</comment>


Best Way to Learn VBA for Excel - <AUTHOR>

Did some Googling for learning VBA for Excel and didn't find any standout resources. I know some java and python. Anyone have any suggestions of resources they have found useful. Thank you! <comment><USER2> Refer to Microsoft's reference:

[http://msdn.microsoft.com/en- us/library/office/ee861528%28v=...](http://msdn.microsoft.com/en- us/library/office/ee861528%28v=office.15%29.aspx)

Also, use the Object Browser in the Macro Editor to browse the list of available objects, methods, and properties. If you need more information on a particular object, search MSDN. E.g.,

[https://www.google.com/search?q=worksheet+object+site%3Amsdn...](https://www.google.com/search?q=worksheet+object+site%3Amsdn.microsoft.com)

</comment><comment><USER3> Record Macros and inspect the code to learn the object model.

<comment><AUTHOR> Thanks for the response. I'm looking for a more comprehensive way to learn it though.

</comment></comment><comment><USER4> If you know Python, you may prefer xlwings to learning VBA.

</comment><comment><USER5> Ditto. I cannot find a good source to learn VBA either.</comment>


Bret Victor tweets about the Macbook Pro touch bar - <AUTHOR> http://twitter.com/worrydream/with_replies
almost exactly eight years from concept to production
Pretty sure most people will find contextual controls like two-finger scrolling -- after a year, any computer without them will feel broken.
Pretty sure that moving a mouse pointer to an onscreen toolbar will soon feel as bizarre and anachronistic as manually dragging a scrollbar.
But hey, don't let me rain on the internet bandwagon hate parade!
This is how I picture "internet commentary": https://www.youtube.com/watch?v=O-QpfLV8dQw
https://www.youtube.com/watch?v=NdSD07U5uBs&t=34m12s https://pbs.twimg.com/media/CwOxhNwUsAAfOLK.jpg
[Presumably he worked on prototypes while he was a UI researcher at Apple a few years ago.] <comment><AUTHOR> My thought about the touch bar is that it starts to tackle a problem which began in the 1990s once desktop displays hit 1024x768 pixel resolution and has only gotten worse as displays pushed to larger and larger size.

Namely: the display was originally small and easy to mouse all the way across, meaning the menu bar and toolbars were always in close reach, and moving the mouse from the current position to the menu bar and back was fast and precise and not too disruptive to work with the pointer.

As displays grow, the menu bar, toolbars, and other on-screen non-content UI controls keep getting further away and more disruptive to reach for with the cursor. If you frequently need to precisely mouse across a 30 inch display, click a button, then precisely mouse back to where you started to carry on with a content creation/editing task, you'll start to hate performing that action and look for ways to avoid it. But often there are actions which can't be handled by keyboard shortcuts, or software with so many functions that remembering the keyboard shortcuts is a chore.

The original justification for a fixed-position menu bar at the edge of the screen was that by Fitt's Law, it would be very predictable, efficient, and cognitively easy to navigate menu options. As software gets more complex and displays get bigger, that justification starts to break down.

The touch bar is a way to restore the fixed-position nature of the original menu bar and even improve on it, moving tools off the virtual screen and into the physical space of easy-to-reach direct finger touches, letting someone drive a contextual toolbar while hardly moving their fingers off the main section of the keyboard.

I haven't seen anyone else try to seriously tackle this problem on a desktop/notebook. Certain niche software has adopted gesture interfaces or radial menus, tried to cover every possible command with keyboard shortcuts, or adopted something like the Quicksilver/etc. command-line-with-text- completion UI, but usually the usability of all of those for non-experts has been poor.

</comment><comment><AUTHOR> I haven't seen much thoughtful commentary about the touch bar yet on this forum or elsewhere (presumably partly because people haven't used it yet, no third party software has figured out how to take advantage of it yet, etc.), mostly just vitriol.

Headlines like:

"Apple just told the world it has no idea who the Mac is for" [https://news.ycombinator.com/item?id=12817332](https://news.ycombinator.com/item?id=12817332)

"New MacBook Pro Is Not a Laptop for Developers Anymore" [https://news.ycombinator.com/item?id=12816474](https://news.ycombinator.com/item?id=12816474)

"WTF Is Apple Thinking with the New MacBook Pro and Touch Bar?" [https://news.ycombinator.com/item?id=12810596](https://news.ycombinator.com/item?id=12810596)

"Apple's new touch bar is a usability disaster" [https://news.ycombinator.com/item?id=12820738](https://news.ycombinator.com/item?id=12820738)

"Apple says no fun allowed on the Touch Bar" [https://news.ycombinator.com/item?id=12840262](https://news.ycombinator.com/item?id=12840262)

"Will the Touch Bar Learn from the Apple Watch's Mistakes?" [https://news.ycombinator.com/item?id=12881097](https://news.ycombinator.com/item?id=12881097)

And comments like "I honestly hope the Touch Bar doesn't survive [...]" [https://news.ycombinator.com/item?id=12850393](https://news.ycombinator.com/item?id=12850393)

I did like this comment [https://news.ycombinator.com/item?id=12817801](https://news.ycombinator.com/item?id=12817801)

Would love to see some UI discussion about it which tried to start from a position of taking it seriously and suspending snap judgments, imagining possibilities instead of complaining about a missing physical escape key, et cetera.

<comment><USER2> I've seen some decent discussion regarding the Touch Bar, here at HN, but it is admittedly buried. Given it hasn't been in the hands of most people, it's honestly too early to do much more than cautiously speculate.</comment></comment>


State of CSS 2019 - <AUTHOR> https://2019.stateofcss.com/ <comment><USER2> I got dizzy trying to read all the info. I barely read something. Just scanned for words and numbers. Why such psycodelic style for something interesting?

</comment><comment><USER3> Haven't read too much yet; but damn, that site is pretty.</comment>


Mozilla's David Mandelin on Crankshaft - <AUTHOR> http://blog.mozilla.com/dmandelin/2010/12/08/crankshaft/ <comment><USER2> I'm really looking forward to see what Crankshaft does on Mozilla's Kraken benchmark:

<http://krakenbenchmark.mozilla.org/index.html>

Supposedly, Kraken has more long-running, sophisticated algorithms (like 'gaussian blur') that are kinder to TraceMonkey's tracing JIT than V8's traditional JIT; if V8 now has a tracing JIT (or something that works much along the same principles, it could be that Kraken becomes a two-horse race.

<comment><USER3> Chrome 9.0.587.0 dev: [http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%...](http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%7B%22v%22:%20%22kraken-1.0%22,%20%22ai- astar%22:%5B1112,1108,1107,1130,1107,1104,1104,1106,1104,1103%5D,%22audio- beat- detection%22:%5B3591,3648,3593,3602,3640,3588,3589,3589,3602,3604%5D,%22audio- dft%22:%5B2733,2772,2712,2634,2667,2731,2677,2659,2562,2592%5D,%22audio- fft%22:%5B3544,3526,3549,3539,3521,3542,3560,3526,3522,3593%5D,%22audio- oscillator%22:%5B985,993,1001,987,1028,995,996,1029,999,1030%5D,%22imaging- gaussian- blur%22:%5B4098,4117,4326,4048,4280,4135,4314,4314,4021,4282%5D,%22imaging- darkroom%22:%5B2827,2841,2858,2835,2861,2811,2801,2813,2831,2801%5D,%22imaging- desaturate%22:%5B3176,3230,3226,3108,3287,3101,3214,3361,3316,3103%5D,%22json- parse-financial%22:%5B467,461,457,457,468,459,457,476,440,472%5D,%22json- stringify- tinderbox%22:%5B471,443,440,440,464,446,439,455,438,440%5D,%22stanford-crypto- aes%22:%5B544,534,534,532,541,539,539,522,536,538%5D,%22stanford-crypto- ccm%22:%5B514,477,478,476,480,476,477,465,487,478%5D,%22stanford-crypto- pbkdf2%22:%5B1484,1509,1500,1504,1515,1490,1495,1517,1495,1507%5D,%22stanford- crypto-sha256-iterative%22:%5B501,500,503,504,503,501,503,503,500,500%5D%7D)

Chromium 10.0.605.0 (68575) with Crankshaft: [http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%...](http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%7B%22v%22:%20%22kraken-1.0%22,%20%22ai- astar%22:%5B399,411,401,401,399,401,401,403,399,415%5D,%22audio-beat- detection%22:%5B2427,2520,2464,2569,2453,2502,2518,2446,2499,2431%5D,%22audio- dft%22:%5B1508,1473,1467,1537,1514,1510,1494,1513,1506,1579%5D,%22audio- fft%22:%5B2565,2599,2684,2449,2691,2737,2684,2553,2635,2555%5D,%22audio- oscillator%22:%5B429,435,445,610,421,424,441,420,423,425%5D,%22imaging- gaussian-blur%22:%5B654,672,654,658,642,647,721,649,661,656%5D,%22imaging- darkroom%22:%5B1249,1306,1240,1242,1235,1231,1234,1232,1232,1234%5D,%22imaging- desaturate%22:%5B1098,1102,1099,1171,1104,1102,1093,1104,1108,1101%5D,%22json- parse-financial%22:%5B459,465,461,461,463,512,466,466,458,462%5D,%22json- stringify- tinderbox%22:%5B142,143,146,143,143,142,142,142,144,144%5D,%22stanford-crypto- aes%22:%5B289,286,282,290,288,287,280,289,288,286%5D,%22stanford-crypto- ccm%22:%5B281,271,287,277,277,274,277,294,280,277%5D,%22stanford-crypto- pbkdf2%22:%5B408,402,398,406,401,371,405,401,373,403%5D,%22stanford-crypto- sha256-iterative%22:%5B200,205,202,206,205,202,205,207,204,216%5D%7D)

Overall Crankshaft is 2.13x FASTER.

Ubuntu 10.04, old Core 2 Duo.

<comment><USER2> On my machine:

Chromium 10.0.604.0 (without Crankshaft): [http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%...](http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%7B%22v%22:%20%22kraken-1.0%22,%20%22ai- astar%22:%5B915,914,919,918,916,915,911,914,916,914%5D,%22audio-beat- detection%22:%5B1788,1789,1808,1797,1821,1792,1792,1790,1850,1794%5D,%22audio- dft%22:%5B2983,2934,3033,3001,2962,2977,3045,3047,3046,2905%5D,%22audio- fft%22:%5B1754,1730,1728,1767,1764,1761,1754,1755,1756,1733%5D,%22audio- oscillator%22:%5B789,789,830,778,795,797,799,796,798,785%5D,%22imaging- gaussian- blur%22:%5B3707,3726,3728,3676,3666,3724,3692,3680,3674,3705%5D,%22imaging- darkroom%22:%5B2111,2289,2113,2099,2115,2104,2103,2103,2099,2094%5D,%22imaging- desaturate%22:%5B2137,2177,2126,2123,2124,2127,2125,2131,2158,2126%5D,%22json- parse-financial%22:%5B290,287,289,289,291,286,289,290,288,289%5D,%22json- stringify- tinderbox%22:%5B263,266,264,263,266,266,265,266,266,263%5D,%22stanford-crypto- aes%22:%5B178,175,176,177,178,177,177,178,178,175%5D,%22stanford-crypto- ccm%22:%5B143,143,143,143,142,142,142,142,143,141%5D,%22stanford-crypto- pbkdf2%22:%5B354,347,356,338,333,331,331,344,331,332%5D,%22stanford-crypto- sha256-iterative%22:%5B143,143,144,142,143,143,142,145,142,142%5D%7D)

Firefox/4.0b8pre from 20101208: [http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%...](http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%7B%22v%22:%20%22kraken-1.0%22,%20%22ai- astar%22:%5B1387,1388,1356,1416,1426,1387,1435,1392,1420,1392%5D,%22audio- beat-detection%22:%5B981,785,866,875,846,850,878,871,875,846%5D,%22audio- dft%22:%5B773,865,740,729,725,722,734,726,714,720%5D,%22audio- fft%22:%5B691,674,671,669,686,667,668,665,669,675%5D,%22audio- oscillator%22:%5B620,620,618,621,625,617,620,620,621,633%5D,%22imaging- gaussian-blur%22:%5B809,805,7072,812,805,804,807,807,805,808%5D,%22imaging- darkroom%22:%5B325,323,323,327,326,324,325,325,326,326%5D,%22imaging- desaturate%22:%5B878,868,857,858,868,865,870,869,874,879%5D,%22json-parse- financial%22:%5B181,176,177,175,177,174,176,179,186,179%5D,%22json-stringify- tinderbox%22:%5B92,93,92,93,91,91,92,92,92,91%5D,%22stanford-crypto- aes%22:%5B364,369,368,363,363,367,370,366,367,367%5D,%22stanford-crypto- ccm%22:%5B228,228,227,228,226,227,229,226,228,226%5D,%22stanford-crypto- pbkdf2%22:%5B503,473,477,477,480,475,475,481,486,481%5D,%22stanford-crypto- sha256-iterative%22:%5B203,203,203,203,203,201,203,201,203,203%5D%7D)

Overall, Firefox is 2.08x faster.

Ubuntu 10.10 x86_64, on a Core 2 Duo 2.4GHz

Comparing these with your results, it sounds like the JS performance war just got interesting again.

<comment><USER3> Huh, that's strange Firefox nightly here is slower than Crankshaft:

[http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%...](http://krakenbenchmark.mozilla.org/kraken-1.0/results.html?%7B%22v%22:%20%22kraken-1.0%22,%20%22ai- astar%22:%5B2070,2281,2123,2528,2183,2254,2335,2437,2256,2314%5D,%22audio- beat- detection%22:%5B2418,2411,2402,2397,2398,2379,2423,2398,4003,2444%5D,%22audio- dft%22:%5B1000,990,1000,1025,1006,1023,1090,1010,1056,1035%5D,%22audio- fft%22:%5B1891,1848,1821,1853,1827,1820,1853,1820,1900,1847%5D,%22audio- oscillator%22:%5B1027,1044,1033,1053,1052,1050,1028,1046,1063,1030%5D,%22imaging- gaussian- blur%22:%5B1242,1265,1271,1268,1268,1244,1266,1246,1284,1300%5D,%22imaging- darkroom%22:%5B622,631,620,635,631,619,621,636,666,629%5D,%22imaging- desaturate%22:%5B1276,1285,1284,1311,1324,1311,1267,1277,1274,1318%5D,%22json- parse-financial%22:%5B403,401,409,415,409,410,402,409,415,402%5D,%22json- stringify- tinderbox%22:%5B146,146,145,145,147,147,147,147,156,147%5D,%22stanford-crypto- aes%22:%5B464,467,448,460,460,451,458,529,471,472%5D,%22stanford-crypto- ccm%22:%5B759,752,758,758,743,749,752,371,354,341%5D,%22stanford-crypto- pbkdf2%22:%5B679,686,691,686,688,688,679,1052,730,679%5D,%22stanford-crypto- sha256-iterative%22:%5B311,308,311,309,304,311,303,324,313,308%5D%7D)

<comment><USER2> I did mention my Chrome test was without Crankshaft - I'm using x86_64, and Crankshaft isn't available for that platform yet.

Doing the comparison thing, apparently TraceMonkey is ~1.2x slower than Crankshaft on your machine. Things are hotting up indeed!

<comment><USER4> Chrome with Crankshaft (which is currently only for 32-bit architecture) is faster on Kraken than Firefox nightly.

<http://www.arewefastyet.com/awfy2.php?machine=9>

</comment></comment></comment></comment></comment></comment><comment><USER5> You gotta love competition between competent and confident engineers. Instead of criticizing and denigrating the competition's accomplishments Mandelin congratulates and analyzes the V8 team's successes.

<comment><USER6> It doesn't always work out that way. Check out Linus Torvalds' discussion of Subversion or Dan Bernstein's discussion of Postfix, for example. Even though Linus and Dan are competent and confident, they were very harshly critical of their "competition".

<comment><USER5> Indeed, which is why I was highlighting an example of "doing it right" (aka acting like mature professionals). Even when business issues don't get in the way there's still plenty of room for personal and emotional issues to bring down the level of discourse.</comment></comment></comment>


The software industry is due for an industrial revolution - <AUTHOR> http://www.scaletheplanet.com/post/the-industrial-revolution-part-1

<comment><USER2> Software already went through the industrial revolution. To take your analogy, the car designers (the ones who work to build the prototype) are all craftsmen. Once the car is designed and we make copies of it, that is the industrial process. In software, the industrial process is trivial.

The car designers who build the first prototype, tweak it, make it actually work would call themselves craftsmen. They might use parts of other car models (same as we use libraries), they might duct tape something (same as we hack things), but the fact remains they are craftsmen.

I would also like to point out to one of the better arguments for this from Dijkstra - [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html) \- you actually have to think across many abstractions and as a result, writing software remains a craftsmanship.

<comment><AUTHOR> I disagree that in software process the manufacturing is trivial. Software is so often designed as more general systems, that need to be configured and installed and integrated, etc. Those steps aren't part of the design process anymore, they're specific to every sale, to every client. They are what I would consider a manufacturing step.

I do agree that car designers could call themselves craftsmen, their jobs are closest to what craftsmen used to be and do. But they don't anymore, they have evolved into new processes and new systems. That is the evolution I think software is due for.

</comment></comment><comment><USER3> To add to NhanH's earlier point [1]: I think it's an overall interesting thought, but the whole argument hinges on an unfortunate association fallacy [2] itself premised on a leaky and questionable analogy.

Besides, as you well know, there might well be very good complexity- theoretical reasons [3] for drawing a distinction between the easily scriptable, repeatable, limited-state steps required to implement/carry on a solution for a given problem; and the non-trivial steps it took to _come up_ with that solution in the first place. It seems to me the great successes in automation during the industrial revolutions were mostly about parallelizing the former, not the latter; while most day-to-day computer programming predominantly involves the latter, not the former. One way or the other, it's far from evident the analogy is even applicable in this case.

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

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

[3] [http://www.claymath.org/millenium-problems/p-vs-np- problem](http://www.claymath.org/millenium-problems/p-vs-np-problem)

</comment><comment><USER4> The "car manufacturing process" doesn't even happen anymore in the software industry. A few years ago the manufacturing step was to press the installation CDs. The closest analogy today is to deploy the software for distribution.

Instead software development is the design process of a new car, coming up with new ideas that make the new car model better/more efficient/cheaper then the past model, testing and tweaking all these improvements, making sure all the components and little pieces work well together.

The industrial revolution didn't really improve this step, it only made the manufacturing step at the end of the whole process more efficient.

I consider industrial designers and software developers still as craftsmen in the best sense of the word.

</comment><comment><USER5> It's a big industry out there. There are those who make bespoke products, and those that take a number of pre-built more general purpose libraries and just stitch them together, and everything in between.

Stitching together libraries is easy and generally quick to produce an initial product, but can become difficult to maintain/extend and is wasteful on both run-time and development resources. This method is pretty forgiving to those that don't know exactly what they are doing, and you don't have to have any experts on your team to produce a "working" product. You will accrue lots of technical debt this way (but in a lot of projects is doesn't matter much).

Bespoke products are difficult to architect and build (properly), take a long time to develop, but are performant, malleable and predictable when done right. If you do it wrong (or your architect is hit by a bus), you have a huge mess on your hands.

Most of my experience has been about two thirds bespoke, one third stitching. In my experience, finding the right ratio depends on the amount of scaling the product needs to do, how much you're willing to spend on talent, how unusual your requirements are, and how screwed you're comfortable being if things go wrong.

I have never seen an instance where a well built bespoke product did not have a competitive advantage over a stitched one. Generally a large competitive advantage. I have also seen a number of poorly built bespoke products crash and burn; so take that as you will.

</comment><comment><USER6> I find myself quite convinced of this today. I believe that, like the industrial revolution, there needs to be a reduction of time-consuming effort to make it happen.

My thoughts lead to thinking that machine-aided development will be a major step forward. Part of this I believe is discoverability in what we make. Perhaps another major step would be to reduce the time to express the intent in code.

<comment><AUTHOR> Reduction of time-consuming effort is exactly one of the points I'm going for. It's necessary for a proper software future.

I considered machine-aided development, and it's definitely a very good potential future. In the context of the post, I see machine-aided or machine- driven development more akin to the 3D printing revolution going on now, where you don't need intricate knowledge of the component parts at all. I'll mention this in part 2 (starting to sound like I should add a part 3 too :p)

</comment></comment><comment><USER7> > Like craftsmen in the past, every line is bespoke, every function something > toiled over. [...] None of them worried about how to build the screws that > hold it together.

Many years ago I wrote a video game in x86 assembly. (It was a shitty Snake game, but still) That code was burping out pixels direct to the VGA framebuffer. That code was pretty manual, and every assembly instruction that ran was designed and typed in by me.

Contrast that with modern web development. You're getting TONS of functionality for free. Did you toil over every line of the node.js code? Did you worry about how the interpreter stored your data in a pretty optimal data structure, gave you the illusion of nearly-infinite memory by garbage collection, or automatically cached a bunch of stuff that you never had to think about? And let's not talk about the encryption library, or the networking code, or the OS, or etc, etc.

In other words, I _don 't_ think modern web developers worry about the screws that hold it together, but man, they are still still there.

<comment><USER8> But you probably didn't write the assembler in machine opcodes before you wrote the snake game. Now I'll grant you that writing in assembly is not a fly-by-night skill, but at some level everything relies on abstractions.

Any common programming language comes with some set of tools, in the form of libraries and built-in keywords. The only difference between modern web libraries and language libraries is that modern libraries evolve and change at a much faster rate.

While a web developer may not be looking as closely to what is running on the metal, they are every bit as focused on being a craftsman at their level of abstraction. And they are able to take advantage of the fact that the tools they use are constantly evolving and providing ways to be more expressive.

</comment></comment><comment><USER9> Proposals to industrialize software development have a long history, for example at the NATO conferences in the 1960s which coined the term "software engineering":

[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)

and in the "software factories" of the 1970s and 80s:

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

</comment><comment><AUTHOR> Part 2 is now live! You can read it at [http://www.scaletheplanet.com/post/the-industrial- revolution...](http://www.scaletheplanet.com/post/the-industrial-revolution- part-2) and comment on HN at [https://news.ycombinator.com/item?id=7758174](https://news.ycombinator.com/item?id=7758174)

</comment><comment><AUTHOR> Hi all,

For what it's worth: this is my very first blog post, and it's a bit of an unusual one. I'd love to hear any feedback, good or bad.

<comment><USER10> I disagree with most of the points you made (mainly because I think the analogy is very weak). But I'm waiting for your next part before commenting more. For a few short notes: \- Software, nowadays, are both services and products. And we are already providing the services to a much larger numbers of customers than developers.

\- It could be said that "build" would be a good description too. But "build" as in "we build a company", rather than "we build a wall". There are big multinational corps as well as mom & pop shop, and there are big distributed programs as well as simple CRUD apps. We'd have the industrial revolution in software when we have one in starting a business (which some may argue is happening too, actually).

\- And finally, "engineer" would be an apt description too, we're merely engineering the program, with all the declarative programming and what not :-). The compilers & co are our factories. Luckily in our case, no sweatshop is involved in manufacturing.

<comment><AUTHOR> Thanks for the input! For the purpose of this post, I didn't make the distinction between services and products, since at their most basic level, they are the same. The difference is in business model, not implementation or process.

'build' a in company is a very interesting avenue of thought. It might imply different ways to work on software. Food for thought :)

Compilers as factories are something I considered, but for software they are a part of the creation process, not the manufacturing process.</comment></comment></comment>


An Exciting Twist on Fundraising - <AUTHOR> https://fundcrazr.com/how-it-works

<comment><AUTHOR> Looking for thoughts on: Is our mission clear? Do you understand our concept? Would you participate as a fundraising manager and/or a supporter? Thank you!</comment>


Ask HN: do you have a process for employees to share new ideas - <AUTHOR>

How do employees share ideas in your company? Is there a process in place for employees to voice their thoughts? How do right ideas reach the right people? <comment><USER2> I can give you an anti-pattern: for years IBM had an ideas program (I think called "Think Up!" but not certain). Employees could submit their idea online and it would be evaluated by "someone".

I turned out to be one of those someones. Any employee idea that mentioned "internet" or "web" in the 1990s got forwarded to me to "resolve". The problem I quickly ran into was that there was no way for me to say "Hey, this is a good idea, I have no means/method/funding to implement it myself". I could only accept ideas (which I then had to document how to implement and implement) or reject them. After getting repeatedly reprimanded for not acting on employee ideas I started rejecting them en masse. All of them, regardless of the value. If it ended up on my desk, I rejected it.

And I eventually won an award for being such a valuable "contributor" to the IBM Ideas program.

So, if you implement some sort of ideas program, make sure that there's some sort of process in place to move the idea from "hey, that's a great idea" to implementing it. Depending on the size of your organization, it's likely that you will get some great ideas from people who have absolutely no idea how to implement the idea. Make sure there's a way to catch these and figure out how to implement them.

<comment><USER3> "make sure that there's some sort of process in place to move the idea from "hey, that's a great idea" to implementing it. "

I agree , however value lies in being able to identify other people who have similar ideas within the organization and be able to filter them out. A lot of people don't speak up in structured settings however having an anonymous forum where everyone in an organization irrespective of rank can post ideas and their bosses (also anonymous can unanimously up-vote or down-vote ) creates good synergies. The idea may not necessarily be implemented .</comment></comment>


Facebook's physical security that protects Mark Zuckerberg, employees - <AUTHOR> https://www.businessinsider.com/inside-facebook-physical-security-protect-mark-zuckerberg-employees-2019-2 <comment><AUTHOR> Outline link: [https://outline.com/9Jr8AX](https://outline.com/9Jr8AX)</comment>


Best of the best: Who makes the most accurate decisions in expert groups? - <AUTHOR> https://www.sciencedaily.com/releases/2019/11/191120141828.htm <comment><AUTHOR> Assumption/Hypothesis: "Those individuals in a group of experts who make decisions that are most similar to the decisions of others also make the best decisions."

"It has been shown time and again that experts who are good in their field are good in a similar way, whereas poor performers are bad in very different ways. Working on the basis of this observation, we developed this new method and tested it in various areas," says Ralf Kurvers, lead author and researcher at the Center for Adaptive Rationality at the Max Planck Institute for Human Development.

<comment><AUTHOR> ...which reminds me of the opening line to Anna Karenina: "Happy families are all alike; every unhappy family is unhappy in its own way" (Tolstoy)</comment></comment>


How to implement Perl 6 in 2010 - <AUTHOR> http://pugs.blogs.com/pugs/2010/04/how-to-implement-perl-6-in-10.html

<comment><USER2> Hi. Thanks for the link!

I'm sure you noticed, the original title was "How to implement Perl 6 in '10", where '10 was meant to refer to the year 2010...

Though I guess "10 minutes" is a valid, if unexpected, interpretation of "'10". Enjoy! :-)

<comment><USER3> Not sure what original you are referring to, but the one linked to is in fact titled "How to implement Perl 6 in ten years".

Anyway, both of them are such a mix of incoherent rambling and impenetrable project internals that I feel cheated for the time it took to skim over them...

<comment><USER2> Aww. :-)

I was referring to the "<h3>...</h3>" tag in the linked article at [http://pugs.blogs.com/pugs/2010/04/how-to-implement- perl-6-i...](http://pugs.blogs.com/pugs/2010/04/how-to-implement- perl-6-in-10.html) as the title of the blog entry.

I'm truly sorry that you feel cheated. Indeed the article contains nothing about implementing anything in 10 minutes, or anything of that sort. My apologies... :-)

</comment></comment></comment><comment><USER4> Coming from the python community, I have to wonder how much exchanges like this have contributed to the delay: <http://perlmonks.org/?node_id=835742>

<comment><USER2> Probably 80%+, in the early ages.

Troll alchemy - I mean troll hugging - is a subtle art, and it took us many years to get the main development channels into reasonable civility.

For example, <http://irclog.perlgeek.de/perl6/today> has been quite gentle for the past 5 years or so.

I guess when one builds a language (Perl) modeled after a natural language (English), one attracts quite a diverse crowd, as basic literacy was the only requirement...

Compare that to Haskell, modeled after mathematics, which attracts folks who thinks in higher-order logic... And as you could imagine, exchanges like the one you cited was quite difficult to express in equations.

On the other hand, civilized exchanges like we see in ycombinator.com is quite difficult to express in equations, too... :-)

<comment><USER4> Heh, I remember reading your troll-hugging post when it came out.</comment></comment></comment>


This is a scale model of the solar system like you've never seen before - <AUTHOR> Http://phys.org/news/2015-09-scale-solar-youve.html <comment><USER2> Ambitious and rather impressive.</comment>


PostgreSQL 9.3 Beta 2 now available - <AUTHOR> http://www.postgresql.org/about/news/1471/

<comment><AUTHOR> Good overview of all the changes can also be found in the wiki on postgresql.org:

[http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9...](http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3)</comment>


Deep Learning and Serverless Computing - <AUTHOR> http://blog.johnemmons.com/post/awslambdaface/ <comment><USER2> If the author sees this: I'd be interested in a more generalized example of using lambda instead of ec2. What kind of savings do you generally get, and for what level of effort?

<comment><AUTHOR> The cost savings are not the main advantage of AWS Lambda compared to EC2 (AWS recently announced EC2 will bill on a per second basis and a minimum of 1 minute). Instead, I'd argue that the programming interface, managed operations, and scalability are what makes it a better tool for these types of tasks! I'm looking into running other more general computations on Lambda right now as part of my PhD! (stay tuned for more soon). Until then, check out ExCamera ([https://www.usenix.org/conference/nsdi17/technical- sessions/...](https://www.usenix.org/conference/nsdi17/technical- sessions/presentation/fouladi)) and PyWren ([https://github.com/pywren/pywren](https://github.com/pywren/pywren)).

<comment><USER2> Awesome, thanks for the insight! Good luck on your PhD.

</comment></comment></comment><comment><USER3> Impressive job for a six hour video!

> In total, the face recognition and montage creation took less than 5 minutes > and cost about $8!</comment>


Show HN: A support network for your weekend side-project - <AUTHOR> Hey HN --
A few weeks ago I launched Pioneer (https://pioneer.app).
Pioneer is an experiment to try and find & help creative people around the world working on interesting projects. A project could be anything -- open source work, research in physics or biology, or creating art. Unlike other grant programs, the way we find people is through crowdsourcing.
Applicants vote on each other (like HN / Reddit) and the best projects float to the top. We have industry experts (Patrick Collison, Tyler Cowen, Stephen Wolfram, etc) act as "mods" to sharpen the quality of the leaderboard.
The top-scoring applicants become Pioneers. They get $5,000, a ticket to Silicon Valley, mentorship from experts and -- most importantly -- a community that will hopefully accelerate and motivate them.
Applications close Sunday night PDT. If you have a weekend-side project that you can't stop thinking about -- Pioneer is exactly for you!
I'm trying to make an engine for converting shower-thoughts into real world stuff. Other than money, what do you think would be helpful to provide?
Pioneer is at https://pioneer.app.
P.S. I also work at YC. This is an unrelated effort, primarily aimed at things that don't fit the bill of a "company". Apply to Startup School for that! <comment><USER2> You may want to disclose you are a partner at YC, as this sounds like a scam/spam otherwise.

EDIT: Was added. Thanks!

</comment><comment><USER3> It doesn't say anywhere on Linkedin that you work at YC.

<comment><USER4> Disclosed in this post from last year. [https://news.ycombinator.com/item?id=14851806](https://news.ycombinator.com/item?id=14851806) Would be better if that was on his public profile page, but I believe it's legit.</comment></comment>


Doom3 Gangnam Style in WebGL - <AUTHOR> http://apps.playcanvas.com/will/doom3/gangnamstyle <comment><USER3> Not only a great idea but also free load testing for the playcanvas.com guys. Their appserver appears to have melted: the CTO's hands are currently a blur on his keyboard!

<comment><USER4> We've spun up a new, higher capacity server. Enjoy!!! :)

<comment><USER5> Impressive animation - where did you the mocap data from, or all animated by hand?

<comment><USER6> Mixamo.com has a good free Gangnam mo-cap you can apply to any uploaded model. It's actually a pretty interesting service, you can just upload a 3D model and their software will auto-rig it for you, and you can pick any animation to apply to the rig (This dance is one of them). Seems it'd be a great service for indie game devs -- not one myself, but looks fascinating.

Clickable: <http://www.mixamo.com/editor/new/1643>

<comment><USER7> Second the vote for Mixamo... awesome service, makes creating animation loops really fun and easy.

We're reworking the animation system in Three.js, so soon you'll be able to make your animations in Mixamo, and deliver them on the web. You can do it yourself with Three.js, or with our help using <http://studio.verold.com> (though, if you're going to do another Gangnam style, please use a better remix - like [https://soundcloud.com/stirling-inch/pretty-gangnam-fly- stir...](https://soundcloud.com/stirling-inch/pretty-gangnam-fly-stirling))

<comment><USER5> Thanks guys... Mixamo looks pretty good, bookmarked for future use.

</comment></comment></comment></comment></comment></comment><comment><USER8> And suddenly the true purpose of WebGL became clear..

This is pretty awesome, would be better if it was in sync with the music though? It gets out after a bit.

<comment><USER9> You may be on to something. In the future more artists may choose to make music videos like this or Ro.Me if it's cost-effective enough. Artists have always embedded CGI stuff into their music videos, anyway.

</comment></comment><comment><USER10> Ah, I came to make a comment about needing 'in WebGL' adding to the title, and I see it is already there!

Little comment: If like me you try to click on anything in chrome, you will get a message about the page wanting to disable your mouse cursor. I thought that sounded dodgy, but agree. It just means let the app take control of the cursor, so you can use it for changing viewpoint.

<comment><USER11> Additionally you can use WASD.

<comment><USER12> Bug report for the author:

This demo tries to capture your mouse cursor, so that you can use the mouse to look around the world. But it's malfunctioning (on Chrome, Win 7 x64).

Synopsis: the first time it loaded, I clicked on the canvas. That popped up a banner at the top of my browser window which said something like "so-and-so website would like to take over your mouse cursor. Allow or deny?" So I tried to click on the allow button, but wound up accidentally clicking a bookmark, which of course navigated me away. So I hit the back button, which reloaded the demo. But now it's not trying to capture my mouse anymore, regardless of what I do.

Just writing that up on the off-chance it's helpful to the author. The itself bug doesn't matter much, though.

Author: fantastic work, fantastic execution.

<comment><USER13> could be your chrome settings... I allowed mouse capture permanently, and whenever I hit escape and click the canvas again, it retakes my cursor.

</comment></comment></comment></comment><comment><USER14> I was ready to declare the whole Gangnam Style thing dead-and-buried, but this still made me chuckle. Very nice work!

</comment><comment><USER15> Very interesting, and very well done.

I also cannot adequately express my thanks for putting a mute button on there.

<comment><USER4> It was more for my benefit while I was developing it. ;)

</comment></comment><comment><USER16> Works on Android for me which is even more impressive.

<comment><USER17> What browser are you using? It doesn't work on Chrome on my Nexus 4.

</comment></comment><comment><USER18> How do you shoot? I want to blow these guys up. Hysterical.

</comment><comment><USER19> You realize that you just _have_ to provide a chain gun now, right?

</comment><comment><USER20> Very nice! (Is there a way to rotate rather than just strafe-move?)

Now if there were a game that reproduced the scenes and people (including Psy) in the actual video -- and let you _blow them all to pieces_ , stopping the music each time a scene is cleared -- that might get another billion plays!

<comment><USER21> > (Is there a way to rotate rather than just strafe-move?)

In chrome i had to explicitly allow canvas to take control of the mouse, then you have full mouse-look.

edit: more info below

</comment></comment><comment><USER22> Very creative and entertaining. I can't stop watching the middle monster.

Something I didn't realize at first was the ability to use the movement keys - seeing different angles is pretty cool. As another comment mentioned, the sync could definitely be tighter, but otherwise well done.

</comment><comment><USER23> Last august there was this other WebGL animation with Doom 3 characters : [http://alteredqualia.com/three/examples/webgl_animation_skin...](http://alteredqualia.com/three/examples/webgl_animation_skinning_doom3.html)

</comment><comment><USER24> That is just wrong on every level. Utterly brilliant but wrong.

</comment><comment><USER25> This is just great. Enjoyed it - posted it on fb and ready to watch it again - then the server is apparently overloading. Wonder what the traffic is like.

<comment><USER26> Here is the CPU: [https://twitter.com/daredevildave/status/289029688943321089/...](https://twitter.com/daredevildave/status/289029688943321089/photo/1)

Turns out a m1.small is much better than an t1.micro :-)

</comment></comment><comment><USER27> that's a silly, yet creative, take on using WebGL - <USER2>

</comment><comment><USER28> This is neat! Had to show it to a couple of other people around me, sucks to explain who the characters are though to non-gamers :).

</comment><comment><USER29> Well dang, crashed my firefox after loading about 1/3 :-\

Chrome is fine, but firefox is where I keep a bazillion pages open

</comment><comment><USER30> Warning: May freeze your browser.

</comment><comment><USER31> Shadows are kinda blocky. And some weapons would be nice.

</comment><comment><USER32> Ah, technology.

</comment><comment><USER33> That's amazing.

</comment><comment><USER34> gangnam style overdose</comment>