Desktop software dead. Software exists only on the internet. Browsers evolve into application runners.

Thin fucking clients.

Commercial CNC machines and other motion control applications will _never_ run off of web-based software. Not to say it isn't possible under the right conditions, but those conditions can't be ensured. There will always exist applications that require low response times that the internet cannot dependably deliver.

High end CAD and CAM software also falls under this umbrella. There is simply too much computation/rendering occuring.

no,the OS you'll be working on will be designed so it will be harder to tell wether you're using a webapp or a native app.

I don't know if your solution is correct. Many functional abstractions in Haskell, such as those that involve high level typeclass abstractions, make code more esoteric, and not more clear. However this is a tradeoff to make code more based in algebra and logical structure. This is more important than readability and conciseness.

There is a very strong argument that you shouldn't be using the high-level esoteric typeclass abstraction in Haskell, or even that you shouldn't be using Haskell for production programming. I say this as someone who likes Haskell a lot and wrote one of the top tutorials on the web for it. But if you run a business based on software, and your core value proposition is not the 100% provability of your code (eg. Galois), then readability and conciseness are absolutely more important than algebra and logical structure.

Very fair point. Thanks for replying.

This article conflates abstraction with OO and language features, IMO.

Putting some functionality into an object is not as interesting as running that functionality as a monadic command.

Would be more interesting to run some benchmarks in Haskell using functional abstractions rather than OO machinery.

Just use protocol buffers. This can't really be a serious competitor to json/thrift/protobuf with no benchmarks and only a python client, sorry.

Your comment would be so much better without the condescending "sorry" at the end. You're in a public forum airing your opinion, not rejecting an application for something.

Sorry

This isn't about web design. You should just add links to these articles on the article you submitted. Good for google ranking, increases the chances of someone reading them, makes user happy :)

.NET supports awesome meta-programming. CLR allows for some very dynamic types and programs.

I quit Chrome and turned off my computer after reading that sentence.

Meh. NgAnnotate is way better than duplicating code. Be DRY, not pedantic.

Something we are looking to change. The duplication is pretty annoying, but we use AssetGraph-Builder for our production build, which uses ngmin, which doesn't play nice with ui-router. Also, now that 1.3 errors globally when you forget annotations, using NgAnnotate is much more of a no-brainer.

I have heard that it has trouble working in a complex build/development environment, e.g. when watching live file changes* with gulp/browserify.

*) https://www.npmjs.org/package/gulp-watchify/

Hmm. There are no open bugs for that on the gulp-ng-annotate or browserify-ngannotate repos. https://github.com/Kagami/gulp-ng-annotate/issues and https://github.com/omsmith/browserify-ngannotate/issues

Feel free to open issues and I'm sure it will be addressed.

ng-annotate itself just produces output for input (stdin/stdout or via files) so it does not at all have any trouble participating in a "complex build environment".

I switched from ngmin to ngAnnotate+uglify. Man this is way faster! Also code looks much better!

Internet high-five!

Try searching through a book vs. search for a tag within your tagged collection of data. It's a way more logical structure on the digital side.