Stephen Colebourne on Scala (ouch!)

[phil swenson]

http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html

[Jan Goyvaerts]

Speaking of which - NO intention whatsoever to start a flame war ! - is it correct about the state of the testing ?

On Wed, Nov 23, 2011 at 14:42, phil swenson <phil.s...@gmail.com> wrote:

http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

It's a bit more complicated than that...

Since the referenced podcast was recorded, the collections framework has been steadily aggregating tests and fixes/performance enhancements from the community.  It's definitely in better shape than it was back then.

Also, many of the subtle bugs (so not the stuff you're likely to encounter on a day-to-day basis) originate from the pattern matching code.  This is one of the oldest sections of the compiler code and grew organically long before Scala looked like it had the potential to be a commercial success, it's also got to be the single largest source of WTFs for anyone working in the compiler source.

So the directors of the firm hired to continue the pattern matcher after the other people had been sacked, wish it to be known that they have just been

sacked. A shiny new and fully tested pattern matcher has instead been completed in an entirely different style at great expense and at the last minute. [1]

In short?  Yes, there's some less-than-perfect legacy code in there, as with any well established codebase[3].  But it's most definitely improving, and the nastiest code is invariably the stuff that has been most widely used, so it's had plenty of testing one way or another.

[1] Not really[2], it was done lovingly with great care and attention, over some period of time.  Nobody was sacked.

[2] But I couldn't resist the quote... http://www.imdb.com/title/tt0071853/crazycredits [4]

[3] And Scala's old enough that it was written when people still thought that embedded XML was a good idea!

[4] We apologise for the fault in the footnotes. Those responsible have been sacked.

[Dick Wall]

I am a little disappointed that despite writing two polite and on-message responses to the article, Stephen has decided not to show those in the comments apparently. I am disappointed but not entirely surprised that his message is being controlled in this way. Stephen, I don't know if you still read the Java Posse group, but if you do, can you let me know why my responses were not published in the comments, and whether you want any changes to them in order to show them? Thanks.

Dick

[Ricky Clarkson]

I think you'd have been better off keeping the film quotes out of that.
Either the coffee isn't working (quite probable, it's made from powder by a machine) or that was quite confusing.

---

From: Kevin Wright <kev.lee...@gmail.com>

Sender: java...@googlegroups.com

Date: Wed, 23 Nov 2011 14:36:48 +0000

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] Stephen Colebourne on Scala (ouch!)

[Josh Berry]

To be fair, with all of the locations I've seen that blog linked, it
could just be a volume issue. My expectation was that there would
more blogs in response. (Of course, I view blog posts with comment
boards equivalent to trying to have every speaker at a talk shout
questions at once and get answers. This works in small crowds, of
course, but with the audience this post reached, it would have been
like having a chat at a conference keynote. Much saner to just see
the other speakers take the stage and say something.)

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/eLzRtpGSgPAJ.

[Jan Goyvaerts]

Right; that's clear then. Thanks !

It's just that during my trials with Scala I regularly crashed the compiler on pattern matching. One of the identified causes was the that the generated method was too big for the JVM. Is that still the case ?

[Ricky Clarkson]

I remember when he and I used to agree. Mine's the third name on the First Class Methods proposal for instance.

The language Stephen is promoting seems to have painful interoperability with Java, and a lot of his concerns about Scala are things that would make interop more difficult.

I don't know why you'd want each JVM language to have its own incompatible module system. On the JVM that needs thinking about for the platform as a whole.

---

From: phil swenson <phil.s...@gmail.com>

Sender: java...@googlegroups.com

Date: Wed, 23 Nov 2011 06:42:34 -0700

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: [The Java Posse] Stephen Colebourne on Scala (ouch!)

[Dick Wall]

Fair point, but I made both comments quite early yesterday morning after I saw the tweet, both were clearly marked with my name and the java posse website (cos I am too lazy and haven't updated my own blog in way too long), and both were, as I say, polite and professional in nature. Indeed one was in response to the implication that I had somehow not demonstrated Scala in my demo at the Scripting Bowl, which is clearly nonsense and I felt deserved some kind of response to that effect. Perhaps Stephen has longer than a 24 hour backlog, perhaps he did not recognize my name, but I have trouble believing either of these things. Not to worry, I can always mention it at the end of the next Posse episode :-)

Dick 

[Kevin Wright]

What! No Monty Python?

I refuse to back down over this...  Carl would never forgive me if I did :)

[Carl Jokl]

Which Carl? There are several...

Don't make me sit you in the comfy chair and poke you with sharp
cushions!

On Nov 23, 3:02 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> What! No Monty Python?
>
> I refuse to back down over this...  Carl would never forgive me if I did :)
>

> On 23 November 2011 13:48, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
>
>
>
>
>
>
>
> > **

> > I think you'd have been better off keeping the film quotes out of that.
> > Either the coffee isn't working (quite probable, it's made from powder by
> > a machine) or that was quite confusing.

> > ------------------------------
> > *From: * Kevin Wright <kev.lee.wri...@gmail.com>
> > *Sender: * java...@googlegroups.com
> > *Date: *Wed, 23 Nov 2011 14:36:48 +0000
> > *To: *<java...@googlegroups.com>
> > *ReplyTo: * java...@googlegroups.com
> > *Subject: *Re: [The Java Posse] Stephen Colebourne on Scala (ouch!)

> > On 23 November 2011 14:04, Jan Goyvaerts <java.arti...@gmail.com> wrote:
>
> >> Speaking of which - NO intention whatsoever to start a flame war ! - is
> >> it correct about the state of the testing ?
>

> >> On Wed, Nov 23, 2011 at 14:42, phil swenson <phil.swen...@gmail.com>wrote:
>
> >>>http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html

[Kevin Wright]

On 23 November 2011 15:08, Carl Jokl <carl...@gmail.com> wrote:

Which Carl? There are several...

*the* Carl, obviously.  Although some know him as... Quinn

 

Don't make me sit you in the comfy chair and poke you with sharp
cushions!

Did you make sure that all the stuffing is at one end? :P

 

[Cédric Beust ♔]

Dick,

I don't think there is any moderation at all (my comments appeared right away and there is another comment that says nothing but the word "FUD" twenty times) but I let Stephen know about your comments. I'm pretty sure your comments are the most reasonable of the entire discussion :-)

-- 

Cédric

On Wed, Nov 23, 2011 at 7:02 AM, Dick Wall <dick...@gmail.com> wrote:

