Reinier,
You want a definition of simple? Ok, some code is more simple than some
other code if it contains fewer tokens that are outside the domain. E.g.,
Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++. Java's
SwingUtilities.invokeLater(new Runnable() { public void run() {
button.doClick(); } }) is not as simple as Scala's: doLater(button.doClick).
Staying cutting edge on Scala is easier as it does not require a cutting
edge runtime.
In my opinion, for tasks for which Java is a reasonable option, so is Scala,
as it is typed and runs in the same environment. I wouldn't look at Groovy,
JRuby or Jython for those, because they are untyped.
Regarding writing in DSLs, pretty much all code unless it is spaghetti ends
up being written in a DSL. For example, at college I saw plenty of Pascal
users writing lots of lines like:
gotoxy(3,4);
write('|');
gotoxy(5,6);
write('-');
to draw ASCII forms etc. I wasn't actually studying computing at the time,
so I didn't have to write any of that code, but it seemed logical to me to
make a procedure writexy(x: Integer, y: Integer, char: Character) to write
the above as:
writexy(3,4,'|');
writexy(5,6,'-');
That is, I invented a DSL and used it, without knowing what one was. It has
nothing to do with missing out a dot in Scala.
(Incidentally, Pascal was the first semi-colon delimited language I came
across after years of BASIC, and I was learning it by following the compile
errors. The compiler told me it was expecting a ; at the beginning of the
line, so that's where I put them! I got some funny looks when I showed the
Computing students that code)
Regarding productivity loss or gain from moving to Scala, I did screw up one
project by doing this, but that was more to do with my then lack of good
engineering practices. For example, I had moved from 20031112-source.tgz
style 'version control' to darcs, and then moved to Windows, where darcs was
not then supported very well, so I went without version control for a while
(the real issue being that I had no server to speak of to store code). That
was manageable, though not ideal, but when I moved to Scala I could really
have done with 'game save points'. As a result I went some months porting
to Scala without a successful compile, and being unable to roll back to a
working point. Eventually I got it compiling and all the unit tests running
again, but the UI was in tatters. I still hope to resurrect it (I was
allowed to make it open source when I left, meaning I could finally host it
on a public svn/git server, oh the irony).
I expect nobody on this list is at the point I was then; we probably all use
version control and use it reasonably well, and it is easier now to port to
Scala than it was, as Scala can do mixed-language compilation (by being able
to parse just enough Java). Thankfully it was a pretty low risk project,
but it did sadden me.
Since then I've only had benefits from using Scala, but then I have become
competent in version control, I now use tickets to manage tasks instead of
emails or bugs.txt files in the codebase, and perhaps more importantly I'm
kept honest by the fact that I'm expected to make releases all the time.
The project I screwed up was only used from February to May every year
(apart from some random people in Colombia who got hold of it). I don't
think the screwup was Scala-specific at all, I'd have made the same mistakes
porting to any language.
Your point about Scala users being uninterested in your code because it uses
Java libraries seems completely false. Most Scala programmers are very good
Java programmers, and probably over half of them know Java's standard
library better than Scala's.
On Fri, Sep 17, 2010 at 1:05 AM, Reinier Zwitserloot <[email protected]>wrote:
>
>
> On Sep 16, 6:22 am, Sean Griffin <[email protected]> wrote:
> > 1. People say Scala is complex, but the actual examples that attempt
> > to prove this complexity are rare.
>
> No they aren't.
>
> > Features that support *writing*
> > DSLs are often used as those examples. I've done a fair amount of
> > Scala development. I have yet to write a DSL.
>
> You've written in DSL plenty of times already. Ever omitted the 'dot'
> when dereferencing? Ever decided not append "()" to a method call that
> doesn't require any arguments? You're a winner already! The DSL nature
> of scala does in fact leak out more during using a library intended to
> be used that way than vice versa. Operator overloading, omission of
> dot for dereference, omission of parens, the underscore shortcut when
> inline-specifying a closure, these are what are meant (or at least,
> what I mean) when I refer to scala's DSL features, and these are ALL
> things that are to be typed by the USER of a library, not the writer
> of one. Unlike e.g. generics wildcards which casual use of a library
> won't ever bother you with.
>
> > 2. Capabilities that currently exist in Java are simpler in their
> > Scala equivalent
> >
>
> You keep using that word, "simpler". This discussion is a lot more
> nuanced than that, unfortunately. What you keep calling "simpler" I
> tend to consider more complicated. And yes, I've used scala, rather a
> lot even. I'm not equating "simpler" with "doesn't look familiar".
> Until you define what you mean with simpler, I don't think this is
> going to get past the "he said, she said" phase.
>
> >
> > I won't be able to use Java 7 for probably 4 more years. I can't even
> > use Java 6 yet because I have to remain compatible with a Java 5 JRE.
>
> But staying cutting edge on scala is legit? Talk about using two
> yardsticks. You're actually going with "scala is better because its
> more stable"? Good luck with that argument.
>
> > Lombok could give me easier data classes but wouldn't allow me to use
> > them in pattern matches.
>
> Ah, yes, just keep moving the goalposts, I forgot.
>
> > only that it's worth a serious look.
>
> In contrast to, let's say, groovy, jruby, or jython? Are those not
> worth serious looks?
>
> >
> > Finally, the whole "drastic as switching to an entirely new language"
> > argument doesn't hold much water with me. Learning the language is a
> > one time thing.
>
> Of course it isn't. That's ridiculous. Scala revs fast (an argument
> being used by e.g. Kevin to convince people to switch, no less!). I
> need only point at scala 2.8 which is a massive update, for example.
> Even if scala didn't rev like its a fairly new language, there's the
> community. They release new, major libraries all the time. Styles
> change, too. Even java has this quirk: 5 years ago, the builder
> pattern wasn't all that famous and methods returning self so they
> could be changed where quite rare. Now you see them everywhere. joda-
> time and guava are used in lots of places, but they didn't exist 5
> years ago. Somebody's kicking the tires on the web framework world
> every other year, it seems. Scala is of course no different.
>
> Long story short: Claiming that learning a language is a one-time
> investment is a falsehood.
>
> This isn't a bad thing, but it does highlight yet again what I keep
> saying: If you're going to switch to scala, then switch. Going halfway
> is not a good idea.
>
> Any product you can write in scala, you could write in java, and vice
> versa with no more than a ~25% productivity loss, and that's in rare
> and extreme cases. The "right tool for the job" is not useful in such
> a scenario. The effort in keeping up to date at two languages costs
> you more in total productivity loss using either language than what
> you gain by being able to switch to the one that's better suited at
> the job. No, if you're going to go down this path, you should learn
> javascript (because html+web is something completely new from giving
> people a swing app to download, for example), or javafx (because
> writing certain GUIs in javaFX is easily 2 to 3x faster than doing so
> in swing), or a new web framework, or something like haskell (more to
> learn more about writing code in java/scala than actually add a tool,
> but that's good too!)
>
> > Learning each new library's API or framework,
> > regardless of the language, is a continual thing and we never question
> > that!
>
> Scala, by for example replacing the collections library, means you
> need to not just learn a new language, no, you've got to learn an
> entirely new API too. Yes, you can interop with java's libraries, but
> then you're on your own. The vast majority of java programmers can't
> read your stuff very well because its scala, but the vast majority of
> scala users don't really want to mess with your code because its using
> non-standard libraries. This doesn't work. You need to switch over
> completely, as I keep saying.
>
> Technically the idea of a java clone that just cleans up a few issues
> may even work (I doubt it'll be compelling enough to cause many people
> to switch), but at the very least such a language will not introduce a
> significant amount of new API. Scala is not that language. Scala is a
> major change from java. Most actually prefer it that way.
>
> --
> 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]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
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.
