I've seen several proposals, such as making patents non transferable, shortening their life time or not allowing cases to go to court unless you can prove your business depends on that patent.
> Circles are ok to set up at the beginning, but many people belong in more than one circle and it gets cognitively tiring to sort people appropriately into one-and-only-one circle.
A person can belong to more than one circle (that's why you have a list of checkboxes, one per circle).
Look at the position of Javascript. It's fair to say it's used exclusively for web development (node.js is quite marginal) and it still tops the job chart.
Ruby on Rails would be there as well if it were mainstream.
entries = new ArrayList<Integer>() {{
add(3);
add(4);
}}
But yes, certainly not as elegant as Scala. Having said that, you don't encounter literal collections very often (except maybe in tests).
6) Named parameters are pretty easy to emulate:
new Window().width(100).height(50)
although the builder pattern is safer:
Window w = new Window.Builder().width(100).height(50).build();
7) No more checked exceptions: celebrating this is like saying that your code is shorter because you no longer bother checking for errors.
8) You can only omit parenthese in Scala when there is exactly one parameter:
x.foo a <-- legal
x.foo a b <-- illegal
x.foo(a, b) <-- legal
One of the many syntactic quirks that Scala suffers from
9) Comprehensions are neat but they suffer from a crippled performance limitation that forces you to revert to imperative loops, even in optimized mode. This technical problem is serious and there is no solution in sight at the moment.
There are genuine reasons to be excited about Scala but this article makes me think that the author just discovered Scala and they haven't really dug very deep yet. When you do, you start realizing that Scala's nice features are offset by quite a few annoying limitations that will probably doom this language to a niche.
> entries = new ArrayList<Integer>() {{ add(3); add(4); }}
Nah, entries = Arrays.asList(3, 4);
Scala is pretty sweet with a lot of syntactic sugars, but it still it doesn't fundamentally make writing correct code any faster, especially for Java developers who are competent with their IDEs. Until Scala's compile time and IDE support improves 10x, I see no point of using Scala for production code.
Slightly more verbose Java syntax is more than made up by the instant/incremental compilation/autocompletion/refactor that works. Even as a Java noob (I'm more experienced in C++), I can bang out correct code the first time without going through any edit/compile cycles, most of the time. IDE is the new REPL and language snobs always forget that.
1) There is a literal syntax for Java:
entries = new ArrayList<Integer>() {{ add(3); add(4); }}
Unfortunately if you have warnings turned on in your IDE, it will complain about the lack of a serialVersionUID on your new class. This can be worked around via the `@SupressWarnings("serial")` annotation, but that hurts overall readability & code line count. That makes this technique less of a win than it would seem.
1) That is probably quite slow since you're creating a new class not just a new object.
6) Sure, now let's see all the boilerplate builder code you need to need to make that work.
7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.
8) Doesn't look like a quirk to me. Looks pretty straightforward.
> 7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.
These clauses allow static verification. In other words, the compiler will remind you to handle the error cases.
If you fail to do this and the compiler doesn't nag you, you can bet that most developers will never bother doing it.
re 1. "create a new anonymous class with one instance and run this when initialising and by the way it's all in one line" is hardly "literal syntax".
re 7. They're ok as long as they're helpful, but at the same time they prevent writing something like useful `map()`, unless it throws everything. How many times do you need to catch something and handle, even though the situation can never happen? (as in - code doesn't throw the exception, but interface says otherwise) How many broken functions, like throwing `sleep()` are there? How many times do you have to write catch / finally / catch / finally / ... when closing more than one resource reliably? And it still doesn't protect you from silly null mistakes. I believe that properly using Option and matching will prevent more errors than checked exceptions ever did... (I may be wrong of course)
Technically, (my interpretation is that) it abstracts your application from your db. The ORM acquires the data, allowing your application code to concentrate on using the data.
All the frameworks "are growing up", this is nothing to be proud about. The real question is: is the framework becoming mature?
Because RoR has this tendency to reinvent itself every 18 months or so, the answer to the question is a resounding no. It's being used mostly to explore new ways to create web sites, but RoR is more and more becoming a framework you really want to avoid if you need to create a production site that you are planning to work on for years to come.
Let's talk again once the owner of the patent successfully sues over it, making millions in the process.
Never going to happen.
Software patents are not the problem, patent trolls are.