Text Processing in the Shell - <AUTHOR> https://blog.balthazar-rouberol.com/text-processing-in-the-shell <comment><USER2> Sometimes I find it strange - in both good and bad way - that we are, in 2020, learning tools and languages designed and build in the 80s, with models and constraints of the time, with 40 years of layers of backwards compatibility, and actually going sometimes back to the 70s

I am still learning tools designed around the constraints of teleprinters

Sure, it's the same on Windows side (and macOS side with their classic OS compatibility layers still present, like all the HFS stuff). Not bashing bash here.

Surely our computers have very different models of operation than PDP-11, yet we are sometimes pretending it doesn't

<comment><USER3> The English language is several hundreds of years old, and the ADN is several hundreds of millions years old. _Everything_ we are based on is legacy; I do not see why it should be different in computing.

<comment><USER4> In fairness to the OP, there's a lot of cruft in the way terminal work that really isn't necessary any more but need to be there because of backwards compatibility. Such as

\- formatting being in-lined via ANSI escape sequences,

\- and there's a massive disparity between what escape sequences terminal emulators support,

\- control codes being part of the same character set as printable characters,

\- changing the behaviour of the TTY requires either terminal emulator support or OS support depending on the behaviour you require because the TTYs are defined partially via kernel drivers (which requires syscalls to alter) and partially by escape sequences,

\- and in the case of kernel behaviour, those syscalls vary from one OS to another. Some OS's don't even support from TTY behaviours that other OSs do so you can't even guarantee that logic is cross platform and that you just wrap around specific differences in syscalls,

\- resizing terminals UIs can be a nightmare -- often requiring capturing RPC signals and redrawing -- because there's no native layout system for drawing to the TTY,

This isn't meant as a criticism though because there's a lot the general design of terminals gets right (eg the kernel driver for TTY allows us to kill processes over remote shells like SSH and mosh). But I think terminals are one of those things that work "good enough" that most of the ugliness is hidden from everyday users. However if we were to redesign UNIX terminals from the ground up there is a lot of things most engineers would like to change and of lot of places where things could be improved. Like having an out-of-band channel for sending meta-data describing the pipeline but shouldn't be mixed in with the byte stream.

<comment><USER5> ... and pretty much all of those were addressed, outwith Unix, by the evolution of the 1960s terminal I/O model into the console I/O model during the 1980s.

You even forgot to mention one of the things that was addressed: input. Terminal I/O input, done properly, requires a full ECMA-48 decoder state machine, with bodges to accommodate non-conformant warts from the Linux KVT, SCO Console, and RXVT. This is all too often _not_ done properly, because people do not realize that there is ECMA-48 in _both_ directions; and is a mess, just looking at function keys alone and not even accounting for keypad application/normal modes and a mouse/locator. Console I/O evolved into uniform input event records for HIDs that did not require state machines to decode.

Note that the lack of a layout system is only applicable to character-mode terminals. Block-mode terminals are a quite different kettle of fish.

<comment><USER4> > _... and pretty much all of those were addressed, [outside?] Unix, by the > evolution of the 1960s terminal I /O model into the console I/O model during > the 1980s._

> _Note that the lack of a layout system is only applicable to character-mode > terminals. Block-mode terminals are a quite different kettle of fish._

Indeed but the point isn't "are these solvable problems?" but rather "why are we still using archaic tech?"

Designing a solution to those problems is actually the easy part. It is shifting the ecosystem away from TTYs that's hard.

> _You even forgot to mention_

It wasn't intended as an exhaustive list :) There's plenty more issues I hadn't raised.

\---

In an ideal world I'd love to see UNIX terminals reinvented. The reality is things are "good enough" for most people that they simply don't notice most of the issues and migrating to the next evolution of UNIX terminals would mean a break in backwards compatibility which will be more disruptive (initially in a negative way) than making do with the warts we currently have.

<comment><USER6> Check out Microsoft's new Windows terminal ([https://www.hanselman.com/blog/ItsTimeForYouToInstallWindows...](https://www.hanselman.com/blog/ItsTimeForYouToInstallWindowsTerminal.aspx) ) It may be the most modern, capable, and yet compatible terminal I've come across, and works well regardless of the environment you want to run it in/with. (To be fair, a modern Windows terminal is a good 20 years overdue, but MS deserves credit for finally getting it right...)

<comment><USER4> If it's backwards compatible with TTYs then it probably hasn't solved any of the problems I mentioned and there's already a plethora of nice terminal emulators out there (which is why I say most of the "ugliness" is hidden from everyday users).

It should also be noted that Windows makes a few mistakes when it comes to terminal design too:

\- For starters cmd.exe is both a shell and terminal emulator and it's impossible to separate the two.

\- To compound things, many common commands like dir, rm, etc are shell builtins (this will be a throwback to DOS). So you cannot even use an alternative shell on Windows without having to either invoke cmd.exe or rewrite existing utilities.

\- And if that wasn't bad enough, cmd.exe builtins do not read from STDIN. They instead use DOS syscalls to read keyboard input.

\- As you've probably guessed, cmd.exe isn't the only culprit which does this. Any "Windows" command line program designed for or which uses DOS APIs will not follow the standard streams idiom. Any command line software written for NT, however will. So you end up having to write all sorts of really nasty hacks just to get the command line working on Windows (far _far_ nastier than any of the hacks that happen on UNIX/Linux).

\- Then you have Powershell, which is an entirely separate command line in its own right and largely - though not completely - incompatible with cmd.exe.

\- And WSL, which is also incompatible with cmd.exe _and_ Powershell.

At least on UNIX/Linux, you have one terminal methodology. From there you can use whichever terminal emulator you want, whichever shell you want, whichever programming language to write CLI tools and/or whichever CLI tools you want to download. Where as on Windows you have 4 competing standards which don't cooperate well.

<comment><USER5> It behooves one not to make egregious mistakes when talking about the mistakes supposedly made by Windows. cmd.exe is not a terminal emulator at all, and does not make DOS system calls (it being a Win32 program) at all.