Fair point, but I made both comments quite early yesterday morning after I saw the tweet, both were clearly marked with my name and the java posse website (cos I am too lazy and haven't updated my own blog in way too long), and both were, as I say, polite and professional in nature. Indeed one was in response to the implication that I had somehow not demonstrated Scala in my demo at the Scripting Bowl, which is clearly nonsense and I felt deserved some kind of response to that effect. Perhaps Stephen has longer than a 24 hour backlog, perhaps he did not recognize my name, but I have trouble believing either of these things. Not to worry, I can always mention it at the end of the next Posse episode :-)

Dick 

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/-g1TmSL_lqAJ.

[Vince O'Sullivan]

On Nov 23, 3:02 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> What! No Monty Python?

Hopefully not. Nothing clears a room faster than two programmers
swapping forty-year-old Monty Python quotes.

[Dick Wall]

Yeah - I guess things go wrong on the internets a lot. I will try and see if I can remember what I said and resubmit. I will also combine the two into one post. Maybe over lunch today. I can put them up here too.

Dick

[Simon Ochsenreither]

Yes, read it.

I think it is a bit sad. Remember the days where people where proud of innovating at their own and critizing that “other” platforms where — in their opinion — the community pretty much centered around Microsoft and accepted what Microsoft fed them?

Looks like at least a few innovation cheer leaders transformed into fear leaders, insulting people along the way and spreading fear, uncertainty and doubt.

There has been one post on HackerNews which I think has pretty much hit the nail on its head:

[...] is never good when you start out a discussion by saying now I know people will disagree but thats because their bigoted zelots. Its kind of disingenuous to attempt to post a technical dissent filled with personal opinion and preface it with that kind of clause inevitability allowing you to label any dissent as "See those scala zelots are at it again"
http://news.ycombinator.com/item?id=3265003

But nevertheless, I'm still waiting for the obligatory “OMG Scala zealots have been mean to me” aftermath post. :-)

On the “contents” of the post itself ... pretty much hypocrisy at its best.

Bye,

Simon

[Steel City Phantom]

the types of projects that i do completely eliminate scala as a reasonable option for anything more than simple testing utilities, and unfortunately thats the part that people are the proudest of. ive worked on large PHP projects with its dynamic typing and it was a nightmare among nightmares.  it actually made me long for the days of VB when i could simply put "option explicit" on the top of all the files to statically type them and solve a good 60% of the bugs we were encountering.  ESPECIALLY when it starts to relate to writing things to the database.  oh god, the horrors we encountered there, i still wake up in the middle of the night in a cold sweat.

take the project im wrapping up right now.  im running a team of 8 developers across 3 different companies in 4 different cities in 2 states.  add to that a starting point of 200,000 lines of extraordinarily badly designed code with absolutely zero javadocs or any other form of documentation and you have a typical tuesday morning for me.  even on the best days its like herding cats to keep on track.  if this were done in a dynamically typed language like scala, php, or whatever, i most likely would have told my boss to write it off as a total loss and propose a new system from the ground up.  but because Java forced the previous developers to follow the strict typing and coding rules of java itself, my team and i were able to save it and get it running again with a new database access layer and security system.  this project would flat out not have been possible with a dynamic language.  it just couldn't.

you want an improvement that would help me?  how about a JVM that has a true memory managment system that allows the application to manage its memory allocation without cryptic settings in config files and reboots.  how about a JVM that doesn't have a @#$ damn permgen space.  how about a garbage collection system that actually gives you back what it cleans out of memory.  oh, how about a garbage collection system that you can trigger when you want it to actually do something specific, like truely flush this 10 meg variable and return those 10 megs back to the system, not just say "oh yea, i did that, TRUST ME!!!" how about language features that allow a dependency management system that doesn't require me to write shell scripts to delete old versions of files after every build that keep crashing because class A needs version 10 and class B needs version 9.  

that would put a smile on my face

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You want it fast, cheap, or right.  Pick two!!

[Simon Ochsenreither]

Hi,

are you sure we are talking about the same language? It pretty much reads as if you are arguing against dynamically typed languages...
 

dynamically typed language like scala, php, or whatever

Scala is statically typed, and yes, it takes the type stuff a bit more seriously than Java, too.

Bye,

Simon

[Fabrizio Giudici]

Probably a bit too much. BTW, I didn't understand yet whether this thread
was yet another discussion about Scala, or about Stephen's blog post.

I haven't read the blog post, as 102+ answers are just unreadable. I did
attend Stephen's presentation (not really because I'm interested in Scala
or Fantom, but because I never attended a talk by Stephen). Overall, it
was very interesting. After a short exchange with Mario Fusco, I
understand that some criticisms about Scala were probably too shallow. In
the end, though, I appreciated one of Stephen's conclusions, that Scala is
overkill on typing and that just a few of current programming problems
with Java are about typing. Thus there's some overengineering in a useless
area. OTOH, while some aspects of Fantom are interesting, I don't feel
much enthusiastic about it (still, I don't think Stephen wanted to give it
a push, but just have a comparison with Scala). Definitely, it's
interesting that with Fantom you can't have shared mutable state, if I
understood well, and this is a real area of troubles, where I'd appreciate
some care by the language.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Kevin Wright]

On Nov 23, 2011 7:09 PM, "Steel City Phantom" <scph...@gmail.com> wrote:
the types of projects that i do completely eliminate scala as a reasonable option for anything more than simple testing utilities

Many people start with Scala there, the DSL capabilities make it a *very* good fit for writing specifications that read almost exactly like user stories.

take the project im wrapping up right now.  im running a team of 8 developers across 3 different companies in 4 different cities in 2 states.  add to that a starting point of 200,000 lines of extraordinarily badly designed code with absolutely zero javadocs or any other form of documentation and you have a typical tuesday morning for me.

So you have bigger problems than language choice.  But have you considered that your programming language is the main source (no pun intended) of communication between those teams.  As a communication channel, is it expressive enough, what's the signal/noise ration?

if this were done in a dynamically typed language like scala, php, or whatever, i most likely would have told my boss to write it off as a total loss and propose a new system from the ground up.

Scala is anything but dynamically typed!  One of the criticisms of that article was that the type system is too imposing.  Which is is, if you only try and understand it by reading the language specs and not by e.g. actually trying to program something in Scala.  In practice, it gets out of your way very nicely.

but because Java forced the previous developers to follow the strict typing and coding rules of java itself, my team and i were able to save it and get it running again with a new database access layer and security system.  this project would flat out not have been possible with a dynamic language.  it just couldn't.

So if the static typing of Java helped, then presumably the more complete type system of Scala would help even more.  As a trival example, it makes it easy to express the idea of optional or uninitialised values via the Option class.  Using nulls in Java just isn't as effective!

In general, the issues you've raised so far make it sound as though Scala could actually be a very good fit.

you want an improvement that would help me?  how about a JVM that has a true memory managment system that allows the application to manage its memory allocation without cryptic settings in config files and reboots.

Scheduled For (I believe) Java 10

how about a JVM that doesn't have a @#$ damn permgen space.  how about a garbage collection system that actually gives you back what it cleans out of memory.  oh, how about a garbage collection system that you can trigger when you want it to actually do something specific, like truely flush this 10 meg variable and return those 10 megs back to the system, not just say "oh yea, i did that, TRUST ME!!!"

Permgen space is on the roadmap to be dropped, probably alongside Java 9, with G1GC being made the default garbage collector

