Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing(gridgaintech.wordpress.com) |
Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing(gridgaintech.wordpress.com) |
If 1/100th of the VC money going into social startups would go into actual technology companies, if it were an accpeted business model to sell (maybe read-only open source) technology for money, then the tech landscape would be totally different.
TL;DR: to replace Java, a lot of directed professional development effort would be needed: money would help a lot.
Not all languages came that way, but some of the major ones did: C was Bell Labs, C++ was also Bell Labs, Smalltalk was Xerox PARC. The main contemporary example in that vein is probably Go coming out of Google, though it remains to be seen how mature and widely used it'll get. For compiler projects, V8 coming out of Google and LLVM now being funded by Apple are two examples. Java is an example developed by a company with an eye towards product/monetization rather than as a research project, but is probably these days seen as a cautionary tale of why not to approach PLs as a business opportunity, because Sun pretty convincingly failed to monetize it.
There may be some social bias against paying for stuff, I think partially because people got burned with vendor lock-in. Technology changes so quickly, it's hard to know what a tool is worth before the fact.
But there's also a very real economic reality at play here. The most valuable platforms will be the ones with the most people collaborating on them, and that's always going to be the free or open platforms.
As you move up the infrastructure chain, I think people are more willing to pay for useful libraries or services, especially for ancillary stuff. But what rational person would build their business on something they didn't own?
http://www.scala-ide.orgSounds a bit like you used an old version ...
Of course Java will always be around because it's easy to learn(I earn my money with it BTW) and it protects you from all kinds of stupid errors that newcomers could do in C , C++ or Javascript (memory management, Static Typed, etc...) but Scala provides a very flexible way to code a way that most Java devs are not used to, and therefor it takes a while to learn, but when you do learn it's a Joy I am a proof of that I really like coding in Scala while java is like my work horse, scala is what I use for my fun coding.
BUT... as an young language it have some major drawbacks, like lack of a proper IDE, slow compiling time, lack of Frameworks, lack of documentation and so on... but I am really happy to see Typesafe writing the problems down and fixing them when possible, it will take a while but when it's done it's going to be a very good language to know, and they are slowly I agree but fixing it.
anyway i'm very sad to hear about current situation. i've been secretly wishing scala will become big.
I had been thinking of Scala as though it was Java++ (in analogy to C vs C++): a language that adds a few features on top of Java for better abstractions, but regular Java programmers can basically program Java in it (and read it as though it was Java). However, it seems like truly idiomatic Scala code involves heavy use of advanced functional and type system concepts that cannot simply be glossed over.
Will Scala and/or Clojure end up as languages in the JVM used by a small number of senior developers to be more efficient on particular problems (like F# on the CLR) rather than the next big language used by everyone (like C++ superseding C for most problems)? And, is that an accurate portrayal of how F# is currently being used?
Probably all "alt.java" tech will remain somewhat fringe, simply due to inertia. And although I wasn't in the Groovy community at the beginning, I do think that Groovy, in some small part, helped further along the "non Java on the JVM" story, giving people solid examples of using alt.java languages without having to leave the JVM altogether.
"Ridicule about parallel collections in 2.9 (one of its major new features)"As one guy put it, the collections do nice work but you have to know what you are doing (not all work can be broken into fragments that can be computed in parallel). He was kind of expecting otherwise.
Not saying they are perfect, just what happened (more or less)
Having a lot of those sorts of comments I don't think will guarantee future success.
My fear is that if things don't change, Scala will fall into a perl-like situation where it won't be able to shake its reputation and people will reject the language out of hand before taking a look at what it has to offer.
But even if it's only to spew hate, the fact that so many people talk about it, must mean something. Too much attention for a fringe language...
Do you have a link? Maybe this unhelpful behavior can be figured out in person.
I always experienced the Scala community as a very friendly and helpful one, focused on getting stuff done.
Imho the talk about “bad behavior” outnumbers the actual occurrences of bad behavior by a few magnitudes.
http://blog.joda.org/2011/11/scala-ejb-2-feedback.html?showC...
I don't question the intent of the Scala community. There's no mystic group of evildoers there trying to degrade newcomers. But the mailing list is very intimidating. It doesn't feel like a place where newbies can come in and ask "How do I do a 'foreach' loop?".
And those were not written to be used with Scala.
After several 90+ words paragraphs I found this 138 words beauty :D.
" Maro 321 days ago | link | parent | on: "Nothing like this will be built again": a tour of...
When I was getting my degree is Physics we had a lab in the "student reactor", which was still in a large building of its own. As part of the lab we got to sit down to the control console of the reactor and control it, on our own. I remember I was turning one knob increasing the power output when suddenly there was a loud noise, everything shook, and the power output went to zero. Turned out it was the failsafe (I think cadmium rods dropped into the core) as I was too agressive with the controls --- it was a normal occurence for students. (All modern reactors are designed in a way that you can't overdrive them, they'll automatically shut down.) It was great fun and a story I'll be telling for the rest of my life. "
P.S: I didn't count the --- as a word !
That said, I've got Grails apps running in production just fine, and to whatever degree noticeable speed is an issue, it's almost always down to database indexing.
As Hamlet said, I don't think execution speed is the primary reason people aren't using Groovy. Personally, I think all the "alt.java" languages are fighting for attention from the few people left in the Java/JVM arena who are truly interested in exploring new ideas/techniques. Many Java devs who were interested in getting better years ago left for other platforms, (and many of those people will likely jump to new platforms every few years out of curiosity more than anything else).
If that were true, then I think JRuby be more popular. It is faster yet remains dynamic. There are various efforts to make Groovy fast, but the ones I have seen require you to turn off some of the metaprogramming capabilities.
I used Grails for a project four years ago - I think it made a lot of sense then. We wanted a simple web UI for something that needed to deeply integrate with some java libraries. We had just done a relatively simple UI with Spring and it was pretty amazing how much better it was to work in Groovy.
However, these days I don't see why anyone would pick Grails over Rails. You can deploy rails on the jvm just fine, and it's much more mature. There are tons of tutorials and example code out there.
It's not a performance thing - it's just that ruby/rails is pretty mature now and runs on the JVM very well.
I wrote a web service that read and processed XML documents. They were large, but not enormous... Couple hundred kilobytes, usually. My first cut, using Groovy and its built in XML DSL, took up to 15 seconds to process a single document. Rewriting in Java/StAX, it was a couple hundred milliseconds.
From then on, my MO was to write my code in Groovy and then rewrite anything that got called more than a few times per request/run in Java. Groovy's fine for glue code, but its performance was a real barrier to regular use.
As for JRuby, I suspect it's because no matter how good JRuby is, it's a second-class citizen to "real" ruby in the Ruby ecosystem, and to built-for-the-JVM languages on the JVM side. It's a great product, but it does have a few impedance mismatches coming from either side.
It's better than JSP, clearer and simpler syntax, better support for componenization with shared tags, layouts, and includes.
I have no experience with StringTemplate.
http://www.picshag.com/show.php?f=pics/112010/java-c-php-rub...
He basically says that if the blog author actually had a look at the language before bashing it, he would have found valid issues.
I agree with that. The author's complaints are unsubstantiated and don't reflect the issues people encounter in reality.
You can be honest, correct and still turn people off.
Could you provide more data points?
(By the way, in C such loops can typically be parallelized by adding one OpenMP pragma.)
It doesn't say much until you define what's most important to you. Is it more important that you can use Scala and get your code working more quickly or do you have more time to write and debug a C program and do you really need to do that for performance reasons? Does the code need to function as part of a larger Java/Scala or C application, etc. In other words, and as always, you need to pick to right tool for the job.
The JVM is very fast now days, in my work the issue of performance vs. C never comes up. Obviously there are still valid uses for C these days, but you can get very decent performance from the JVM and that often means you can finish your work faster.
list.par().map(f);I process upwards of a million facilities ( a facility is the exposure on a commercial loan a bank makes to a client ), trying to forecast their expected loss over 12 future quarters.
I rewrote my code like so :
val facs:List[Facility] = ...populated via jdbc query ///
val N = 1000
facs.grouped(N).foreach( group => {
group.par.map( fac => expectedloss(fac)
Now the outer loop is sequential but the inner loop is parallel. It chugs along, and processes the entire million plus facilities! I get some control via the N. Currently my N is 1000 and all 8 cores running at 100% capacity, but I can slow down the workload with smaller N.