>
>
> My experience tells me that before switching the benefits should be
> enough and for me it went quite good sticking with a language at least
> 5 years. That said, I sticked with Magic II about 6 years and with VB
> about 14 years. And those were the two languages I was most productive
> with.
I can't comment for anyone coming from a different language, but studies on
migrating Java->Scala shows that you'll be matching productivity levels
after 4 weeks, and improving on them thereafter. This is based on pure
research as well as feedback from the experiences at EDF trading and
Twitter.
Sadly, I don't have references to the original data, though it is something
I've been trying to track down.
> I think we need to distinguish between research and productive
> projects. I am working at a small company. Working for a year on
> learning a new language or stack and trying that on a new project
> would be critical for the whole company if the experiment fails. When
> I was still in school and at university (and of course did not have
> wife and family) things were different. I had more spare time and
> invested in trying different new stuff (and there were attempts
> hopping on real new stuff that completely failed).
If it took a year, then the cost/benefit would be very different, agreed.
> Don't tell me of "natural expression", when I don't find Scala very
> "natural" although l know a lot of languages so far. Don't see those
> concepts where it fits so well - not for my type applications.
Also true. Without any experience in functional programming it *is* very
difficult to see how it might be relevant to you.
That doesn't mean it isn't relevant, just that you can't see it. I have a
great deal of empathy for this, as I was once in the same position.
e.g. "What's the point in solving problems with recursive functions? Isn't
that just a needlessly complicated party trick to show off how clever you
are, with no real benefit"
"Immutability doesn't make sense, isn't the whole point of software to
change stuff"
I was wrong, and I freely admit it. True day to day functional programming
and immutability is best reflected in the simplicity and elegance of
something like JodaTime.
The high-level academic papers posted on lambda the ultimate really don't
reflect the reality of working in this style for a production environment.
> One of these two examples is easier to comprehend:
> > //Java
> > List newList = new ArrayList<Integer>
> > for(Integer item : oldList) {
> > newList.add(item * 2)
> > }
> > //Scala
> > val newList = oldList map {_ * 2}
>
> 1. In your Scala sample I don't see what that type of items list
> contains or should contain.
>
That's the entire point, it doesn't matter!
If it's a list of Ints and must later be changed to a list of Doubles or
BigInts, why *should* you need to go and change every tiny bit of code that
uses the list?
The Scala code is far more maintainable, it also maps more closely to the
way I think about the problem. And, yes, it happens to be shorter.
2. Your example is a typical simple sample you would give when
> learning or teaching Scala. In realtime there would be more in the
> brackets part and hence make it less readable.
>
Did you just state that adding more code makes it less readable? I agree!
> 3. I only have to type "newo<tab>" and "fore<tab>" in NetBeans to get
> the java "boilerplate". So I not really have to type much to get the
> "verbosity" which I consider as information rather than boilerplate.
>
What's the equivalent to the Tab key for reading back the code? Can your
IDE do that for you? It'll be read many more times than it's written...
More worrying still is the fact that Java *needs* this kind of IDE support.
It's certainly nice to have, but when it becomes essential I see that as a
problem.
> 4. If I need such things more often I would write a function like this:
> public static ArrayList<Integer> multiplyListItems(List<Integer>
> oldList, int n)
> {
> ArrayList<Integer> newList = new ArrayList<Integer>();
> for (Integer i : oldList)
> {
> newList.add(i*n);
> }
> return newList;
> }
> Which means, doing the multiplications then would also be a one-liner:
> List<Integer> newList = multiplyListItems(oldList, 2);
> One-Liner + clearly defined contents.
>
And what happens when you need a list of Doubles, or Floats, or Matrices?
The Scala code will continue to work unchanged.
I'll have it compiled and tested while you're still writing a multitude of
extra helper methods.
For the case you come up with the argument that this is additional and
> Scala can it do out-of-the-box that short way: I don't know any
> programming language that offer even approximately the common stuff I
> need so anyway I have to create my common libraries containing all the
> stuff needed for my real work.
>
Again, I agree, this is a strong driving force behind Scala, and the reason
why the features work together so well in helping you create an elegant
reusable library or DSL.
For example; When you look at an example of using Scala actors, you're
looking at a pure library, actors are absolutely *not* in the language spec.
Don't understand me wrong: It is nice to have an out-of-the-box way to
> do some things shorter - but you need to offer me more substancial
> advantages to make me switch. And for the case you do mention now the
> functional stuff - I can do this in Java too if I want but basically I
> don't like the functional coding so this is even no advantage for me.
It's hard to see how functional programming can help if you've never used
it.
I understand, I've been there.
> I want to create software that more closely matches how I'm thinking about
> > that software. That's a benefit, it makes it easier to write and,
> crucially,
> > much easier to read.
>
> This is just your opinion. Other people think different and don't
> share your opinion about readability.
It *is* a subjective topic, of course.
But... There seems to be a general agreement that "accidental complexity"
hurts readability/maintainability, and I believe that Scala does a good job
of reducing this.
>
> > Developers who come after me will be able to read what I *meant*, not
> what I
> > was forced to write so that I might satisfy the compiler.
>
> ROTFL! Why do you think that laws are written in so awful long texts?
> Because leaving too much room for *interpretation* mostly does not
> bring the intended result. It is already hard to read somebody else's
> code (that is why many people rather do a rewrite of a code instead of
> fixing the old code) - if you expect me to understand what you
> "meant", I just say: Be clear in what you code. This includes that you
> specify the intended content of your list for example.
Programming and Law couldn't be more different.
Programming evolved from engineering and Mathematics, it's all about
expressing a clearly defined concept in a manner that a computer can
understand, Law is about trying to pin down inherently ambiguous concepts.
The idea that there can be such a thing as a "perfect" law is laughable, but
there *can* be such a thing as a perfectly doubled number.
What if simply want to double everything that happens to be in a List,
regardless of type?
(perhaps I suspect the type may need to be changed at a later point in time)
Doesn't being forced to duplicate a type (that has already been specified)
obscure my intent?
This is type inference, not dynamic typing. The result of the operation is
still definitely a List<whatever>
>
> > I'll happily go to the extra effort of writing rich Scala APIs/DSLs, with
> > operator overloading, type classes, implicits, etc. If that means that
> code
> > using such a library them becomes easier to read/write/maintain.
>
> Have fun. I did C++ a long time ago at school and at university. I
> never needed operator overloads for example. What I would need is real
> good browser integration in Swing GUI for example. I hardly expect
> Scala offering me this. Or I would need an easier use of SOAP and REST
> webservices. Fortunately NetBeans already helps in generating stubs
> from wadl and wsdl - does Scala a better job here?
> My focus is practical results, so I am only interested in things that
> give me a boost there.
XML literals in the language help a *lot* with REST services.
I'm also finding swing code far easier to write by using first-class
functions for event handlers.
There's a good summary here:
http://www.scala-lang.org/sites/default/files/sids/imaier/Mon,%202009-11-02,%2008:55/scala-swing-design.pdf
It's a very practical language!
> > To me "just creating software" is about using tools that are as
> > natural-feeling as possible, not about struggling with
> > complicated/nonintuitive frameworks, regardless of how well I may have
> > memorised them.
>
> I fully agree with you that there are plenty of complicated and
> nonintuitive frameworks. But don't blame the core language for that.
You can write rubbish in any language, but that doesn't mean that a language
can't help you out here.
If I'm writing a complex number library, then I want to be able to define
the + operator, this will make my library more usable.
Anyone who's had to work extensively with BigDecimals will appreciate this
point.
--
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