how about language features that allow a dependency management system that doesn't require me to write shell scripts to delete old versions of files after every build that keep crashing because class A needs version 10 and class B needs version 9.  

Project Jigsaw, a High priority on the Java 8 roadmap.

that would put a smile on my face

Quite :)

[Kevin Wright]

Agreed, shared mutable state is generally a PITA.  Then again, it can occasionally be very valuable if correctly used and controlled.

Case in point, the disruptor pattern achieves some amazing performance metrics through use of shared mutable state, as do certain lock-free algorithms and software transactional memory.

Are these solutions that we want to categorically rule out of a programming language?

On 23 November 2011 20:06, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Fabrizio Giudici]

On Wed, 23 Nov 2011 21:23:12 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> Agreed, shared mutable state is generally a PITA. Then again, it can
> occasionally be very valuable if correctly used and controlled.
>
> Case in point, the disruptor pattern achieves some amazing performance
> metrics through use of shared mutable state, as do certain lock-free
> algorithms and software transactional memory.
>
> Are these solutions that we want to categorically rule out of a
> programming
> language?

Not by chance I wrote "I'd appreciate some care", rather than say that I
don't want to see it supported. Clearly, it's ok when experienced people
use it for writing the Disruptor or such, while I'd appreciate something
that prevented a direct use, not mediated by a "trusted" library.

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 12:23 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Case in point, the disruptor pattern achieves some amazing performance metrics through use of shared mutable state, as do certain lock-free algorithms and software transactional memory.

Are these solutions that we want to categorically rule out of a programming language?

Agreed, mutable state is important for a bunch of reasons, but mostly performance. There are two concepts in tension: you can either have very high performance (with mutable state) or parallel code that might be easier to reason about (with immutable state). Notice I said "might" here because there are other factors that can make even 100% immutable parallel code a nightmare to debug (e.g. very high asynchronicity, which the actor model tends to encourage).

Both Java and Scala are in a good place here because they allow both types of control.

-- 

Cédric

[Ricky Clarkson]

> Scala is anything but dynamically typed!  One of the criticisms of that
> article was that the type system is too imposing.  Which is is, if you only
> try and understand it by reading the language specs and not by e.g. actually
> trying to program something in Scala.  In practice, it gets out of your way
> very nicely.

I've found that to be true, but I find myself able to understand the
type systems of C# and of Haskell (ok, not everything) simply by
reading the language spec. Less true of Java, but I had 10 years less
experience when I first read Java's than when I first read C#'s.

There are things I would happily remove from Scala's type system and
it could be that Java's real successor will be something like Scala,
but minus a few features. Here's what I'd kill:

View types - nobody knows what they are but they knock a bunch of
lines off a number of use cases.
Implicit conversions - the main use case is to do what C# does with
extension methods, and those are simpler. I'd keep implicit
parameters, but only just.
The many and varied uses of underscore, _. Just write 'ignored'
instead [for most uses].
Self types. I don't care much about OOP (not to say I'm in the
immutable-only camp), and those seem only useful in that. The
encoding I'd normally use is more like Java's Enum type (trait Foo[F
<: Foo]) but when I'm coding without enforced designs, which is
luckily all the time now, it just doesn't come up.
Incomplete pattern matches - those should just be a compile error, as
should an incomplete switch over an enum in Java.
Existential types. Wildcards were a mistake in Java, they don't
really need to be copied over. There are reasons for not having 100%
compatibility, and sanity is one of them.

It's not part of the type system, but I'd also drop the XML literals
as I think pretty much everyone using Scala today would too. They are
probably *the* best advert for continuous code review I can think of
(the literals aren't bad but the code backing them is).

I think that without those features, sure, some code would be longer
but I don't think it would be disastrous and it would be much easier
to learn the language. That said, you can learn the language today
and ignore all those features, but some libraries will make that
difficult as they rely on the features.

[Dick Wall]

My comments made it up on the blog this time, but as promised I thought I would throw them in here as well for further pondering. It's a long one, and not quite the same as the first posts I made (since I couldn't remember exactly how I had worded them), but it's about the same in spirit.

As the guy who represented Scala in the scripting bowl at JavaOne, as well as a Scala practitioner for over 3 years working on real world projects for which Scala is an ideal match, I feel the necessity to weigh in on the discussion.

