So modern Chinese consider their country to have been stagnant during the entirety of the Yuan, Ming, and Qing dynasties? I've read a number of Western books about Qing-era China trying to understand the same questions the linked article discusses - why China doesn't already rule the world. The way things are presented, the Qing rulers and court just seem to be generally incompetent and isolated from their contemporary reality.
So within China the understanding is that the problems go back to before the Qing?
Calling the JVM platform a relic is a major mistake - the number of businesses that rely on the platform is massive.
However Java-the-language has been stagnant since Java 1.5 in September 2004. The Java API has had some changes but the language has remained mostly unchanged. The 1.8 version promises some nice improvements inspired by FP languages. Unfortunately, 1.8 has been continuously delayed with a current release date of sometime in early 2014. For JVM developers who care about their productivity, moving over to languages such as Scala, Groovy, and Clojure is the only sane choice.
Java fills a particular niche (code with an emphasis on readability) which is not addressed by Groovy or Clojure and arguably not addressed by Scala. I'd say Go is the biggest competition for that niche as a language, although it's not JVM, it does fix many warts with how Java handles inheritance/polymorphism without sacrificing readability and simplicity.
Groovy is slow as a 1-legged dog. (we use it to fill the shell/perl niche a lot but it is slow, effectively you're doing reflection lookups every time you call a method in Groovy). The dynamicness makes it better for scripting or web programming, though, where you don't care as much about performance.
Scala is the JVM's C++, a giant pile of overlapping features, supported by an advanced and very slow compiler that yields fast bytecode. Case classes, funny operator overloading, lots of additional syntax for collection manipulation. They're giving you more expressiveness at a cost of readability and language complexity. (This is an opinion, some may disagree).
Clojure is really awesome but most dev shops will have an easier time with imperative programming models.
Ultimately, not changing in 8 years isn't fundamentally bad, and Java isn't that bad at all as a language if you avoid things like EJB and Hibernate, and if you're not looking for a dynamic language like Ruby and dissapointed by Java not being Ruby. You might just disagree with the tradeoffs.
For me its a benefit, why would you want your language/core api changing all the time? Thats how you end up with certain unnamed languages that have fallen out of favor. Java the language tries very hard to not be redundant in its feature set, so the path to usage is clear.
I think Java suffers from too many search results (yes thats a thing). I suppose if you want to learn Java today you simply google it, and find tons of people trying to solve the N+1 hibernate problem on stackoverflow, or some other common annoying enterprisey issue, and so you start reading up on JCPs and EE apis. If that is your introduction, I can understand why people end up going "what is this shit?". The reality of course is that there are many subcultures within the Java community and that many of them are anti cruft api as well which is how innovation comes to the Java world.
Yeah, a good rule of thumb is that if something was specified by a JSR, it's probably shit to work with because of all the competing corporate agendas that went into it.
I'd argue Scala is much more readable than Java with some effective practices. Type inference (where appropriate) cuts down on distracting text, operator overloading is great when used judiciously, for comprehensions, etc are all great features.
Just because Java requires explicit typing all over the place does not make it easy to read, especially when I'm trying to decipher what the ResourceBuilderFactoryFactory class is doing in my enterprise grade codebase. There is cognitive load in parsing tons of text to express simple concepts, just as there is cognitive load in deciphering a bunch of random symbols doing something complex. Scala with discipline lets you choose somewhere in between; Java gives no choice.
For startups with small, disciplined teams, Scala is manageable, sure. But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off. Maintainability is THE great equalizer.
> But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off.
That has nothing to do with language; Java for which development is outsourced and maintenance goes in house is pretty much a nightmare, too.
But that's pretty much a "myopic development practices -- including outsourcing development of code you are going to need to end up supporting in house -- will blow up in your face problem", and not an issue relating to any particular language or platform.
Chances are, if you have the authority to make enterprise-level language/platform policies, you also have the authority to make enterprise-level decisions on whether and when to outsource development of software, so it makes sense to just do the latter right than to make an otherwise second-rate choice on the former to make up for doing the latter poorly.
It's my personal goal at the current company I'm at to see Scala grow to be respected as an "enterprise" language. The startup where I learned Scala had a small disciplined team with lots of mentorship that meant almost everyone developed some very good Scala practices.
If code is becoming unmaintainable because of outsourced development, does that not have more to do with how we communicate to these external developers? Bad code is bad code in any language.
I'm curious to know if Groovy 2.x (with strict/static compiler pragmas, er, annotations) is slow relative to regular Java lang code. I know Grails doesn't use the strict mode stuff, but for hand coded "hot spots", how does Java vs Groovy 2 compare?
Hmm. Interesting. I recently incorporated Groovy into an existing legacy (web) app. As the app is still under Java 1.5, I could not get the static/strict stuff to work - it needs 1.6 or better support.
So, there's consensus that this feature is not ready for prime time? (I don't want an answer from people who hate Groovy in general)
> So, there's consensus that this feature is not ready for prime time?
Best wait till Grails trusts the static enough to use it before you do.
> I don't want an answer from people who hate Groovy in general
I love the Groovy Language, but the current PM made some bad decisions after taking over, e.g. removing Poirier's Heredocs, disabling Scala-like catchless try statements, laundering Tkachman's Groovy++ static-typing plugin, stonewalling on Wilson's MOP upgrade, scuttling any attempt to spec the language, the horrible paren-less DSL syntax for multi-arg function calls, removing Closure Lists just before an RC release without any public discussion, how Strachan the founder was knifed over dynamically-scoped closure syntax at Devcon 2, how Java 8 lambda retrofit hasn't even been begun on, instead the PM is wasting time on non-Java compatible traits to Groovy, etc.
I still love the essence of the Groovy Language, tho, that's why I'm rebuilding it atop Clojure.
Java fills a particular niche (code with an emphasis on readability)
I'm a bit skeptical of this claim. While Java does remove many of the opportunities other languages provide for making a small piece of code do something unexpected, I've found that Java's verbosity makes it hard to see the big picture.
Of course, good programmers manage in spite of any limitations of the language, and bad programmers manage to write incomprehensible code no matter how much a given tool tries to guide them in the right direction. I suspect it will always be this way, and that's not a bad thing.
Groovy's niche is supposed to be the same as Ruby or Python - if you want high performance, it's not the way to go. I've done a lot of Groovy for simple web applications and it works very well.
You don't have to use funny operator overloads if you use scala! Making your code readable in that language is definitely up to the developer.
Clojure can be exactly as fast as Java within a function when type hints are used to avoid reflection. Calling Clojure functions has a little overhead relative to calling Java methods.
That said, an idiomatic system in Clojure will likely have a very different design than it would in Groovy or Java. Using Clojure's built-in immutable data structures, it's cheap in terms of CPU and memory to make a large number of modified copies or to concurrently access data compared to the standard collections in Java and Groovy. Single-threaded reading and writing are, however somewhat more expensive.
My prediction is that it's easier to get good performance out of a system with a lot of concurrency using Clojure than it is with Groovy or Java, though with careful design, it's possible to get better performance with Java.
Actually, Scala core is pretty small. What you think as operators are methods. What you call case classes is pattern matching , one of the most powerfull feature of Scala along with Actors.
> lots of additional syntax for collection manipulation
Actually using collections in Scala is far more easier than in Java
And i'm not even talking about XML parsing... where you would write 30 lines in java you'll write one liners in Scala. Guess which one is easier to read...
Scala promotes immutability that make code sane.
Scala promotes recursion over loops that makes the code elegant.
Scala promotes experimentation through its REPL.
Scala saves you writing 75% of the java boilerplate, thus promotes maintainable applications.
Scala looking much like Java is a deception but also an necessity for compatibility which Java libs. but the syntax has a total different meaning . That's the genius of Scala. Scala is the guy looking outside the box when Java is trapped in Cargo Culting.
This post comes across like you're incredibly ideologically invested in Scala. I'd suggest that 'the future of computing' in any dimension will take a lot more from practicality and a lot less from theory or ideology.
Specifically, the point about encouraging recursion for more 'elegance' kinda bugs me there. Recursion is more of a natural fit than loops when walking a tree or graph, and is less so when iterating a list, set or map. It's about practicality.
If you're very interested in aesthetics, you'll never like java or even not-hate it. And that's ok.
> Scala looking much like Java is a deception but also an necessity for compatibility which Java libs.
The fact that Scala can look a lot like Java is more for compatibility with Java devs; the code could look a lot different (and idiomatic Scala does) and still be compatible with Scala libs, but supporting code that is familiar to Java devs eases the learning process and encourages adoption.
Many of the productivity features we're talking about (e.g. lambda) were originally supposed to be in java 7, so have already been delayed multiple times.
That's a little generous. Clojure is great and I enjoy working with and Scala is fun too, but Java still has the best tooling support. Scala IDE has weird little bugs here and there whereas I haven't encountered a JDT bug in years.
I use Eclipse for all of them Counterclockwise, ScalaIDE and JDT. Counterclockwise is actually really nice. Selecting forms is super simple and makes the parenthesis "issue" not a thing.
It's a shame there isn't an "employable" choice of language platforms somewhere between a GC-ed language and C.
The JVM has an exquisitely tuned GC, but any GC still comes with a cost. But do I have to use a language with no safety features at all if I opt for other non-GC languages?
(I'm of course thinking of something like FreePascal, but there must be a number of good middle-ground alternatives that are being ignored in the work-place, which would easily write less hardware-hogging code)
I would not have thought the above comment was offensive. Perhaps somebody doesn't like having his/her choice of language questioned??? (whether it was Java, or C, dunno)
> moving over to languages such as Scala, Groovy, and Clojure is the only sane choice.
Anyone who mentions these three languages in the same breath is regurgitating the marketing talk for one of them. The article doesn't make that mistake, so could actually be genuine research rather than some PR drivel from some corporate Product Manager.
That's a great conspiracy but I'm not sure those folks have that much market share in the grand scheme of things (and it's possible liberal groups are doing the same thing). I don't know how many news site comment sections you tend to frequent, but I feel like I've seen just as much "dumbed down" liberal "trolling" as the reverse.
Obviously both sides will do it! I'm trying to offer an explanation as to why such nasty stuff will show up on news sites - political actors are paid to promote their viewpoints.
"This story is a great demonstration of my maxim that any headline which ends in a question mark can be answered by the word 'no.' The reason why journalists use that style of headline is that they know the story is probably bullshit, and don’t actually have the sources and facts to back it up, but still want to run it."
In the situation described by the article, the changes in gene expression are happening in the rat's brains. These changes aren't going to make it into the rat's gametes.
Politics is unworthy of discussion yet an article like this is acceptable? If Javascript is making all other languages irrelevant why does the world have Coffeescript, Clojurescript, and so on and so forth?
The argument is "You must master javascript". If other languages compile to javascript - then you needn't master javascript, you can master those other languages.
So no, this does not just support this argument. There are other languages to learn.
When Steve wrote this article, his point was Javascript or anything that creates Javascript. Or actually, we don't even really care about Javascript, just the portability and qualities we get from it and its derivatives or offshoots. Another suitable title would be "Server side only thinking is dead".