* [http://jdebp.uk./FGA/a-command-interpreter-is-not-a-console....](http://jdebp.uk./FGA/a-command-interpreter-is-not-a-console.html)

And the fact that CMD and PowerShell provide different interpreted languages is no different to the Korn shell, tclsh, and Perl providing different languages.

<comment><USER4> > _It behooves one not to make egregious mistakes when talking about the > mistakes_

Admittedly it's been a little while since I last played around with custom shells and terminals on Windows and I had also rushed my post so you're right that some details were wrong but you're just as far off with your corrections as the points you were criticising so you're really not in a position to be making platitudes about egregious mistakes.

I didn't say cmd.exe was a terminal emulator, I said it was multiple layers _including_ the terminal emulator but not exclusively the terminal. Ok, techically it's conhost.exe that provide the terminal emulation, I'd lazilly lumped that together with cmd.exe because cmd.exe depends on conhost.exe when not run headless. The former requires the latter so you can't just drop cmd.exe into another terminal emulator and run it (other people have tried and there's extensive blog posts about the hacks they've had to do to get it to work, like running conhost.exe off screen).

If you want to be 100% technically accurate then cmd.exe is actually not like any of those things we've described. It's certainly not equivalent to Korn or other language REPLs as you stated. In fact the "language" part of cmd.exe is barely a macro language (again, due to it's DOS heritage). Plus shells orchestrate with byte streams where as NT's streams work very differently and cmd.exe doesn't even behave correctly when used as a CLI tool (which I'll get into below).

You're right that cmd.exe itself doesn't make DOS syscalls, as said aboveI was rushing my post which caused me to conflating two points. What I really meant to say was:

1\. cmd.exe builtins read from the NT console API's stdin. Which means you cannot fork out to cmd.exe as a CLI command because any prompts ("Are you sure you wish to delete" type things) just whiz straight past without pausing for input. This was highly annoying when I was developing my alternative Windows shell and wanted to make use of rm, copy, etc rather than having to write those commands all over again.

2\. Windows, and cmd.exe by extension, supports running other console applications which don't use NT's console streams because they favour some of the other hacks used in the DOS days. This means those applications also don't work with alternative shells let alone alternative terminal emulators.

Also I think it's disingenuous citing your own blog post as a source. I could link you to the Github repository where I've had to put in numerous workarounds for the shell I've written to work with Windows. But instead I'll link to something a little more recognised:

[https://devblogs.microsoft.com/commandline/windows- command-l...](https://devblogs.microsoft.com/commandline/windows-command-line- inside-the-windows-console/)

(I did have a hunt around for the blog posts from other developers building console solutions for Windows and the similar problems they've ran into but since it was around 5 years ago when I gave up first party Windows support, those blogs are now lost in the mists of the ether).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> A little suggestion for the authors, they mentioned xargs, I think [GNU parallel]([https://www.gnu.org/software/parallel/](https://www.gnu.org/software/parallel/)) might work a mention too, since it is a kind of modern successor that can use many computers to run tasks.

<comment><USER8> This you have to install, xargs is everywhere. Also with the -P flag you can parallelize the most common cases.

<comment><USER9> Personally I like parallel better because of the `--bar` option and `{}`, `{.}`, `{/}` and `{/.}`. And I usually just use it with `-P 1` anyway.

</comment></comment></comment><comment><USER10> OP you should mention perl one-liners in upcoming chapters [https://catonmat.net/introduction-to-perl-one- liners](https://catonmat.net/introduction-to-perl-one-liners)

<comment><USER11> Agreed. Perl makes it easy to do complex text processing and can replace many individual command line text processing tools.

Recent versions of Perl also support UTF-8 so they can support text processing in different natural languages or internationalization needs. See [https://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8](https://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8)

<comment><USER12> > Recent versions of Perl

Make sure it's recent enough and released after 2002!

<comment><USER11> I was thinking of Perl versions 5.14 (released in 2011) and later since that release fixed several Unicode-related bugs.

There have been other improvements and fixes in the versions up to 5.30, so the Unicode support now is pretty transparent.

Many of the classic command line text processing tools are not Unicode aware.

</comment></comment></comment></comment><comment><USER13> I've always viewed `awk '!a[$0]++'` as superior to `sort | uniq` because it preserves order and does not have to sort the data first before deduplicating. But `sort | uniq` is much easier to remember.

<comment><USER14> Or just `sort -u` (if you are using GNU sort, not sure about other implementations)

Another difference is that sort is optimized to handle large files [0]

[0] [https://unix.stackexchange.com/questions/279096/scalability-...](https://unix.stackexchange.com/questions/279096/scalability- of-sort-u-for-gigantic-files)

</comment></comment><comment><USER15> This is cool for English text. But once you get Unicode with various ways to represent é, whew lad. This get shitty quickly in the shell.

<comment><USER12> English _is_ Unicode. Pretending otherwise would be quite naïve. [https://www.azabani.com/pages/gbu/#slide4](https://www.azabani.com/pages/gbu/#slide4)

<comment><USER15> You claim is not clear.

"Unicode with various ways to represent é" is a shit show to parse using shell tools. e.g. Try scraping Spanish language Twitter feeds. When I have done this kind of work, I made a tool to canonicalize glyphs and had to put it between every step of a pipeline.

</comment></comment></comment><comment><USER9> Lately I've started to use Perl instead of sed for replacing text. Its regex support is much better IMO:

      cat a.txt | perl -pe 's/banana-(\d)/papaya-$1/g'

Or in-place:

      perl -i -pe 's/banana-(\d)/papaya-$1/g' a.txt

</comment><comment><USER16> I'll preface my question by saying that I'm not a dev.

Why do this kind of work in the shell? Isn't it better to do this in a programming language that can run on all operating systems? What are Windows users supposed to do?

<comment><USER17> As a dev: I don't know. It's a well written article and this stuff can be handy in a pinch, but I've yet to see many real world scenarios where a complicated shell script is a good idea. Most of these examples, I would probably rather write a five line python script to ingest the data into sqlite and then use actual queries.

<comment><USER18> The use case is to quickly handle ad hoc scenarios.

If you need to quickly extract something from a csv, you could break out python, or import it into a database, but using cut and grep (or csv-tools) will take 5 seconds.

The point is if you need to do a specific task many times, do it in a programming language. But if you have an ad hoc task, you're saving a lot of time by being proficient in the shell.

<comment><USER17> Ad hoc tasks quickly become regular tasks though. If your "database" is csv files you're better off figuring out a better way to structure it.

The way things are moving with containers, the idea you're even going to have these utilities on the server, and the idea that the server is writing this stuff to a file system- that's totally changing. So is this useful for local stuff? Maybe, but is Excel probably more useful there?

</comment></comment></comment></comment><comment><USER19> Text processing is scraping. Modern shells have structured output from their stdlib, allow you to pipe to 'where' and 'select', and can read JSON, yaml, etc natively.

<comment><USER20> Which shells in particular are you referring to?

<comment><USER19> Mainly pwsh and nushell

</comment></comment></comment><comment><USER21> I wish man pages were this good!

<comment><USER22> [https://tldr.sh/](https://tldr.sh/)

<comment><USER23> Even better: [https://github.com/chubin/cheat.sh](https://github.com/chubin/cheat.sh)

This includes man pages from tldr, and more! The command line utility had been a great help for me over the past few months.

<comment><USER22> Thank you, did not know about this one!

</comment></comment></comment></comment><comment><USER24> I invite you to read [https://unix.stackexchange.com/q/169716/38906](https://unix.stackexchange.com/q/169716/38906)

</comment><comment><USER25> i was just missing a small note akin to "which becomes all the more powerful by combining these commands" and then make a totally readable example such as this one

         some_file=example.sh; tail -n +$(( $(wc -l $some_file | grep -o "[0-9]\+") - 5 )) $some_file

</comment><comment><USER26> Pleased add the "join"

</comment><comment><USER27> Just Don't. Unix-style text stream processing was super cool in 80s-90s but is born tech-debt today.

<comment><USER28> what do you do instead?

<comment><USER29> Output data as JSON, manipulate and show it with jq

<comment><USER30> not all data comes from sources that you control and have chosen how to output.

<comment><USER31> [https://github.com/kellyjonbrazil/jc](https://github.com/kellyjonbrazil/jc) can come pretty handy there

<comment><USER3> oh my god, why?! just why!?

What the world needs is the inverse program of "jc", where an unparseable json string is expanded into a flat list of lines all of the form "field.subfield=value"

<comment><USER32> If you search for "gron", you will find a family of such tools, e.g., [https://github.com/tailhook/rust-gron](https://github.com/tailhook/rust- gron).

<comment><USER3> Thanks, that's just what I needed!</comment></comment></comment></comment></comment></comment></comment></comment>


Angular 2 Core - <AUTHOR> https://docs.google.com/presentation/d/1XQP0_NTzCUcFweauLlkZpbbhNVYbYy156oD--KLmXsk/ <comment><USER3> I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.

I know Angular has a lot of community support and I have built some side projects in Angular but I feel now too bloated with having their own standards instead of following normal HTML standards. That's just my 2 cents on it and i'm sure there are a ton of reason to use Angular but I just don't know if I can continue supporting a project that makes so many drastic changes to a standard. I don't want to make it sound like I have Angular hate here but i'm a big vanilla fan and it seems in order to build anything useful in Angular you have to throw out vanilla and use Angular's way even if vanilla is better. On most projects handlebars and correct proper design patterns in code is enough to keep HTML out of javascript and keep basic organization.

<comment><USER4> > Sometimes I think Angular is mainly popular because it's supported by > Google. If any regular developer made these drastic changes in HTML with non > valid tags and attributes people would not be happy with that project.

This is a pretty interesting statement and I want to give it more thought. I've used Angular on plenty of projects and admittedly, It's felt a bit dirty to go back to spaghetti DOM that we worked for years to get rid of. All the books were saying to separate logic from our views. Now we're calling it declarative and it's acceptable again. I've been yelled at by other developers as if I should just forget the past few years and just get in line with what's currently the new hotness. Fine, I'm totally okay with embracing whatever is new and hot. But not just because it came from the same people that gave us Wave, Gears, GWT, etc. Let's not get involved in hero worship. All of those technologies had great ideas, yet were (overall) marked as failures. I'd love to have seen this same proposal come from some random Susan/Joe on their GitHub and see if it had been laughed off the stage for the same reasons I mentioned earlier.

<comment><USER5> > All the books were saying to separate logic from our views

It doesn't matter what the books say. Or rather - you've got to understand the reason for the advice - not just learn to follow the advice.

Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase. Everyone is trying to achieve the same ends - ease of development without sacrificing maintainability (to give a very simple example).

Catch-phrases such as "separate your logic from your views" was meant in a specific context. If you etch it in granite and pass it on to future generations it won't always embody the practical truth it was meant to convey.

So - we should remember the catch phrases but understand their context - <USER2> therefore we might hope to understand the more subtle and less easily stated truth behind the one-liners.

<comment><USER6> Exactly. There is almost no advice in programming which applies to all situations. The trick is knowing when not to follow the advice, and that cannot be explained in a one-liner.

Or, as the tao of programming says:

There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."

</comment></comment></comment></comment><comment><USER7> I want to be excited, but at the moment there's just so much new and unknown stuff I'm seeing that I'm just not sure. I don't like the new template syntax; html attributes with parentheses and whatnot just look non-standard and I don't really see why they did all that. I really need to dig into the design documentation and find out the whys behind all of these new features.

ES6 is also new, of course; when I first saw Angular 2.0 code, I didn't like it - mostly due to DI, which instead of a single argument in a simple function, now consisted of three different statements to have one service injected, which just feels non-DRY.

<comment><USER8> I disagree. New syntax actually gives much more for compatibility with other technologies and IDE integration. Also clean visual difference between events and properties - big thing. Not valid HTML... Well, not so high price.

<comment><USER9> That's a fair point. Being able to differentiate complex directives from attributes greatly helps separate the concerns visually.

</comment></comment></comment><comment><USER10> Even though this is still called "Angular", this new version has barely any resemblance with the previous one, it's really a totally new framework.

It's a bit sad to think that all this knowledge I have of Angular 1 is now obsolete but I'm excited to dive into this new framework. If it's half revolutionary as Angular 1 was, it's going to be a pretty interesting time.

<comment><USER11> I have to agree. Will there be backwards compatibility? If not, upgrading to angular 2 is going to require so much work and we'll probably end up switching frameworks. This could end up like Python 2 & 3.

<comment><USER12> It is not an upgrade if your old stuffs stop working. Man, 1.0 used to mean something.

<comment><USER13> What did 1.0 used to mean? I thought that major version upgrades typically mean that backwards-incompatible API changes have been made.

<comment><USER12> It used to mean that it is stable and it will carry on working as far as it can to the future major versions or until it is end of line of the product.

So I can understand if Angular 1.0 stopped working on Angular 4.0 or 5.0. Breaking apps just on one major revision number is really a bad way to manage frameworks.

<comment><USER14> It's what killed Drupal for me (and many others). Frameworks should provide for either a porting tool or backwards compatibility between major versions. Otherwise you alienate the people that trusted your in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER15> I'm quite disappointed by this presentation, I see only new syntax everywhere for approximately zero benefit.

There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps.

Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...

<comment> kuni-toko-tachi Agree 100%. Things like dependency injectors have no real place in JavaScript, where programmatic wiring and modules already solve the problem in an idiomatic way. Angulars modules factories services etc are absurd and attempt to reinvent what the language naturally provides.

<comment><USER16> >> where programmatic wiring and modules already solve the problem in an idiomatic way

Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves.

Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors).

DI allows you to provide an object with object instances it depends on without tightly coupling said object to those dependencies (pass a Door instance into a House instance, advantage being you can pass in any type of Door and House doesn't need to care - thanks polymorphism)!

I'm not sure that's a great explanation, but it's worth trying every now and then right?

You seem to be making the argument that the language provides alternatives, and it's true that in dynamic languages you can eschew some of the benefits of DI by doing monkey patching instead (e.g. to mock out an object's 'tightly coupled' dependencies during testing), but to myself and many OOP proponents DI leads to cleaner design and simpler tests.

<comment><USER17> _For example, if an instance of House requires a Door it is not enough to just require( 'Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors)._

So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance:

        function House(door){
            this.door = door;
        }

This is JavaScript, let's stop trying to make it into Java.

<comment><USER16> What you just wrote as a code example _is_ Dependency Injection, it's just manual dependency injection as opposed to using an IOC container or any of the mechanisms Angular provides.

I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said _' Dependency Injection is a 25-dollar term for a 5-cent concept'._ [1].

What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach.

[1] [http://www.jamesshore.com/Blog/Dependency-Injection- Demystif...](http://www.jamesshore.com/Blog/Dependency-Injection- Demystified.html)

<comment><USER18> > _When I realized it was "passing stuff in" I wanted to shout, I have done > that for years!_

Well, it's the "automatic" part that is important, not just the DI.

<comment><USER17> So the setter gets called automatically, but now you have to store the object names as strings or in an XML file. How is that better?

<comment><USER18> Loose coopling?

<comment><USER17> Well, now the different classes inside your application are more loosely coupled, but your business logic is more tightly coupled to a DI framework.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'm not sure I've seen a framework with such a drastic API change, particularly such a young API. I find that very threatening. Having spent a considerable amount of time learning and working with Angular.js, not only does this appear to be massively breaking changes, but it would also break 3rd party directives which has been a great benefit to building the Angular community.

This makes me think that Angular didn't think through their API for the 1.0 release. I would have thought Angular could have been written to improve the performance where needed without such drastic changes to the framework.

<comment><USER20> It has been talked about for almost a year that Angular 2.0 is going to be bringing such breaking changes. 2.0 is going to require complete app rebuilds _if_ you want to migrate to 2.0.

The good news is that if your code is clean, a migration shouldn't be too painful. The danger comes when you have unmodular code that sticks everything on $rootScope (for example).

<comment><USER19> Except in a modular app, I should be able to upgrade module-x to Angular2 without having it break the entire app. With this change I have to re-write every module in my app.

We've been looking at React at work over the last week, and were considering moving some of our angular directives to react. Now there is a larger case for building a complete app in Flux.

</comment></comment></comment><comment><USER21> I am literally working on a new project, starting to code the front end as of a day ago... I using Flux+React (nearstack.io, plug) around the Yahoo implementation of Flux's model. The down side, is this will be how things are for the next 3-5 years for the life of the site/application.

Angular 2 looks really cool... they seem to be embracing the shadow-dom concepts (like polymer) as well as es6-style import directives and expansion. I still think I made the right decision, but this is really cool and looks to be something that can work really well on current/next-gen browsers, but maybe not so well on currently supported browsers such as limited support for IE8 in my case :-(

I've been saying for a while that React/Flux is probably the best solution today for web applications, and that something similar to Polymer would be the best option in 3-5 years. I'll be watching this with great anticipation as Angular 2 actually changes most of my complaints about the framework today, and is really something that will come to work well.

Though, I'm not sure if they have or plan on a server-side component to handling server rendering, which is a huge part of why I went with React+Flux.

\-- adding to my post --

More Info: [http://ng-learn.org/2014/03/AngularJS-2-Status- Preview/](http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/)

Looks like they are indeed using Traceur as a migration path, and embracing many ES6 features. Not sure how they will go with Promises, or if they'll wind up going down the generator path. There's definately some interesting reading and watching for the next year or two on this. Also, really curious where Polymer is heading in the light of this as well.

<comment><USER22> FWIW, React will be in ES6 (with native classes and imports) before they tag 1.0. In fact, React 0.12 has some breaking changes to prepare for that transition.

<comment><USER21> Interesting... though not surprising... Honestly, I'm not a big fan of class hierarchy in JS. It tends to weight things down imho more than it helps. I'm generally in favor of decorating against object literals, which has some overhead, but less so than deep inheritance chains.

</comment></comment></comment><comment><USER23> Angular 1 developers should see this as an opportunity to abandon Angular and move on to React.

React is by far and away the best the market has to offer right now. From my perspective client-side applications are a solved problem thanks to React.

<comment><USER24> Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.

<comment><USER20> I disagree (about never going back) - I spent some time playing around with React (I authored [https://github.com/wesleycho/angular- react](https://github.com/wesleycho/angular-react) ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application.

Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.

Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.

HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).

<comment><USER24> > Angular has a void with the lack of a useful enough eventing solution - > $scope eventing ...

I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.

> HTML mixed in with JS via JSX is also an abomination ...

Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.

<comment><USER20> > I've found that using a publish/subscribe system for communicating between > components makes them more loosely coupled and modular. In most cases, the > components I've written are naturally somewhat slightly coupled so I just > pass around functions as props from parent to child components.

I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should address this hole.

> Totally agree. I use the default React.DOM elements instead. I find them > more transparent and easy to read, and manipulation of these are much easier > using the map, filter, folds etc.

Unfortunately it doesn't seem like React documented React.DOM :( . I would rather just use HTML, but I would rather have it in a separate file. Perhaps a build tool for grunt/gulp where you can register keys with the path to the template being the value, and the tool converts the value into the React.DOM elements would be a good idea.

<comment><USER25> > Unfortunately it doesn't seem like React documented React.DOM :(

React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.

<comment><USER20> At the least, I cannot find any mention of the specifics anywhere on the main GitHub page - this is the best that I can tell: [http://facebook.github.io/react/docs/top-level- api.html#reac...](http://facebook.github.io/react/docs/top-level- api.html#react.dom) . I do know the recommendation is to use JSX, and I can see why, but more visibility of the API would be better.

Edit: As a note, I did find out how it worked by doing source code diving two months ago.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> To everybody trying to make this into a tech fight about Angular vs. React/whatever, I've been repeating this like a mantra and even mentioned it in a talk on javascript once[0]:

You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts.

jQuery: (for reference)

        5,656 commits
        7 branches
        122 releases
        199 contributors

React:

        3,003 commits
        10 branches
        18 releases
        226 contributors

Ember:

        7,490 commits
        35 branches
        90 releases
        412 contributors

Angular:

        5,988 commits
        12 branches
        111 releases
        1,044 contributors <---

I have made a bet on Angular two years ago and the reason was: They understand how to herd cats. They get community right and at the end of the day, that's the only thing that really counts (no matter how much nerds like to pretend that it doesn't and it's all about technological purity or what have you).

I am absolutely confident that they are making good calls and the way they have handled the transition periods so far (and the way they are going about these new "big" changes) only increases my confidence.

I would be very surprised if in a few years, Angular wasn't on the same level of "you can basically assume that it's loaded" as jQuery is.

[0] [https://www.flickr.com/photos/valanx/14136669418/in/set-7215...](https://www.flickr.com/photos/valanx/14136669418/in/set-72157644551467698)

<comment><USER27> React is just newer. Give it some time.

<comment><USER28> Indeed. If number of contributors is the only metric that counts then, since React has more contributors than jQuery, I guess that means we shouldn't bet on jQuery. Nobody's gonna be using that fly-by-night project in a year!

<comment><USER26> That's why I wrote "for reference". jQuery, of course, is a different kind of library.

A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.)

Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find a reason to dismiss React and I do realize that it is still young. From a business standpoint, though, the choice couldn't possibly be any clearer.

I do agree that React has gathered a sizable crowd in a short time and it's definitely on my list of projects that I keep an eye on. But it's simply too young to warrant the same kind of investment that I have personally made into Angular.

<comment><USER27> > But it's simply too young to warrant the same kind of investment that I have > personally made into Angular.

Sure .. it makes sense. Though one of the main selling points of React is that it's dead easy.

</comment></comment></comment></comment></comment><comment><USER29> Guys, relax and stop whining. You are probably wrong about what is going to happen with Angular, because you underestimate how massive Angular has become.

I recently began searching for a new JavaScript job. I don't like Angular at all and I am skipping all positions that mention it. I have to skip ~90% of all ads. Think of it – 90% of companies that are expanding their web development use Angular.

So, even if this change will kill Angular, it will probably take years. It has become too big to fail.

If you like Angular, get excited about it. Look at how .NET or Java guys accept everything coming from Microsoft or Oracle. You are in a similar ship now. No one got fired for choosing Angular. No one will.

<comment><USER30> Is this right? I can't believe for a millisecond that 90% of all new JS jobs relate to Angular, it's a horrible and overblown framework with a high barrier to entry. Were you looking at a particular subset of jobs, a particular industry or in a particular location?

<comment><USER31> > it's a horrible and overblown framework with a high barrier to entry

Listen, if _I_ can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown and the barrier of entry was there but I got over it. By all means, keep ignoring it, but drop the shtick where you know better than thousands and thousands of us out here building things with it.

<comment><USER32> >if I can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown

That's a weird argument. Just because you think it's not horrible or overblown doesn't really mean much. That's just an opinion.

I've worked full-time with AnguarJS over a year, and I know it pretty well. It's easily better than jQuery spaghetti code, and probably better than most data-binding frameworks. It has lots of issues, though. From bad documentation and performance to the mess of $scope.$apply/digest loop and a lot of moderate design problems.

Anyway, the biggest problem is the boat. AngularJS is really trying to "eat" other libraries and actually doesn't try to be modular. A data-binding/MVC framework shouldn't invent it's own module system, and recently it's own _programming language_. Apparently Google is trying to kill of jQuery too and substitute their own system. And they want to reinvent everything as AngularJS modules instead of "plain" JavaScript code that can be used across multiple frameworks.

What I'd like to see in AngularJS 2 is a tiny core which does data-binding without $scope.$apply, is fast and modular and could be used with a wide range of other frameworks. What I don't want to do is start writing AngularJS modules with AtScript and using their forced(?) ES6 classes.

<comment><USER20> Angular 2 definitely aims to be more modular - the Angular team acknowledges the problem that it isn't modular enough itself. Stuff like di.js, watchtower.js, zone.js, etc. are all built with modularity in mind & are framework agnostic. I think once Angular hits 2.0 and it becomes highly modular, we are going to see a boom in development productivity. Some of what is currently in Angular is unique for JavaScript, such as the change listener pattern and dependency injection. These are things that we'd like to take advantage of with other libraries. Combining stuff like di.js with React sounds very appetizing to me.

In addition, it would appear that we would be able to use these libraries with Node.js as well.

I can only see this being a good thing.

</comment></comment></comment></comment></comment><comment><USER33> It's sad to see a post on HN specifically devoted to Angular utterly devolve into framework flame wars. If the title were "Why Angular 2 will be better than React" I could understand, but this is just a sneak preview of features to come. Can we please just choose the tools we prefer and build stuff instead of nursing our insecurities about the choices we've made?

<comment><USER34> As someone at the inflection point of choosing a single-page framework, I find these "flamewars" incredibly useful. Further I find the notion that this is evidence of insecurity itself evidence of insecurity -- why feel threatened that people discuss alternatives and merits/detriments?

When new language features of C# or other languages (e.g. Go) are brought up on here, inevitably those features and benefits will be contrast against other languages. _And they should_. Because we aren't hammers and everything isn't a nail, and even if we happen to use tool A today, we usually have the capacity to move to tool B tomorrow if it made sense.

<comment><USER35> Surely you don't really find "off topic" complaints an insecurity. This article is about Angular 2.0, I would expect to read about thoughts/pros/cons about Angular 2.0 when reading the comments.

It's similar to reading comments on a Halo (Xbox) post on Reddit. Over half the comments are flame wars about PS4 > Xbox. There have been many "framework vs. framework" potss already on HN, let's keep the flamewars contained.

<comment><USER36> No, sometimes you don't really know what something is without holding it up to a yardstick. Flamewars are annoying, but this isn't a flamewar.

Carry on.

</comment></comment></comment></comment><comment><USER37> The problem I see with this is that it's very different from Angular 1 to the point people using Angular would have to learn it all over again.

Breaking how the framework looks this drastically is both very brave and very risky. Especially since from discussions with Angular core (and as you can see from the presentation) - Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any browser and worse - are not known by most web developers anyway.

<comment><USER38> Agreed. This looks almost like a complete rewrite, which seems like a good thing because IMO Angular 1 is overly complex. But it does make me wonder if I should bother to really learn Angular 1 at all. The main thing pushing me towards Angular has been the size of the community but if they're wiping the slate then I might just go with React after all.

<comment><USER21> Angular has some huge support and momentum behind it... there has also been a lot of job postings around it as well. That said, I couldn't get past some of my issues with it, and that server rendering (shared code) was not really a good option there... The issues with dependency injection is another issue, and testing pretty much requires a browser.

These are the reasons I'm using flux/react now. I'm really looking forward to following the development of Angular 2 now, and may just be my tool of choice for new development in a couple years.

</comment></comment></comment><comment><USER39> I think it's hilarious how javascript frameworks are beginning to resemble java frameworks. This new release is really starting to look like Spring, including annotations. The increasingly complex DI is also looking like Spring.

<comment><USER40> original author came from Java server-side background I believe, that probably explains why you see similarities.

</comment></comment><comment><USER41> There have been so many binding frameworks, with a few varieties of approach. It has always been clear that it's "experimental". But it's been a few years now, and the mature(er) frameworks are focusing themselves.

This is a good thing! I'm glad they're learning, and willing to make it better. In my career I've gone from ASP -> PHP -> ASP.NET Web Forms -> ASP.NET MVC -> Angular/knockout/react. We're developers, if you can't flow with change you should move on to one of the more established engineering disciplines.

<comment><USER12> It's not about you, the developers. You can easily move on and jump from frameworks to frameworks.

Your clients or employers suddenly have to worry about one extra thing because their newly developed applications/systems suddenly become 'out of date' simply because the crazy churn in on JavaScript frameworks API.

It is not a good thing. We are invalidating people's investments, time and money for no good reason.

<comment><USER41> Honestly, that's why you don't develop a new production system in a framework that's just a few years old. I had a coworker suggest using Angular on our main product that pays our bills. My reply was, it looks great... i'm excited about it, but I think we should use it on less critical systems until it matures. There's too many unknowns. There's no reason every new platform you develop needs to be using literally the latest tech. Actually, there's really good reasons not to.

<comment><USER42> Too many unknowns is way too broad of a reason when it comes to JS. JS is already the language of unknowns. It really depends on the framework, timing of things, people behind it. Angular is by Google, but also Google is pushing Web Components at the same time, which can integrate with Angular 2, but it challenges it as well. Also with Angular 2's goals being known for a long time, anyone could tell that ES6 would be a dramatic wave of change to the framework.

With JS, all the frameworks and libraries out there are just a few years old. Angular is about 5 years old, but Google doesn't even use Angular in their sites, which should be extremely telling (along with the complexity learning and figuring out the API). In fact I think Google isn't even planning on Angular on any Google sites in the future. They are waiting until Web Components are finalized.

With React, it is apparently mature enough, it is used on Facebook (1 billion users), Instagram (a child company of Facebook, like Youtube for Google), Khan Academy, Github (github issue viewer), AirBnB, CloudFlare, and a lot more:

[https://github.com/facebook/react/wiki/Sites-Using- React](https://github.com/facebook/react/wiki/Sites-Using-React)

In the JS world, there's a lot of reason to keep moving forward with tech. Sure it doesn't have to be the latest and greatest, but since JS is such a "poor" language, a lot of these newer tools, features, framework, and libraries help build more professional, quality code. Shying away from newer tech (again not the latest and greatest, but away from tech that improves quality of code) highlights obstinance and ignorance about the technology behind it, as well as how little someone understands the industry today.

<comment><USER20> Google does use Angular on many sites in production - the number is somewhere over 120 according to their metrics last I heard. They even use it for static pages - I noticed that the older Google Nexus pages were done in Angular. They prominently tout using Angular for DoubleClick, among other sites. It is also used widely internally.

Angular is also used by a formidable set of companies in production - Microsoft, Google, Apple, VMware, Netflix, MSNBC, Bloomberg, Washington Post, USA Today, US News & World Report, Amazon, Udacity, Cisco, and countless others. I have heard of it being used in the financial sector quite a bit as well. The prevalance of Angular and the strong support by Google is far more telling.

<comment><USER12> I will challenge that 'strong support by Google'. Angular.js 2.0 is an abandonment of Angular.js.

</comment></comment></comment></comment></comment></comment><comment><USER43> Every large opinionated framework is "overblown" (aka "scary") until you actually take the time to learn it and code a few large non-trivial projects with it. I've learnt more MVC frameworks than you can shake a stick at and Angular is hands down one of the best. Once you're comfortable with it you can fly and code things so quickly and cleanly, and it scales well into complex apps too. Angular is largely designed the way it is to promote small, encapsulated, testable components. But if you're not practising TDD, or don't test your code at all, (which I suspect is the case for many of the framework's detractors) then it possibly is somewhat over architected - by all means pick a simpler framework, but don't knock it from a position of ignorance.

<comment><USER44> TBH, I'm both amazed by the power and simplicity of Angular && mad at how difficult and unpredictable is to unit test services that use promises and/or depend on other services.

<comment><USER43> You can fully mock out those services and pass them into the component under test. Those mocks could return an immediately succeeding (or failing) promise for example. Hey presto, no uncertainty or weird promise handling code in your tests.

</comment></comment></comment><comment><USER45> Ouch, just spent this month learning Angular... And now 'RIP angular.module, controllers, $scope' etc.

Does anyone have some idea about when this launches and when it can be sort of considered stable for building apps beyond mere prototyping? Curious about the timeframe :) Thanks

<comment><USER24> > Ouch, just spent this month learning Angular

I've found that no knowledge I've gained from learning technology/framework/language etc has ever gone to waste.

Somewhere down the line, the insights gained previously come in really handy or even make something that I thought wasn't possible, realizable.

</comment></comment><comment><USER46> Took some digging but I found a video: [https://www.youtube.com/watch?v=S8fE-w2DL8U#t=54m12s](https://www.youtube.com/watch?v=S8fE-w2DL8U#t=54m12s)

Edit: They took it down, sorry :\

<comment><USER47> This video is private.

</comment></comment><comment><USER48> This looks like a completely new framework, version 1.0.

I don't think I'll use Angular for any new projects, they basically flushed every library and documentation (1st and 3rd party) down the drain.

</comment><comment><USER49> As somebody with little experience writing web applications, having just used ember for a my last project, these Angular 2 Core highlights seem way behind ember.

</comment><comment><USER50> I knew there was a reason I put off learning angular.

<comment><USER51> I'm not so sure. I think it will take about 5 years for angular 1.x to lose momentum.

</comment></comment><comment><USER52> Intresting, but WHY are these approaches better. Is that adequately explained?

<comment><USER41> I think this is the problem with posting slides, and not a video. For most presentations slides are bullet points. It's like ordering a cheese burger without the burger.

</comment></comment><comment><USER53> From [http://jaxenter.com/angular-2-0-112094.html](http://jaxenter.com/angular-2-0-112094.html):

> _the framework will be "drastically different looking", meaning users will > need to get to grips with a new kind of architecture. It's also been > confirmed that there will be no migration path from Angular 1.X to 2.0._

> _Currently Angular is aiming for a release by the end of 2015 – but early > 2016 seems more realistic given the drastic changes that are planned._

This essentially makes investing in Angular pointless, when there are far more capable and easier to learn frameworks out there - Meteor primarily, and also Derby.js, though it's got about 1/10th of the momentum of Meteor, which launched 1.0 two days ago, and had 20k GitHub stars without backing from some giant company. BTW, Meteor never broke compatibility with earlier releases in such drastic ways as Angular will.

</comment><comment><USER54> It took a lot of time for me to get the hang of AngularJS 1.x and now AngularJS 2 seems very promising but shifting along with the new syntax, programming logic is really painful..

They should provide a path to easily shift programmers thinking from 1.x to 2 (hopefully it is already in their roadmap)

<comment><USER55> IIRC, in the larger Google Doc cache of their Core documentation for Angular 2.x, they've stated in the manifesto of sorts that, well, that "easy shift" may just not be possible. Primarily when it comes to migrating existing applications.

<comment><USER54> Although I am looking forward to the Angular 2.x mainly to see what it has in store in terms of performance.. i had had faced performance issues with Angular regularly

</comment></comment></comment><comment><USER56> 1\. For developers, change is usually a good thing in regards to our careers. If you aren't learning and growing, it's not Angular that will go away, it's you.

2\. They are following the [http://semver.org](http://semver.org) definition of a major version change perfectly fine "MAJOR version when you make incompatible API changes".

3\. If anyone is bothered by the complete shift, fork Angular at version 1.3 and maintain it yourself. That's the joy of open source. You might even be a hero to many other developers.

</comment><comment><USER57> I tried both EmberJS and Angular. To me it seems Ember is years ahead, the main advantages:

\- clean model abstraction, which prevents soo much boilerplate \- clean templates \- components, partials, great re usability

<comment><USER58> I've built one significant project in Ember, and three in Angular (multi-month projects with a small team; requiring maintenance for the next 3-4 years; < $100k USD).

Ember 'feels' so much more right to me. I really enjoyed working with it and it reminded me of the desktop frameworks I used to work with. It's not without it's faults, but what is.

But sadly Ember just doesn't seem to be holding it's head up in the ongoing swell of JS frameworks. I think that is a great pity. But time goes on and they'll all be forgotten in a few years.

<comment><USER58> "its"

</comment></comment></comment><comment><USER59> Is there anywhere with further detail on this?

(Because it looks fascinating, but I'd like to see some detailed documentation and examples on how it's going to work.)

<comment><USER37> Yes, if you go to the AngularJS GitHub it's full of design documents and debates about 2.0, for example - here is 2.0 change detection for the data binding: [https://github.com/angular/watchtower.js/](https://github.com/angular/watchtower.js/)

It's not proper documentation but debates and design documents but it's all there.

Of course - not to forget [https://github.com/angular/Angular2.design](https://github.com/angular/Angular2.design)

</comment></comment><comment><USER60> I don't know exactly how many of the Durandal & Angular convergence[1] features made it into Angular 2.0, but it looks like lazy module loading and a better component syntax did, which is fantastic

[1] [http://angularjs.blogspot.fi/2014/04/angular-and-durandal- co...](http://angularjs.blogspot.fi/2014/04/angular-and-durandal- converge.html).

</comment><comment><USER61> I love how they use attributes, I've been impressed by attribute modules for CSS. The only thing I am surprised, I would think that this would include significant overhead, yet you claim it is way faster. Most likely previous scanning of the dom was even slower.

I think this is excellent use of attributes and good way to refactor things. What others pointed out, this is different framework :)

</comment><comment><USER62> Great to see HTML5 growing so rapidly during the past few years! That said, I'm not a huge fan of frameworks, they do not work so well except for basic pattern apps. When you have an app worth building you consider very carefully what foundation stones to use. I ended upright on my feet and happily dancing using React as one of the stones.

</comment><comment><USER39> Can anyone suggest which practices can be added to the use of 1.3* to ease the transition to 2.0? For instance, if I start using grunt-ng-annotate or gulp- ng-annotate now, will that help ease the transition? If it would, I'd be curious what other things I could do to make the switch less abrupt.

<comment><USER20> I think the biggest win would be to start using ES6 and getting used to using the import/export syntax.

</comment></comment><comment><USER63> New syntax is ok, quite cool actually, but I'd rather see more improvement on things like route, high performance repeat. Hope they bring some goodness from Angular 2 to Angular 1x as well. Also, not sure how the old directive/plugin ecosystem would fit in, is there any rewrite needed?

</comment><comment><USER64> In your face Angular fans, who said that all the angular stuff was the best way. They scrapped most of it!

</comment><comment><USER65> After looking at the doc, my first reaction is that all HTML should be schema compliant. Using non-standard HTML in the constructs will screw up a lot of tooling and validation.

It's also safe to say this is just too big of a change without public commentary. Way too big.

</comment><comment><USER66> I understand wanting to appeal to the same user base and tell that it was develop by the same team. It's a brand decision. Nevertheless Angular 2 "deserve" a completely new name. It has no resemblance of Angular 1.x. Welcome to a new framework.

</comment><comment><USER67> Nothing surprising or disappointing here in my opinion. It was my understanding from day 1 that ng was Google's experiment and attempt in transforming and mutating HTML into a language for web apps instead of web sites.

</comment><comment><USER68> Is this for real? Is this the official direction for AngularJS 2?

Seems like a very big leap considering people are just getting use to the way AngularJS 1 works ($scopes etc).

</comment><comment><USER12> This is what is shit with JavaScript frameworks, no respect to backward compatibility. Imagine if these kind of API churning happens in C++ or other languages.

<comment><USER69> I'm sat right now coding a bunch of new stuff in angular 1.2 - it was feeling sweet until I read this - now it feels old and outdated. Time to just ignore the massive race to reinvent the framework and just get some stuff done I think.

</comment></comment><comment><USER70> What does Angular win you beyond what you get in Web Components? I haven't used Angular, so this is curiosity, not a challenge being issued.

</comment><comment><USER71> I'm now wondering what will happen to other projects that have placed a huge bet in Angular 1.x, like the Ionic Framework for example...

</comment><comment><USER72> Is he using TypeScript or ECMAScript 6? Also, is it just me, to does this seem like a completely different framework than Angular 1?

<comment><USER73> Typescript is ECMAScript6, with additional (typing) features.

I'd venture it's ecmascript 6 being used, as Google suffers NIH syndrome too..

<comment><USER72> Yeah, it definitely is EcmaScript 6. They've added the "class" and "constructor" keywords. Typescript is very mush modeled after EcmaScript 6 anyways, so technically it can be both. But I'm sure it's EcmaScript6, because that's what Angular 2 is written in.

<comment><USER36> See the post about Google's AtScript that was on HN yesterday.

<comment><USER72> So is this basically TypeScript with annotations and types available at runtime?

</comment></comment></comment></comment></comment><comment><USER73> is there a video of this? viewing these slides is like reading every-other page of a book :(

</comment><comment><USER74> So... upgrade path is nonexistent?

Looks like it's great if you're starting from scratch though!

</comment><comment><USER75> time to find another framework to work with

or best is, just scrape client side MVC framework, and fallback to server MVC framework

</comment><comment><USER76> bye bye angular. need new framework due to 2.0 if I have to rewrite then I might as well look at others.

</comment><comment><USER77> Is this just a proposal or something?

</comment><comment><USER78> This is a change for the far worse, someone branch this please and maintain a backward compatible branch with the same syntax.</comment>


A flaw in the Apple Watch leaves it absurdly vulnerable to thieves - <AUTHOR> http://uk.businessinsider.com/apple-watch-theft-kill-switch-activation-lock-iphone-reset-2015-5

<comment><USER2> If someone gets close enough to me to remove my watch from my arm, I'm pretty sure I'm gonna have bigger problems then them re-selling it on eBay or at a local pawn shop (such as getting beat up or possibly stabbed / shot)

Sensational headlines FTW!</comment>


Go Performance Dashboard - <AUTHOR> http://goperfd.appspot.com/perf

<comment><USER2> So in the stats, Red is bad, yellow is good, on a row-by-row basis?

But something should be done about the scaling of the #s on the stats page. It seems that each row is a factor based on the row below. But : Look at the lines 1715f0128906 -> fca7904c77ce, where an intentional slowdown was inserted, and then reverted. The Red looks far worse than the Yellow that follows (say, +3782% -> -97.42%), whereas (I assume) that they are equivalent, but opposite. Perhaps the differences could be (t[n+1] - t[n])/t[0], so that the numbers sum up?

</comment><comment><USER3> Interesting! Can you explain what are the benchmarks(build,http,json,rpc)?

<comment><USER4> Calling them fascinating would more approriate since there is no way to understand what these numbers mean. It's like the Avatar film without the sound track. Not sure if it's really interesting yet.

</comment></comment><comment><USER5> This is very cool. How was it built? Is the source available? Clicking the commit SHAs doesn't link to the commit for me.

<comment><USER6> There's some info here: [http://grokbase.com/p/gg/golang- dev/13bs7d4qm3/performance-d...](http://grokbase.com/p/gg/golang- dev/13bs7d4qm3/performance-dashboard)

</comment></comment><comment><USER7> Can I deploy it on my laptop?

<comment><AUTHOR> Why not? It's available. But you'll need GAE setup and Go source code compilation. BTW, it's actually for the developers of Go itself.

</comment></comment><comment><USER6> Really nice!</comment>


Apple Loses German Top Court Case on Swipe-to-Unlock Patent - <AUTHOR> http://www.bloomberg.com/news/articles/2015-08-25/apple-loses-german-top-court-case-over-swipe-to-unlock-patent <comment><USER3> This always struck me as an "On the computer" patent. The slide to unlock mechanism has been around since forever (think any bathroom stall or old wood screen door, etc). Just because it's on a computer screen shouldn't make it patentable.

<comment><USER4> I think these are different, though I don't necessarily think it deserves a patent.

In real life, slide to unlock pushes a bar in place to prevent the door from swinging open. You slide to unlock, so the bar is moved away from blocking the door.

"On the computer", it's making sure that you deliberately intended to use the device and it's not an accidental "pocket dialed" motion.

These are similar motions addressing different problems. In the physical world, you slide the bar into place to allow the bar to work for you. On the computer, you slide to express a deliberate intention.

Anyway, deserving of a patent or not, these seem like different mechanisms.

<comment><USER5> That argument could be applied to any digital concept that has a real life counterpart. "Window" for example, in the real world it's made of glass and keeps rain out. Does that mean the digital window is different enough to deserve a patent?

But more importantly, "slide to unlock" is essentially "swipe to unlock". The swipe zone is confined to a specific area, but it's still swiping. "Flicking" also works. Apple are trying to patent "swiping", which is ridiculous.

Just like "double click to unlock" would be equally absurd as a patent for unlocking a desktop PC. Changing the name to "double press to unlock" doesn't suddenly make it unique.

<comment><USER6> You're making his case for him. A computer windowing system should be able to be patented even if real windows exist.

<comment><USER7> A computer windowing system does not model real windows, it models pieces of paper, spread across a desk.

On a desk cluttered with papers, you can see bits of some papers and others papers are hidden by other papers that are on top.

There is no way you should be able to patent such an obvious real world, real life experience, just because you were the first to take that real world experience and replicate it on a computer screen.

All you have done is modeled a real work experience.

</comment></comment></comment></comment></comment><comment><USER8> Minor nitpick: The ruling court was not "the German Supreme Court" (which there is no single direct equivalent - often the term is used for the Bundesverfassungsgericht but that's problematic on many levels). The court was the Bundesgerichtshof which is the highest court for civil cases. Best is the avoid the term "Supreme Court" at all when talking about the German court system.

<comment><USER9> The Bundesgerichtshof is also Supreme Court for criminal cases.

The phrase "Supreme Court" is indeed problematic, since we have quite a few of them (administrative law, labor law, finance law, social law, plus BGH and BVerfG), but I think it's okay to call the Bundesgerichtshof so.

More okay than calling our Federal Constitutional Court "Supreme Court", at least, since generally speaking the Constitutional Court is not "above" the other courts.

<comment><USER8> I would be happy with calling it "a German supreme court" (which is maybe misleading but technically correct). The phrasing "the German Supreme Court" implies that there is only one and it's somewhat comparable to the US Supreme Court which are both wrong assumptions.

</comment></comment></comment><comment><USER10> Even the so called "good" software patents have a lot of the same elements as this bad patent. The problem is, most people aren't going to bother to read the claims of those patents and try to understand what the concepts claimed really are.

I have been involved with several patent suits (on both litigant side and defendant side) and as an engineer, I have to admit that there has never been a time when I haven't read the statement of the problem the patent says its going to solve, and not thought of the solution myself, way before the patent presents the same solution. In other words, every single litigated software patent I've been asked to review has been BLATANTLY obvious. And I'm no genius. I've talked to other engineers and they've all said the same thing. I just explain a problem domain, and they usually give a solution that comes under the claims of the litigated patent.

This is not to say that there aren't non-obvious software patents. Its just that those never seem to get litigated, because they aren't some obvious concept sitting at the nexus of a well-trodden path the industry is following.

I can't describe or link the specific patents I've been involved with, for obvious reasons, but the stuff I'm talking about sounds like things as follows:

"Receiving at a server a data packet, the data packet comprising a user identification number and a merchant identification number

retrieving a record in a database referenced by the user identification number

determining if the record in the database contains an authorization entry corresponding to the merchant identification number

responsive to the record in the database containing an authorization entry corresponding to the merchant identification number, transmitting a second data packet, containing an authorization token, to a server operated by a merchant."

I am not lying to you. This is how stupid each of these patents have been. Sometimes even worse.

Nobody not involved in these litigations understands how bad it is. And this is coming from someone who has made at least enough money to buy several luxury cars, providing consulting services to this particular legal industry. In other words, I have a financial interest in things remaining this fucked up. And I'm still telling you, its really fucked up.

<comment><USER11> Yes, I think this is the essence of the problem: the PTO and the courts have a very hard time distinguishing a nonobvious invention from an easy problem that merely happens to have been solved for the first time (as far as the PTO can tell).

I have occasionally seen a software patent with an idea that was not obvious at least to me, but I haven't seen many of them. Most have been as you describe: once the requirements are understood, there is no difficulty designing a system to satisfy them. It's just that (again, as far as the PTO can tell) nobody has come across that particular set of requirements before.

I think that in order to litigate a patent, the patentee should be required to provide evidence that their invention was nonobvious. The PTO is poorly equipped and structured to do a good job filtering out obvious "inventions" (for example, examiners have no incentives to do so); and yet, as things stand, the courts defer to the PTO on this question. I think the rules should be changed so the court has to be persuaded of the nonobviousness of the patent before the suit can proceed. That would be a potentially adversarial proceeding itself, in that the defendant would be allowed to argue that the invention is obvious, but the primary burden of proof would be on the patentee.

One could argue that this would put on the court a job that should belong to the PTO, and that argument has some merit, but here's a counterargument. It's often hard to tell, when a patent application is filed, how much the potential patent will be worth. Delaying part of the effort involved in evaluating the patent until such a time that the patentee has actually decided to litigate makes some economic sense. More to the point, it is often easier to show nonobviousness once some time has passed. One of the Graham factors [0] that can be used as evidence of nonobviousness is commercial success of a product based on the invention. Such success can't have occurred yet at the time the patent application is filed.

The change I am proposing would constitute a massive shift in the balance of power between patentees and alleged infringers, and a lot of oxen would be gored; I'm well aware of that. A lot of companies would see the putative value of their patent portfolios drop precipitously. Against that, they would have to worry a lot less about being sued.

I'd be interested in your take on this, as you've been inside the system a lot more than I have.

[0] [https://en.wikipedia.org/wiki/Graham_v._John_Deere_Co.#The_P...](https://en.wikipedia.org/wiki/Graham_v._John_Deere_Co.#The_Patent_Act_of_1952)

<comment><USER10> How would one present evidence of non-obviousness? It seems very difficult once a solution is presented. Its a bit easier to prove that something was obvious at the time of invention. One sure sign is if there are many cases of independent invention.

I think therefore that one simple way to ameliorate some of the abuse in patents is to give defendants an independent invention defense. What I mean is, if you can prove that you had no access to the patent holders patent or idea, and that you came up with it independently, then, that should be taken as a factor showing that the solution may have been obvious. If additional companies similarly show that they also independently came up with the same solution, then that is additional strong evidence of obviousness that should make the finding of obviousness more likely.

Right now, independent invention is not a defense. And multiple independent invention isn't even considered evidence of obviousness.

As embarrassing as slide to unlock is for the US patent system, its actually not the more egregious case of obvious things being patented. If you look at what is being filed in social networking patents, database patents, and cloud computing, any person here on Hacker News would be shocked.

The problem is, the USPTO examiners are NOT shocked. Have you ever talked to one of them? The quality of their technical knowledge is EXTREMELY poor. EXTREMELY. The USPTO seems to have recruited third-rate PHDs and other "technical" folk from developing nations, and put them into examiner positions based on their degrees alone. I have seen many many office actions from USPTO examiners where it was obvious that the examiner understood absolutely nothing of the patent he was reading, so he just did a Google search on the key words in the abstract and pasted the paragraphs he found into a response. The office actions are not even coherent, much less effective.

Don't take my word for it. Do a search for a patent that has some technical phrase you are familiar with ... say Markov Chains. Then take the patent you find and go to the USPTO Public PAIR database. Pull up that patent application. Go into the record of documents for that patent and read the first office action that was sent by the USPTO for that patent ... I will bet you 10 to 1, the office action will be utter gibberish that makes no sense. I'm willing to give you those odds, because out of the hundreds of office actions I have seen, perhaps less than ten have made any sense ... where the examiner had any clue at all.

Programmers don't realize this basic problem.

Every patent lawyer understands it. And they are embarrassed by it. They are embarrassed because they are making tens of thousands of dollars writing oppositions to documents written by what are essentially technically retarded individuals. This is not a disputed fact. Go put some beers into a patent prosecution attorney, and let him start talking to you about office actions he has received from the USPTO.

These office actions usually don't get seen by the public. They only get surfaced in big litigations ... and when they are surfaced, all involved are deeply embarrassed. Why? Because both plaintiff's and defendant's attorneys don't want to come out and say that they are making a living in a system that is fundamentally broken at its very core.

What does it mean if the USPTO patent examiners don't actually do any examination worth a damn at all? Has the American public been made aware of this blatantly obvious and true fact? No. They continue to think that the USPTO is actually serving a useful examination function. That is a complete and utter lie. And its a lie out in the open. Just open up the prosecution history for any technical patent as I asked earlier. ANY TECHNICAL PATENT.

<comment><USER11> The problem with the independent invention defense is, how can you ever _prove_ you had not seen the patent? One could read a patent, then change terms, rearrange parts, etc. until it was not at all clear that one's own expression of the idea actually came from the patent. I realize an independent invention defense seems natural to us as engineers, since we independently (re-)invent things all the time, but I don't see how it would work as a matter of law.

And people wouldn't necessarily have to have read the actual patent in order to abuse such a defense -- they might just have seen the product that incorporates the invention.

As for how one would present evidence of non-obviousness, if you follow the link I gave, you'll see three kinds of evidence which can support such a claim, according to the Supreme Court: commercial success; long-felt but unsolved needs; and failure of others. I think what these all have in common is clear: you need to show that others have had an incentive to try to solve the same problem, but haven't done so. _That_ would constitute evidence that the solution wasn't obvious.

> It[']s a bit easier to prove that something was obvious at the time of > invention. One sure sign is if there are many cases of independent > invention.

How would this work? If the independent inventions occurred _before_ the patent application, they're already prior art; if they occur after, then once again, we can't know they were truly independent.

I already knew the examiners were pretty bad, though maybe I didn't realize quite _how_ bad.

How did you get started in this kind of consulting?

<comment><USER10> There is an independent invention defense of sort in Copyright Law. A Copyright plaintiff actually has to prove that the defendant had access to the material and was inspired by it (or copied it).

BTW, substantial similarity acts as defacto evidence of copying in Copyright. So, you might claim you didn't copy Michael Jackson's Thriller because you were on a desert island and never heard it, but if your rendition is really similar to the original, then that similarity is itself proof sufficient that you are lying. Additional evidence isn't necessary.

In software things could work differently. I think one way the defense would be most aptly used is in cases like the notorious podcasting patent. There you could see literally hundreds of independently written podcasting style applications, where literally every one of the engineers writing podcast software were willing to testify that they'd never seen the podcast patent or heard of the company that wrote the patent. I think courts can take that as strong evidence of obviousness, as all of those engineers perjuring themselves is unlikely, and the simultaneous widespread invention of the same thing means its probably an inevitable and obvious advance.

I don't want to go into too much detail about how I started my current patent work, because this account is anonymous. I'll just say, though, in this business credentials mean everything and actual practical expertise means nothing. I have a law degree from a top ten law school in the US, in addition to an engineering degree from an Ivy league school, and over a decade of engineering experience at brand name US tech companies. My resume looks good. That's why I get work. It has nothing to do with my skills as an engineer. I know how to communicate technical ideas, read legal documents, and look confident in my advice to people for whom appearances matter.

Any bright engineer can learn to do what I do in less time than it would take to master something technical (like machine learning), but you'll need paper credentials to get in this business. That's why I don't recommend this line of work to people that prize capabilities over paper.

Also, its a get rich slow scheme.

<comment><USER11> But that's exactly the difference between copyright and patent: copyright covers the expression of an idea, but patent covers the idea itself. J.K. Rowling can't sue me if I write a book that's just like Harry Potter except that the places, characters, and storyline are all different, and all that remains is that it's a book about kids growing up learning about magic at a weird school. On the other hand, if it were possible to patent such an idea, and Rowling had done so, then it wouldn't matter that I had changed all those things: the idea would still be there.

So for copyright, the absence of substantial similarity is a straightforward defense, but it couldn't work that way for patents.

I agree about the podcasting patent. There are a few cases where so many people have independently invented the thing that its obviousness is overwhelmingly clear. I don't know how often that happens, though.

<comment><USER10> It happens all the time. In fact, that's where all the valuable patent litigations happen.

<comment><USER11> Well, from your perspective it may happen frequently, because those are the cases you get called in on. That doesn't necessarily mean that these cases represent a large fraction of the obvious patents that have been issued and that we would like to see invalidated. There are an awful lot of those, as you yourself have pointed out.

Thank you for your comments, though. It has been interesting hearing about your experiences, and I think we agree on many points.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I think this should apply generally to touch screen gestures. Once someone invented a good enough touch screen display(capacitive) , the gestures are not that big of a step.

All Apple did was to acquire the inventors of the capacitive touch - <USER2> worked a bit on the UI. And while it's valuable to be the first company who recognize the importance of a capacitive touch screen - that isn't a basis for a patent - and Apple did get enough benefits anyway.

<comment><USER13> Like the bounce-back effect patent, which is even sillier than the slide-to- unlock one. The main problem by far is still having these patents granted in the _first place_ , and then either having multiple companies getting harassed by others to pay them money for the bogus patents (like what Microsoft does) or spend millions and years in Courts to resolve just a handful of them.

Sounds like a terribly inefficient system to me. Not to mention that because the US Patent Office has such low standards for accepting patents, that also means lawyers will file just about any crazy idea they can come up with, backing up the USPTO for 4 years.

If the USPTO took a stance to reject 80% of the filed patents while still charging them a few thousand dollars per application, I think the quality of the patents would significantly improve in a few years. so if there are some good patents in there, perhaps from a startup, that startup will have to wait 4 years to get it. That sounds like ages for a small company and it could be long dead by then, especially if it doesn't get funding because of the lack of an approved patent.

[http://www.macworld.com/article/2042023/apples-crucial- overs...](http://www.macworld.com/article/2042023/apples-crucial-overscroll- bounce-patent-claim-is-valid-us-patent-office-says.html)

[http://www.zdnet.com/article/apple-bounce-back-patent- declar...](http://www.zdnet.com/article/apple-bounce-back-patent-declared- invalid-in-germany-thanks-to-steve-jobs-video/)

<comment><USER14> I remember watching the original iPhone presentation thinking "this looks OK but touch screens suck" then having the UI-design-oriented part of my brain completely blown by the bounce-back effect. No other touch screen software worked that way and it is hard to think of something physical that bounces like that (unlike the swipe-to-open metaphor).

I am not a lawyer and I have no opinion on the validity of the bounce-back patent (although the German court rejected it based of publication date rather than merit), but from a business point of view I can see why Apple was so keen to hog bounce-back for itself. I didn't buy a iPhone for a few years but they won a customer that day.

<comment><USER15> >it is hard to think of something physical that bounces like that

Have you never quickly opened a drawer with stuff in it?

<comment><USER16> I think a better example would be a drawer with rubber stops that causes the drawer to bounce back if you open it too quickly.

Or a door with a rubber stop on the wall. Or even a door with a soft spring that prevents it from opening too far.

Or a car with good bumpers.

Or a chair that springs forward if you rock back too far.

Or bungee jumping.

Nope, can't see any evidence of that action in the physical world at all.

<comment><USER14> Good examples, but I would be willing to bet that at some point all those things have been covered by different patents. The company who patented a chair rocking mechanism would not be affected by the inventor who made a door with soft springs (although I have never seen a door that works exactly that way).

<comment><USER17> The difference is that those patents would cover the specific mechanisms by which the bounce-back effect was achieved. In this case, the Apple patent covered the bounce-back effect itself, _without regard_ to the code or other specific mechanisms used to achieve the effect.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> This is long overdue. As is invalidation of the bounceback patent. Like so many of "designy" patents, there's quite a bit of prior art.

The whole "but on a computer" patent needs to go away. "Sliding a latch from one position to another to open but on a computer" should not be patentable.

</comment><comment><USER19> Well in EU some algorithm is surely patentable if it has a "technical effect", for instance if you can move a robot arms consuming less energy or producing less waste materials, it must have a physical impact on something. Quote: "the method didn't reach a level of sophistication needed to award patent protection", just this, lol at patenting it in the first place.

<comment><USER20> I feel it would be easy for Apple to argue that is does have a physical effect - it makes it easier to access a locked phone than having to enter a pin, or one of the many other methods of unlocking electronic devices.

<comment><USER19> It is not saving battery, it is not producing less waste.. so no, it has no physical effect. As an algorithm it cannot be patented in the EU, and code- wise in EU it's the only thing you can try to patent.

<comment><USER20> It's making life easier for the user... this is one of the primary things that patents are here for, inventions which make life easier. And it's certainly not what would be considered "an algorithm" by any patent office - it has user interaction, in involves hardware, it is clearly not just a mere algorithm.

</comment></comment></comment></comment><comment><USER21> " _The contested patent thus isn't based on an invention._ "

It seems there are more patents that fill this description.

</comment><comment><USER22> Interesting that the article doesn't mention that there is prior art, which was discussed in court, in the form of the Neonode N1m.

<comment><USER23> The true prior art is the door bolt. Slide to unlock. Bringing the same method and procedure to a phone or car shouldn't warrant patent protection.

</comment></comment><comment><USER24> _Judges on Tuesday said that the iPhone maker's method didn't reach a level of sophistication needed to award patent protection_

Just so I understand what happened, can someone summarize German patent law? Is it the same 3 tests as in the U.S., i.e. statutory, novel, non-obvious?

</comment><comment><USER25> I'm waiting for a future where we can ask a "blank" AI to come up with trivial solutions to new problems, so that we can just invalidate such stupid patents. If the AI can invent it, it is not worthy of a patent.

<comment><USER26> UI stuff is _not trivial._

Simple != trivial. The art is in designing a high quality experience, not in solving a programming problem.

Look and feel is a very real and valuable thing in the marketplace. The big differentiator between Apple and everyone else is that Apple pays attention to - or used to pay attention to, anyway - the user experience,

The code behind the experience was always secondary to that. Users don't care about it, and they're completely fine with not caring.

I agree that there are limits, especially when there are patents on rounded corners or specific English words.

But generally if there's innovation in the user experience on a screen it's potentially patentable, even if the code behind it is trivially simple.

AIs have no concept of user experience, so it's unlikely you'd get much of marketable value out of one.

<comment> norea-armozel It's more that AI can't be taught aesthetics since for most people it's a "I know it when I see it" sort of thing. Very few people can turn that into a talent like Scott Forestall. We're probably at least a century away before we can get an AI to work at that level of abstraction.

</comment></comment></comment><comment><USER27> I don't get how this was a patent to begin with. The door in my room has a "slide-to-unlock" lock that dates back 50 years. Surely Apple did not invent this.

<comment><USER28> I think it is a mistake to suggest that slide to unlock on a touchscreen and a sliding bolt are the same concepts. The important thing as I see it is a way to change a touchscreen from a state of "unresponsive to input" to a state of "responsive to input" by requiring a very restricted set of inputs to be entered. "Swipe to unlock" is just one (pretty good) definition of this restricted set of inputs. I think this is quite conceptually different from a physical lock unlocking a physical door.

<comment><USER29> Don't know the technical terms but how is "unresponsive to input" when you can interact with the lock screen. For example swiping/expanding notifications, change songs, etc. For me "unresponsive to input" to a state of "responsive to input" would be the power/home button let's you interact with the screen.

<comment><USER28> Fine. Change "unresponsive to input" to "unresponsive to all but a very restricted subset of all possible inputs".

</comment></comment></comment></comment><comment><USER30> Pretty obvious this was going to happen. Pretty much the only software that is patentable in Germany is stuff that controls physical machinery of sorts (embedded break controls or something). Control of forces of nature to cause an expected effect is what qualifies. "Technizität" (technical character) is what it's called. It's one of the four criteria. The other being it has to be "new" (no prior publications including your own), marketable (no clear cut criteria) and an invention (an "imaginary expert in the field" can't come up with it, also pretty debatable).

So technically not much really qualifies. [IANAL]

</comment><comment><USER31> I don't think "obvious in retrospect" is a fair criterion for invalidating a patent. Those are actually the most valuable patents. The safety pin and the catseye (road reflector) were both patented and made fortunes for their inventors (or in the case of the safety pin the company that bought the patent).

Now arguing the whole patent system is fucked up is perfectly fair but we shouldn't celebrate a legitimate, non-abstract patent being incorrectly invalidated.

<comment><USER32> It doesn't say that in the article, what are you basing it on?

It says that it wasn't sophisticated enough. Safety pins and cats eyes both require sophistication in their construction.

<comment><USER31> I should have been clearer. Their definition of "sophistication" is arbitrary and effectively amounts to "obvious in retrospect". Safety pins and catseyes aren't more "sophisticated". The inventor of the safety pin made a working version in a few minutes. Differentiating an intentional slide gesture is actually much more _sophisticated_ than bending a wire or mounting a reflector on a piece of rubber.

</comment></comment></comment><comment><USER33> Good. Such stuff should never have been patentable to begin with.

</comment><comment><USER34> Glad to hear it, Apple's been going stupid crazy with this patenting lately.

<comment><USER35> Lately? Like 2015?

<comment><USER36> Last week of August 2015

</comment></comment></comment><comment><USER37> does the patent say it actually has to work? XD just saying...

i'm always in two minds about this but i lean very heavily towards culling people who think this sort of thing should be patentable. i think it would benefit everyone for the entire future mostly...

</comment><comment><USER38> I can't imagine tim cook losing any sleep over this. Most users unlock their phones via touch ID (fingerprint) these days.

<comment><USER39> Still shows "slide to unlock". Which you can do and enter pin instead of using fingers (or tongue if you were bored like me).

Also there's still iPhone 5C(heap) phones in production which don't have fingerprint reader.

</comment></comment><comment><USER40> Ha! I just used a cheapo off the shelf website that featured slide to unlock on web forms for spam prevention. Not posting the link because I don't want Apple breathing down their neck.

</comment><comment><USER41> I'd say "good riddance to bad rubbish" but this is just one of a million nonsense patents that are uselessly being applied to transfer wealth upwards. Why, humanity, why? Why do we continue to hang ourselves with these thin fictions?

Our property concepts are fundamentally broken. Copyrights, patents and especially real estate are all flawed concepts that privilege their owners far more than they should. But we allow them to persist for centuries; then we wonder why society is fucked and some people have all the wealth.

<comment><USER42> What's wrong with real estate?

<comment><USER41> Arbitrary titles granted to someone that allows them to control a piece of the Earth in perpetuity? That doesn't strike you as a recipe for disaster and inequality?

For a full answer, try: "Progress and Poverty" by Henry George.

<comment><USER43> I feel we're mixing too things now. There's control of land, and there's ownership of land. Control of land is mainly obtained by conquest and occupation, that's to say physical dominance. Titles are usually obtained by persons that attained this dominance, so that's hardly arbitrary (nor very perpetual though that may often seem so). This is nature.

Ownership is the fun stuff where you pay money/goods to the previous owner (who might very well be (a descendant of) an oppressor). In exchange for rights of exploitation (i.e. living on it).

It's not the titles that make real estate unfair, it's nature itself. That's why an egalitarian society can not be like nature but must instead be governed by rules and regulations. This is why democratic socialism is superior to libertarian capitalism (at least when we're talking equality and 'fairness').

<comment><USER41> Fairness is a human concept, as are land titles. If the latter are unfair we can't blame nature.</comment></comment></comment></comment></comment>


The U.S. Can Get Julian Assange - <AUTHOR> https://www.wsj.com/articles/the-u-s-can-get-julian-assange-1495403122?mod=e2tw <comment><USER2> So the WSJ seeks to bring the 4th estate under control of the other 3?

Below pathetic. Law and (dis)order above all.</comment>