Firstly, comparing Scala to EJB 2 is, of course, an attention getter, as it is supposed to be, but as several people have pointed out here, falls apart on anything greater than a casual glance (from the comments, even the Scala detractors don't seem to agree with that one). If you are going for headlines, Stephen, you have them, but the risk with statements like this is that they will reflect more poorly on you than on your subject, and may even perversely boost the interest in the subject. 

I share the sentiment with several other people in the discussion that I would like to know what, and how much, experience you have with Scala to make these kind of judgement calls. If you are telling the world not to use Scala (which it sounds like you are, and with which I have a whole other set of issues), at least that position should be backed up by some kind of description of real world experience you have had trying to use it. I would not comment negatively on Fantom since I have only dabbled with it, I don't believe it has enough to interest me or make me want to invest the time into learning it more deeply, but then I certainly wouldn't tell other people how much I dislike it or recommend that they don't use it.

Coming back to that subject, I am also confused by your aim here. Are you attempting to just tell the world you don't like Scala, or are you trying to discourage the rest of the world from even trying it out? Surely if you have the courage of your convictions, your position would be the same as mine: why not give Scala a try for yourself and see what you think. After all, people should care less about what you or I think and more about making up their own minds. I did, three years ago, and I am very happy with the decision to use Scala as my primary development language. At the same time I do not feel the need to put down other languages with negative comments and glib comparisons to technologies that really bear little resemblance.

In fact I was unable to make it to your Fantom is light years ahead of Scala talk at Devoxx, because I was talking about a subject that matters to me: Courage in software development. The core messages behind that talk are that people should care less about what "celebrities" think, and should do more thinking for themselves, also to get out of their comfort zone a little more.

If someone tells me a technology should not be learned, my natural reaction is to move that technology further up my interest list. If it's bad, I can eliminate it quickly enough, but I was raised to think for myself rather than to take someone (anyone) else's word for something that might interest me.

You started the article on a negative note as well, practically challenging the Scala community to deluge you with negative comments (really, why all the negativity?). In reading the comments, I would say in my opinion that the negativity scales are tipped more to the Scala detractors than the Scala fans.

I also read Richard Vowles comment that "Scala tied the scripting superbowl this year by trying its very best to not be like Scala". As the Scala representative in the scripting bowl, I can tell you I did nothing of the sort.

The clue here is in the name of the panel: the Scripting bowl. Clearly I am not going to dive into a discussion of higher kinded types in 5 minutes of scripting bowl time, but what I demonstrated was three different and very relevant aspects of the Scala language and platform that are useful to developers right now. 

The first was interactively scripting a real world project (actually the code base I work on every day) to try out ideas in the Scala shell. I demonstrated talking to a third party API (confluence), reading data, and parsing the XML out using only the standard scala libraries. I used a for comprehension, the xpath XML features and more.

The second was a demonstration of Kojo, a scripting and learning environment for kids. I did this to take on the notion that Scala was inherently over-complicated (thanks to the numerous comments from Scala detractors for the idea by the way, it made it really easy to choose a theme). Kojo is like Logo but in Scala, and is used by several people I know for teaching programming to high-schoolers. It is *absolutely* standard Scala, you define methods and use custom control structures and not a type system concept to be seen in the process. Just because it doesn't fit with your idea that Scala is to complicated, Richard, it doesn't mean you can just throw out there that it isn't real Scala. It is.

Finally I demonstrated the real crowd pleaser, a DSL that literally takes:

A long time ago in a galaxy far far away

and returns a String result. This is a reasonably advanced domain specific language, and again needed nothing more complex than string types and a single object to write.

Back to Stephen: in short, I am glad you seem confident enough in your opinions to share them in blog posting, but are you confident enough in them to invite people to try it out for themselves? I am! Please, if you are reading this, don't believe either of us but give it a go yourself. Learning Scala will not taint you in some indescribable way that will prevent you from ever programming again. Indeed, if you are interested in the coming crop of languages like Ceylon and Kotlin, Scala will introduce you to many of the concepts you will see in those languages so you can get a head-start on learning them. Chances are though, some of you will like Scala and continue to use it.

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 2:13 PM, Dick Wall <dick...@gmail.com> wrote:

The core messages behind that talk are that people should care less about what "celebrities" think, and should do more thinking for themselves

<digression>

I just can't help but chuckle at the idea that you made this point standing on a stage at a conference. A particular scene from "The Life of Brian" comes to mind :-)

</digression>

-- 

Cédric

[Simon Ochsenreither]

Well, my wish list is more on the practical side, because I don't care that much about the type system anyway. It stays out of my way but helps me to get “impossible” stuff done if I need it:

• Remove floating-point literals without a number after the point, e. g. “1.”
• Remove octal literals
  

Both points are being adressed, as well as:

• the new pattern matcher is in trunk
  
• the stuff behind the XML literals is being made more flexible, so the implementation can be replaced

So overall, I'm very happy.

Existential types are pretty much the sane cousin of wildcards and necessary in some places.

I'm pretty much against removing implicits, they are one of the key features of the language. I wonder what the whole angst is all about. Java has implicit conversions, C# has implicit and explicit conversions and those two languages are still alive.

[Martijn Verburg]

Hi Dick,

I like your Courage analogy. My Diabolical Developer talk at Devoxx
was very much in the same vein, although hidden behind a wall of UK/NZ
irony and sarcasm. Thinking for yourself and not blindly trusting the
'Giants' in our industry is something I think many in our industry
could do more of.

As I say to my audience:

"Those who can't code, teach, those who can't teach write books, those
who don't finish their books, speak at conferences"

OK, that's a little untruthful, so really what I'm saying is:

"If I'm speaking at a number of conferences, writing a book & running
mentoring/training courses then how much of my time am I really
spending coding? So you should take what I say with a grain of salt,
instead maybe you should listen to the developer sitting next to you
who's hacking on some code on their laptop right now."

Cheers,
Martijn

2011/11/23 Cédric Beust ♔ <ced...@beust.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to

> javaposse+...@googlegroups.com.

[Kevin Wright]

+1

and, as stages go, Devoxx is one of the most impressive/scary going, depending which side of it you're standing...

2011/11/23 Cédric Beust ♔ <ced...@beust.com>

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

I've had this discussion before (with Stephen of all people!)

I understand the reasoning for wanting to remove all of those features, but generally wouldn't do so.  There's a strong synergy between many of Scala's features, and removing any of them would generally hurt other features that you wanted to keep, or force them to be implemented with dedicated (and limited) compiler support:

View types - I'm assuming you mean view bounds here.  Okay, they're just syntactic sugar and could be removed without too much pain.  But they do a great job of representing intent.

For example:

def fn[T <% Seq[Char]](arg: T) = ...

would accept any value that can be "viewed as" a sequence of chars, such as a String.  The unsugared alternative is not as pretty and struggles to expose the intent:

def fn[T](arg: Seq[T])(implicit view: T => Seq[Char]) = ...

--

Implicit conversions - the main use case is to do what C# does with
extension methods, and those are simpler.  I'd keep implicit
parameters, but only just.

They're also core to the mechanism that allows collections to just do the Right Thing(tm).  For example:

someBitSet map {_.toString}

is only able to return a Set[String] thanks to an mechanism based on implicits, and this really just scratches the surface of what's possible. (for example, look up type classes in Scala)  I wouldn't give them up for anything!

---

The many and varied uses of underscore, _.  Just write 'ignored'
instead [for most uses].

Fair point... The humble underscore *is* too heavily overloaded

---

Self types.  I don't care much about OOP (not to say I'm in the
immutable-only camp), and those seem only useful in that.  The
encoding I'd normally use is more like Java's Enum type (trait Foo[F
<: Foo]) but when I'm coding without enforced designs, which is
luckily all the time now, it just doesn't come up.

I used a self-type only today!  They just make some things so much easier... Especially when coupled with structural typing, self types really do make some problems a great deal more approachable.  They also enable the cake pattern, and who doesn't like cake, eh?  The cake is *not* a lie...

---

Incomplete pattern matches - those should just be a compile error, as
should an incomplete switch over an enum in Java.

a.k.a partial functions.  *far* too useful.  For example, in implementing a web server where you can chain together different partial functions, each of which matches a different set of URLs.  Though I'd readily admit that the same can be done with a Function1[A,Option[B]] as is possible with a PartialFunction[A,B]

----

Existential types.  Wildcards were a mistake in Java, they don't
really need to be copied over.  There are reasons for not having 100%
compatibility, and sanity is one of them.

They're also, sadly, a necessary evil for dealing with certain Java libraries.  If Scala were to remove features that enable interop, then existential types most definitely would not be the first on my list!  As it is, interop was a core design choice of Scala, so existentials really can't be removed.

---

[Dick Wall]

Please - I encourage you to watch the talk - the irony is not lost on me, and indeed I tackle it head on, even to the point of pushing people to disagree with me and think for themselves (which is the point of the whole thing anyway) :-)

[Dick Wall]

I look forward to seeing this talk on parleys :-)

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 3:05 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

They're also core to the mechanism that allows collections to just do the Right Thing(tm).  For example:

someBitSet map {_.toString}

Right, but you can achieve the same result without needing implicits. I'll just show how Fantom does it but I'm sure the same applies to Gosu/Ceylon/Kotlin:

    // a set of A instances, where A has a toUppercase method

    aSet := [ A("foo"), A("bar") ]

    l := aSet.map | v->Str | { v.toUppercase }

    echo(l)

    echo(l.typeof)

[FOO, BAR]

sys::Str[]

