Just as enterprise frameworks tried to encourage and codify best development practices a few years ago, nascent languages aim for the same on the JVM and the .NET runtimes. The JVM, in particular, has seen a proliferation of alternate language to Java, running the gamut from the highly type-safe and statically-typed Scala to scripting languages, such as Groovy and JRuby.
Noop is yet another JVM language that, according to the project's documention, aims to:
Syntactically encouraging what we believe to be good coding practices and discouraging the worst offenses.
Noop's creators found that the root cause of many poor coding practices were poorly designed language features,
In analyzing this problem, we found that the root cause in many cases was language features - like globally visible state, misused subclassing, and API's that are easily misused. Noop will try to avoid these problems...
Noop is a new language that will run on the Java Virtual Machine, and in source form will look similar to Java. The goal is to build dependency injection and testability into the language from the beginning, rather than rely on third-party libraries as other languages do...
Immutability and minimal variable scope are encouraged by making final/const behavior the default and providing easy access to a functional style. Testability is encouraged by providing Dependency Injection at the language level and a compact constructor injection syntax.
What do you think of Noop's goals? And, with an increasing number of JVM languages to choose from, what motivates you to learn a new language that runs on the JVM?
This seems like a mostly pointless language. It claims to reduce typing and yet still forces you to add semi-colons. And, as if that weren't taking the mickey enough, it's a language built upon Scala, which is arguably easier to write in and has less typing.
If it weren't for the project being hosted on Google Code, chances are, no-one would have heard of it. It has no value-add over any other language, nor over the language that it's built upon.
I must admit to some trepidation when I hear about any language that includes Oracle's JVM as its base requirement; given that there will be little or no involvement from Oracle with the language development and correspondingly little influence upon the JVM by said language developers.
Whilst it has many short term advantages, it just seems like a significant weakness in the long term.
Every new pilot project will look pointless if you look hard enough in that direction. The same was said when Java came up, and the same was said when OOP came out, and so on and so on. Had we been inclined to think that way in general, we would still be doing COBOL... or worse.
There are some valid concepts to be explored here. Immutability by default, unit testing and DI as language constructs. It might fly or it might not. No way to know until you try.
> It claims to > reduce typing and yet still forces you to add semi-colons.
I'm not sure what it is about obligatory semi-colons that runs counter to reducing typing. AFAIK, the bulk of reducing typing has more to do with strategically reducing boilerplate code than to save an extra character or two per executable statement.
> And, as if that weren't taking the mickey enough, it's a > language built upon Scala, which is arguably easier to > write in and has less typing.
And yet, Scala came up as the result of the same type of effort, of investigating certain features in a new language. That's how Scala came to be. That's how javac and java Generics (via Pizza) came to be. That's how almost every piece of technology (good or bad) came to be.
> If it weren't for the project being hosted on Google Code, > chances are, no-one would have heard of it.
If it wasn't because Sun was publishing Java (Oak) back in 1995, chances are no one would have known about it. Non sequitur dude.
> It has no value-add over any other language, nor over the language that it's built upon.
Exploratory work on immutability by default and DI/Unit testing as language constructs? They have no value added on? Not worth exploring?
This looks like a 'yet-another-lang' superficial rant than an actual, objective analysis.
The language might be garbage in the final analysis, but the problem here is that you haven't done any analysis at all.
> I must admit to some trepidation when I hear about any > language that includes Oracle's JVM as its base > requirement; given that there will be little or no > involvement from Oracle with the language development and > correspondingly little influence upon the JVM by said > language developers. > > Whilst it has many short term advantages, it just seems > like a significant weakness in the long term.
Hi, I was trying to find any link indicating that this new lang requires Oracle's JVM, but couldn't find any on its google doc site. Do you think you could post a link to it?
If it indeed it is intrinsically tied to the language, that *might* be a problem, depending how you look at it.
Jrockit JVM is a fine piece of software. I was very impressed when I saw several installs of JBoss running on it. You could use different tools to take a peek at the running JVM and monitor its statistics (I/O, memory usage, etc.) That is invaluable from an operations point of view.
You can do that with other JVMS, but with Jrockit, it's a breeze (time saved == $$$ saved.)
So I could see why - if it is true - this new lang is being shipped or build on top of Oracle's Jrockit.
Also, it should not be that much of a problem to use a custom VM (like Erlang and Ruby do). It might be a problem in terms of licensing if it is a proprietary one like Jrockit, though.
Previous Topic