The signature of map() is exactly what you would expect: it takes a function that takes an element of the collection and returns "something", and the type of your expression is "list of something" (here we transformed a list of A's into a list of strings).

It's really not rocket science, and the fact that you need implicits to achieve this result is an implementation detail that's very specific to Scala.

Sure, you can handwave it with "You don't need to understand the exact details of the API", but the truth is... you really do. Not a week goes by without me having to go check out a Javadoc or the signature of java.util or Guava method. And saying that only library authors need to know about implicits, CanBuildFrom and its triple generic signature is creating a rift between the Scala developers (people who know and people who don't), which is worrisome.

-- 

Cédric

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 3:35 PM, Dick Wall <dick...@gmail.com> wrote:

Please - I encourage you to watch the talk - the irony is not lost on me, and indeed I tackle it head on, even to the point of pushing people to disagree with me and think for themselves (which is the point of the whole thing anyway) :-)

If you trust me, leave the room right away!

I will definitely watch your talk (and many others) once they become available, I'm sure they will be great.

-- 

Cédric

[Ricky Clarkson]

I'll reply here now, but if anyone suggests taking it off-list after
this message that's fine by me.

On Wed, Nov 23, 2011 at 8:05 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> For example:
> someBitSet map {_.toString}
> is only able to return a Set[String] thanks to an mechanism based on
> implicits

That's implicit parameters as far as I know, whereas I was talking
about removing implicit conversions.

> I used a self-type only today!  They just make some things so much easier...
> Especially when coupled with structural typing, self types really do make
> some problems a great deal more approachable.

They seem to be used for avoiding making a type generic.

> Existential types.  Wildcards were a mistake in Java, they don't
> really need to be copied over.  There are reasons for not having 100%
> compatibility, and sanity is one of them.
> They're also, sadly, a necessary evil for dealing with certain Java
> libraries.  If Scala were to remove features that enable interop, then
> existential types most definitely would not be the first on my list!

One could write a bit of Java code that exposes a wildcard-less
version of a class to Scala. Not the ideal perhaps, but in the
interests of simplicity it might be for the best.

> As it
> is, interop was a core design choice of Scala, so existentials really can't
> be removed.

The interop is great from Java to Scala but terrible the other way
around. object X { val x = 5 } generates a class file named X$, for
instance. There are reasons but they are based on engineering choices
that could reasonably have gone the other way.

[Ricky Clarkson]

> Existential types are pretty much the sane cousin of wildcards and necessary
> in some places.

Other than Java interop? C# has a similar type system to Java and
doesn't seem to need them, but maybe its programmers replace them with
some runtime casting.

> I'm pretty much against removing implicits, they are one of the key features
> of the language. I wonder what the whole angst is all about. Java has
> implicit conversions, C# has implicit and explicit conversions and those two
> languages are still alive.

Java's implicit conversions are a fixed set, as you know. C#'s do not
make methods available on the value, so if you have a conversion from
Dollar to Euro you can't do mySavingsInDollars.BailOut(greece); you
need ((Euro)mySavingsInDollars).BailOut(greece);, where BailOut only
exists on Euro, not on Dollar. Or you can use a temporary variable as
in, Euro inEuros = mySavingsInDollars; and that triggers the implicit
conversion. Trust me, the example I wrote and deleted before that one
was worse!

So C#'s conversions are slightly more straightforward and are not
appropriate for Scala's main use of them. Luckily C# has extension
methods that cover that use case. To be more exact, I would remove
the 'implicit search' where Scala's compiler looks for an appropriate
type to convert a value to to make a method applicable, but C#'s and
Java's implicit conversions are not, to me, an issue.

[Josh Berry]

On Wed, Nov 23, 2011 at 8:54 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
> Right, but you can achieve the same result without needing implicits. I'll
> just show how Fantom does it but I'm sure the same applies to
> Gosu/Ceylon/Kotlin:

I could be wrong, but I think an underlying point Kevin was making was
that there is no compiler support outside of implicits for the
collections in scala. That is, if you had a use case that was similar
to this in code you were writing, you too could take advantage of it.
Since Fantom doesn't even let you write generic classes, I'm guessing
they special case their collections in the compiler.

[Cédric Beust ♔]

On Wed, Nov 23, 2011 at 6:28 PM, Josh Berry <tae...@gmail.com> wrote:

I could be wrong, but I think an underlying point Kevin was making was
that there is no compiler support outside of implicits for the
collections in scala.  That is, if you had a use case that was similar
to this in code you were writing, you too could take advantage of it.
Since Fantom doesn't even let you write generic classes, I'm guessing
they special case their collections in the compiler.

Yes, they most likely do. Don't focus on Fantom, I picked it because it's the fastest I can write an example with. I'm looking forward to writing this in Kotlin (with reified generics, no less).

My point was that I often feel that Scala is the proverbial frog being slowly cooked in its own complexity and not realizing that there are easier ways to provide certain functionalities. At the expense of certain features, for sure, so the question remains: are these extra features worth paying for the complexity and creating this rift between regular and API developers?

-- 

Cédric

[Ricky Clarkson]

> Since Fantom doesn't even let you write generic classes, I'm guessing
> they special case their collections in the compiler.

That really bugs me. When I began using Java I was really impressed
at what I would now call dogfooding, that it was pretty much built in
itself at least as far as the library goes, whereas I don't think that
was true for any of the BASICs I'd used beforehand. It was true of C,
C++ and Pascal which I used before Java but for some reason the
importance of it didn't really click until Java.

To see Fantom provide built-in generic types only seems like a serious
step backwards, like not having lambdas or not having recursion.

[Cédric Beust ♔]

I agree, it's a weakness, and one that Andy and Brian are resolved to address as soon as possible (and since there is some built-in generic support already present, I'm hoping the effort won't be too colossal).

I think it would be an acceptable limitation in the absence of the competition (after all, we managed to get by without generics in Java for a decade), but with Scala/Gosu/Ceylon/Kotlin around, I understand if this shortcoming makes people uncomfortable.

-- 

Cédric

[Josh Berry]

On Wed, Nov 23, 2011 at 9:33 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
>
>
> On Wed, Nov 23, 2011 at 6:28 PM, Josh Berry <tae...@gmail.com> wrote:
>>
>> I could be wrong, but I think an underlying point Kevin was making was
>> that there is no compiler support outside of implicits for the
>> collections in scala.  That is, if you had a use case that was similar
>> to this in code you were writing, you too could take advantage of it.
>> Since Fantom doesn't even let you write generic classes, I'm guessing
>> they special case their collections in the compiler.
>
> Yes, they most likely do. Don't focus on Fantom, I picked it because it's
> the fastest I can write an example with. I'm looking forward to writing this
> in Kotlin (with reified generics, no less).

Apologies, I had meant to say that I wouldn't be shocked if the other
languages also special case the compiler for their collections.
Kotlin goes so far as to make the contains method "break" variance
rules. That sounds like special casing as well. In fact, it seems
like all of the "easier" ways are really just doing the work in the
compiler such that others can not do the same tricks. :)

[Kirk]

+1

"The resemblance of any opinion, recommendation or comments madue uring this presentation to performance tuning advice is merely coincidental."

or simply put, advice given at a conference is not a substitute for common sense.

What I have learned in the past is that one has to be very very careful when reading what Stephen says. He's quite talented at leading you down the proverbial garden path with the intention of inspiring a very thoughtful discussion.

Regards,

Kirk

[Matthew Farwell]

The bug of which you speak is nested extractors generate exponential-space bytecode https://issues.scala-lang.org/browse/SI-1133, and is being worked on.

Matthew Farwell.

[Fabrizio Giudici]

On Wed, 23 Nov 2011 23:38:07 +0100, Martijn Verburg
<martijn...@gmail.com> wrote:

> Hi Dick,
>
> I like your Courage analogy. My Diabolical Developer talk at Devoxx
> was very much in the same vein, although hidden behind a wall of UK/NZ
> irony and sarcasm. Thinking for yourself and not blindly trusting the
> 'Giants' in our industry is something I think many in our industry
> could do more of.
>
> As I say to my audience:
>
> "Those who can't code, teach, those who can't teach write books, those
> who don't finish their books, speak at conferences"
>
> OK, that's a little untruthful, so really what I'm saying is:
>
> "If I'm speaking at a number of conferences, writing a book & running
> mentoring/training courses then how much of my time am I really
> spending coding? So you should take what I say with a grain of salt,
> instead maybe you should listen to the developer sitting next to you
> who's hacking on some code on their laptop right now."

LOL and I agree with your general points. It's just the matter of defining
what "mentoring" means. It's one of the things I frequently do and it
includes writing code together with the customer, including testing it and
bringing it to production (I mean, it's not just "academic" code).

[Kevin Wright]

I guess I missed the point in my (rather terse) example.

What I was demonstrating is that the expression doesn't just change the contents of the collection, but also the type of the collection itself.  For example:

val bitSet = BitSet(1,2,3) //a BitSet can only hold integers, it subclasses Set[Int]

val res1 = bitSet map {2*} //BitSet(2,4,6)

val res2 = bitSet map {_.toString} //Set("1","2","3") BitSets can't hold strings, so returns a Set[String], as per the Liskov Substitution Principle. 

val myMap = Map(1 -> "x", 2 -> "y", 3 -> "z") //a Map[K,V] is also a collection of K->V pairs

val res3 = myMap map {x => x._1.toString -> x._2} //Map("1"->"x","2"->"y","3"->"z"), a Map[String, String]

val res4 = myMap map {case (a,b) => a.toString -> b} //more readable via pattern matching

val res5 = myMap map {_._1} //List(1,2,3), a List[Int]

val res6 = myMap map {_._2} //List("x","y","z"), a List[String]

This is all 100% safe and statically typed, and is made possible by the "scary" CanBuildFrom implicit parameter that Stephen mention in his article.

I don't believe that Fantom can do this, not least because it doesn't have highly-optimised collection types such as BitSet, it doesn't consider Maps to subclass collections of pairs, and it doesn't support creation of your own paramaterised collection types.  So far as I'm aware, Scala is the only language in existence that directly supports such a scheme (though I imagine it would be totally possible to duplicate using something like Lisp macros)

It looks threatening in the documentation, but when you actually use this stuff it's really quite effortless.  The best part is that these collections are defined entirely in library code using completely standard syntax without a single line of compiler support required.  Anybody could have implemented them without touching the compiler, and it's completely possible to implement your own collection types that fit transparently into this hierarchy (although you *do* have to understand the full method signatures at that point)

2011/11/24 Cédric Beust ♔ <ced...@beust.com>

[Paul King]

Very nice examples but perhaps better to lose the reference to "LSP"
or make it clearer?
If the next line after setting res2 is: assert(res2.isInstanceOf[BitSet])
then I don't quite get substitutable behavior if I am expecting a BitSet.
LSP within certain bounds for sure but not blanket LSP.

Also, I am not sure what you mean by "100% safe". Perhaps you mean
statically type-checked according to the scala type system (which is what
you kind of say later in the same sentence - which I think sums it up nicely
and adequately).

Not trying to nit-pick. I just find type-safety to be a small subset of the
potentially desirable properties of programs. I would hate someone to
think that any program I wrote was "100% safe" just because it compiled
or met some type systems constraints.

Cheers, Paul.

[Kevin Wright]

What LSP essentially states is that because a BitSet is-a Set, then it should be transparently usable everywhere that a Set is valid.

One possible operation on a Set[T] is to convert all members to strings, yielding a Set[String].  A naive implementation of BitSet would only support a map(fn: Int => Int) operation, thus breaking the LSP.

The pre-2.8 version of the Scala collection library achieved this by overloading the method and calling the Set or BitSet version as appropriate, the problem with this approach is that it led to a LOT of code duplication and rapidly became a testing/maintenance nightmare.  The current design allows for behaviour to be defined in a very generic form at a high level in the collections hierarchy, which means that all collections can benefit from the rich set of operations available without having to extensively copy+paste code.

There's an alternative approach in which you state that a BitSet is implicitly convertible to a Set, and therefore there's no subclassing relationship between the two.  It has different trade-offs and can lead to cleaner designs, but unfortunately can't be made to work in Scala; an implicit conversion will only kick in where a method doesn't exist at all, not just because it doesn't exist with a given signature.

Such logic *could* be implemented, but would be sub-optimal on the JVM and would carry a certain performance cost.  It also doesn't play along very nicely in the presence of mutable objects.

[Simon Ochsenreither]

Q.E.D.

http://blog.joda.org/2011/11/scala-ejb-2-feedback.html

[JodaStephen]

Hi Dick,
Just wanted to say publicly that I checked both the "pending" and
"spam" sections of Blogger's comments when Cedric mentioned it to me
yesterday and I didn't find any post from you. What happened? Sadly,
I've no idea. I can happily say that I've never censored an opinion on
my blog and the only things I've ever deleted were clear link spam.
Hopefully allowing a comment calling me an "old twat" goes some way to
evidencing this, although if I were in your position I'd be equally as
annoyed.

Anyway, I'm very glad your response got through in the end, as it is a
good contribution to the debate (and I guess I should really have
checked this list earlier!!!).

thanks,
Stephen
(I'll avoid responding to comments from others here, mostly because
I've had my say now in the main piece and the follow up
http://blog.joda.org/2011/11/scala-ejb-2-feedback.html . Its now for
others to comment, think and decide)

On Nov 23, 2:41 pm, Dick Wall <dickw...@gmail.com> wrote:
> I am a little disappointed that despite writing two polite and on-message
> responses to the article, Stephen has decided not to show those in the
> comments apparently. I am disappointed but not entirely surprised that his
> message is being controlled in this way. Stephen, I don't know if you still
> read the Java Posse group, but if you do, can you let me know why my
> responses were not published in the comments, and whether you want any
> changes to them in order to show them? Thanks.
>
> Dick

[Fabrizio Giudici]

"You know who else compared Scala with EJB? Hitler.
Runar Oli tweet (which I took in good humour)"

LOL

[Cédric Beust ♔]

On Thu, Nov 24, 2011 at 1:28 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

This is all 100% safe and statically typed, and is made possible by the "scary" CanBuildFrom implicit parameter that Stephen mention in his article.

I don't believe that Fantom can do this

It depends on what you mean by "this", but the answer is that Fantom certainly can (as can all these other languages I'm sure). I'm providing the code below and not here since I don't want to turn this into a Scala vs/ Fantom debate, which is not the point I'm trying to make here. In this particular example, you're just morphing one map into another, which is really trivial. Admittedly, Fantom requires to declare a new map and then adding the new content to that map, but you will probably do that in Scala as well if you want to reuse that result (which I bet you would in a real program and not a code golf).

 

, not least because it doesn't have highly-optimised collection types such as BitSet

Maybe, maybe not. Optimized libraries are a separate topic from language comparisons.

The bottom line here, again, is that implicit CanBuildFroms and other subtleties are a very specific implementation detail in Scala that are not necessary for languages that followed a different path to build their type system.

By the way, I don't think the Liskov Substitution Principle is applicable here since a function taking a Map[Int,String] will certainly not be happy if you pass it a Map[String,String].

 

, it doesn't consider Maps to subclass collections of pairs

True, but this seems is a collection design choice, not a language feature (I like it, personally).

 

, and it doesn't support creation of your own paramaterised collection types.  So far as I'm aware, Scala is the only language in existence that directly supports such a scheme (though I imagine it would be totally possible to duplicate using something like Lisp macros)

I don't think so but if I misunderstood your point, feel free to clarify.

Finally, the code to morph the map:

    aMap := [1:"x", 2:"y", 3:"z"]

    // Create an empty map

    map2 := [:]

    // Create the map ["1":"x", "2":"y", "3":"y"]

    aMap.each |v,k| { map2[k.toStr] = v }

    // map2 is now a [Str:Str]

    echo(map2)

-- 

Cédric

[Simon Ochsenreither]

Hi,

No, sorry, but you still miss the point.

The thing Kevin tries to explain is that the collection methods are far more flexible, because they can select the “next best available” type if the “best available” type just doesn't exist.
This occurs in “the real world” (BitSet, String, ...) and that's why it is solved in the standard library instead of pushing the work to the developers.

To my knowledge no other language out there goes to this great lengths to make this work as developers expect (most accurate return types, collections integrating with non-collection types, ...), but I will be happy to get corrected.

So the reasons for all the CanBuildFrom stuff are very pragmatic and practical ones. If those “Scala type theorists” would really live in some academic ivory tower (as some people suggest) the “simple” signatures would certainly be “good enough”.

Hope this helps a bit.

Thanks and bye,

Simon

[Kevin Wright]

I guess the elephant in the room is mutability.  Whereas the Scala code I quoted will take an immutable map and result in an immutable map, your fantom equivalent is obviously relying on externally visible mutability to provide equivalent behaviour.  I certainly wouldn't feel comfortable passing this on to multiple other threads.

Does Fantom have some form of map builder available, or a way of pinning down this map once constructed without incurring the cost of copying it to a dedicated immutable collection?  For some of the larger data sets I need to work on, the performance cost of cloning to ensure thread-safety would be a deal breaking concern.

2011/11/24 Cédric Beust ♔ <ced...@beust.com>

[Ricky Clarkson]

Kevin, you know that people do manage with mutable values as if they
were immutable pretty often. I actually only found out that
java.util.Date was mutable recently (or I forgot at some point) and
have been treating it as immutable all these years.

Perhaps there's someone maintaining some code I wrote who is cursing
me now for relying on Date being immutable, I don't know.

Even without that ignorance, not changing values you don't 'own' can
work, just as in C you free() only values you 'own'. Defensive
copying isn't actually necessary. All that said, I prefer the
guarantees immutability can give you, but without immutability I
wouldn't automatically start copying everything around, making method
calls O(n) unnecessarily.

[Kevin Wright]

Mutable Dates are actually the lesser evil here, it's when you try to use the same instance SimpleDateParser on multiple simultaneous threads that you feel the real pain.  It certainly looks like something you could think of as a pure function from String => Date, but uses non-thread-safe internally mutable state (and possibly dragons) within...

Ironically, it's Stephen who's one of the heros in leading Java out of that quagmire by writing joda-time.  I guess this is one of the reasons why I find it so bewildering that he's now bashing Scala.  More than any other language on the JVM which is seeing mainstream adoption, it embraces the same ideals of immutability that he once championed, even to the point that the core of the standard collections library builds upon the same concepts.

Granted, some of the resulting mechanisms and method signatures needed to make it all work intuitively can seem bewildering, especially to the newcomer.  But the Typesafe team and community are working hard to hide that necessary plumbing by default from both the Scaladoc and IDE auto-completion.

[Cédric Beust ♔]

On Thu, Nov 24, 2011 at 3:42 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

it embraces the same ideals of immutability that he once championed

We already went through this, Scala "the language" does very little to enforce immutability. Hardly more than Java.

-- 

Cédric

[Kevin Wright]

C'mon!

1. Open a fresh scala REPL. No imports, no other lines of code, just a clean standard REPL

2. val m = Map(1->"a",2->"b",3->"c")
3. Your challenge, should you accept it, is to manipulate m in such a way as to change its value

3a. and no, creating a new m doesn't count

2011/11/25 Cédric Beust ♔ <ced...@beust.com>

[Takeshi Fukushima]

how about reflection? 

I'm joking of course so more to the point: those seems to be examples of how the library encourages you to use immutable data structures whereas what Cedric seems to be implying is that the language itself doesn't (or that is how i read his response anyway)

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima

[Ricky Clarkson]

That's encouraging, not enforcing. Nothing stops you from importing
the mutable map type. All you showed is that your code sample uses an
immutable type.

[Kevin Wright]

You can change everything with reflection, even the interned values for strings and boxed integers.  This is a good one to hold in reserve for April fools day...  If you're going to reflect then ALL bets are off :)

Otherwise, it's semantics.  method params are immutable unless, the standard keyword for values is "val" (equivalent to final in Java), and collections in the standard library are immutable unless you explicitly import mutable variants.  Yes, *of course* you can choose to use mutable collections or to use vars, this is why I say "encourages" immutability.

If I were to claim that scala "forces" immutability, then the grounds for calling me out on this would be far, far stronger.

Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Ricky Clarkson]

Then in your head there must be more distance between 'enforce' and
'force' than in mine.

[Cédric Beust ♔]

On Thu, Nov 24, 2011 at 5:05 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

That's encouraging, not enforcing.  Nothing stops you from importing
the mutable map type.

Nor using "var" instead of "val".

-- 

Cédric

 

[Cédric Beust ♔]

On Thu, Nov 24, 2011 at 5:11 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Otherwise, it's semantics.  method params are immutable

Same as Java.

 

unless, the standard keyword for values is "val"

And "var" for variables, with Scala not encouraging either over the other.

 

(equivalent to final in Java), and collections in the standard library

They are collections, so irrelevant since we're talking about the language.

Like I said, we already went through this.

-- 

Cédric

[Ricky Clarkson]

Method parameters are not immutable in Java without the final keyword.

2011/11/24 Cédric Beust ♔ <ced...@beust.com>:

[Paul King]

Fun exercise - someone who knows Scala can probably do better - of
course you could hide all this away in a library and make it really
easy if you wanted:
val m = Map(1->"a",2->"b",3->"c")val field =
m(1).getClass.getDeclaredField("value")field.setAccessible(true)val
mods = field.getClass.getDeclaredField("modifiers")mods.setAccessible(true)mods.setInt(field,
field.getModifiers & ~java.lang.reflect.Modifier.FINAL)field.set(m(1),
field.get(m(2)))println(m)// => Map(1 -> b, 2 -> b, 3 -> c)

[Paul King]

Fun exercise:

val m = Map(1->"a",2->"b",3->"c")

val field = m(1).getClass.getDeclaredField("value")

field.setAccessible(true)

val mods = field.getClass.getDeclaredField("modifiers")

mods.setAccessible(true)

mods.setInt(field, field.getModifiers & ~java.lang.reflect.Modifier.FINAL)

field.set(m(1), other.get(m(2)))

println(m)

// => Map(1 -> b, 2 -> b, 3 -> c)

2011/11/25 Cédric Beust ♔ <ced...@beust.com>:

[Paul King]

Sorry about the formatting glitches, trying again:

val m = Map(1->"a",2->"b",3->"c")

val field = m(1).getClass.getDeclaredField("value")
field.setAccessible(true)
val mods = field.getClass.getDeclaredField("modifiers")
mods.setAccessible(true)
mods.setInt(field, field.getModifiers & ~java.lang.reflect.Modifier.FINAL)

field.set(m(1), field.get(m(2)))

[Kevin Wright]

I'd argue that it's unlikely and uncommon for that to happen without thinking.  A language doesn't exist in isolation from its ecosystem, and nobody learns a new language without working from examples, books, etc...  Everything currently out there for Scala advocates using val as a preference.

The mere fact of having val/var also forces you into making a choice, so you have to actively think about what you need.  Given all the learning resources currently available, this means that developers generally *will* favour vals without good reason not too.

Contrast this approach to Java in which "final" is very much an optional extra prefix, you're not forced into making an explicit final/non final decision when declaring a value, and it's incredibly easy to just leave out the keyword unless you're being remarkably self-disciplined or are frequently leaning on static analysis tools to constantly (no pun intended) remind you.

Worse still, "final" just seems to add extra verbosity and boilerplate (especially on method params), developers are forced to make a trade-off between making their code immutably safe, or making it cleaner and more lightweight.  The language actively DIScourages immutability.

So by comparison, yes, Scala does encourage immutability.

2011/11/25 Cédric Beust ♔ <ced...@beust.com>

-- 

Cédric

 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

For bonus points, use JNI and do it in C/C++

Seriously though, all bets are off in the face of reflection.  It can cut right through anything marked as final in bytecode, and no immutability guarantees made by *any* JVM language can be relied upon when reflection is being used to subvert the system.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ben Schulz]

Well, that's not quite true. Static final fields actually are
final[1]. That means one could create an immutable object by
generating a class and stuffing the values in static fields. Obviously
that's not a viable route to take, but I hear there are bonus points
to be had.. :D

With kind regards
Ben

[1] Of course this does not hold for System.out, System.in and
System.err.

[Fabrizio Giudici]

On Fri, 25 Nov 2011 21:31:37 +0100, Ben Schulz <ya...@gmx.de> wrote:

> Well, that's not quite true. Static final fields actually are
> final[1].

I didn't check the specs... but are you sure? Because people tend to
consider them unmodifiable "also by reflection" just because they are
inlined by the compiler (a thing that can be worked around, BTW). I could
be wrong, but I'd say they are just fields as others, and final (other
than a compiler syntax) is a bit in the VM that could be possibly
dynamically modified?

[Ben Schulz]

As far as I am aware there is no (Java-standard-compliant) way to
change the value of static final fields (excepting of course the
previously noted System.in, out and err). And as far as the JVM is
concerned the same holds true for non-static final fields. Just
recently Cliff Click wrote two blog posts about that[1,2].

With kind regards
Ben

[1]: http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
[2]: http://www.azulsystems.com/blog/cliff/2011-10-27-final-fields-part-2

On 27 Nov., 13:23, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:

> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it

[Fabrizio Giudici]

On Sun, 27 Nov 2011 14:20:17 +0100, Ben Schulz <ya...@gmx.de> wrote:

> As far as I am aware there is no (Java-standard-compliant) way to
> change the value of static final fields (excepting of course the
> previously noted System.in, out and err). And as far as the JVM is
> concerned the same holds true for non-static final fields. Just
> recently Cliff Click wrote two blog posts about that[1,2].
>
> With kind regards
> Ben
>
> [1]:
> http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
> [2]: http://www.azulsystems.com/blog/cliff/2011-10-27-final-fields-part-2

Some people argue the opposite:

http://stackoverflow.com/questions/2474017/using-reflection-to-change-static-final-file-separatorchar-for-unit-testing

Didn't find the time to try it, though.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."

[opinali]

Even if this works, be warned that static final fields are special in that the JVM is allowed to make static constant-propagation optimization, at least for fields of primitive types, without any guard code. So if you have some code like "if (DEBUG) {...}" and DEBUG==false at the time this code is first executed, the VM will obliterate that code to nothingness - this is guaranteed by spec, it's the only way to obtain conditional compilation in Java. (I think even the interpreter will do this, no need to wait for JIT.) Even if afterwards you change DEBUG to true (JNI will certainly work as a last resort), that CSE-optimized code will *not* be recompiled to be consistent with the new value.

A+

Osvaldo

[Fabrizio Giudici]

On Sat, 03 Dec 2011 02:03:12 +0100, opinali <opi...@gmail.com> wrote:

> Even if this works, be warned that static final fields are special in
> that
> the JVM is allowed to make static constant-propagation optimization, at
> least for fields of primitive types, without any guard code. So if you
> have
> some code like "if (DEBUG) {...}" and DEBUG==false at the time this code
> is
> first executed, the VM will obliterate that code to nothingness - this is
> guaranteed by spec, it's the only way to obtain conditional compilation
> in
> Java. (I think even the interpreter will do this, no need to wait for
> JIT.)
> Even if afterwards you change DEBUG to true (JNI will certainly work as a
> last resort), that CSE-optimized code will *not* be recompiled to be
> consistent with the new value.

The discussion about reflection and constants was merely academical. Of
course changing constants by reflection is bad idea for any practical
purpose.