White Elefant

2011/10/26 Josh Suereth <joshua.suereth@gmail.com>

Java was a *beast* to learn initially.  Lots of odd rules and strange behavior.

Obviously, everybody will have different experiences about the Java learning curve, but I can tell you that after ten years of a very grueling C++ career, Java felt like an immense breath of fresh air and it appeared so downright simple in pretty much all areas that I went through a constant stream of "This is so simple, why didn't anyone do it this way before?". About the syntax, the disappearance of the dichotomy header file/implementation file, the thread library, the standard collection and how simple they were compared to the STL, etc... It wasn't just the syntax, it was the whole platform.
A new language on the JVM will have to hit that mark if it wants to challenge Java's dominance.
-- Cédric

2011/10/26 Cédric Beust ♔ <cedric@beust.com>

2011/10/26 Josh Suereth <joshua.suereth@gmail.com>

Java was a *beast* to learn initially.  Lots of odd rules and strange behavior.

Obviously, everybody will have different experiences about the Java learning curve, but I can tell you that after ten years of a very grueling C++ career, Java felt like an immense breath of fresh air and it appeared so downright simple in pretty much all areas that I went through a constant stream of "This is so simple, why didn't anyone do it this way before?". About the syntax, the disappearance of the dichotomy header file/implementation file, the thread library, the standard collection and how simple they were compared to the STL, etc... It wasn't just the syntax, it was the whole platform.
A new language on the JVM will have to hit that mark if it wants to challenge Java's dominance.

Sure.  I'm using Scala because it does.   Feel free to use Java.  It's good for what it is.   No one is forcing you to learn Scala.

I have to agree with that.

I had the pleasure to try to teach java to a mixture of complete
programming newbies and old school C and COBOL programmers about a
decade ago, when I could not find better work due to the end of the
dotcom boom. It was quite an interesting experience.

Obviously I would start with a standard hello world program. The
amount of concepts you have to explain for the simple hello world
program is staggering. And then you always had so many exceptions.
Everything is an object. Except primitive types, which are not. This
wouldn't be so bad if primitives were some obscure part of the
language that you could ignore in the beginning. But they are pretty
much the first thing people will be confronted with.

Then you have to explain that all functions are part of an object, and
you have another exception for static methods. Again, this is not
something you can delay explaining, because the very first method
people are confronted with is a static method.

I ended up telling people that they should just ignore the noise and
that I would explain it later, but that is not very satisfactory from
a teaching point of view. The C and COBOL programmers would obviously
understand static fields and methods and immediately go to work,
ignoring all that newfangled object oriented stuff.

I think it would be quite interesting to try to teach scala to a
complete programming newbie without any java or C baggage. I could try
with my son, but I guess 11 months is a bit early... :-)

cheers

Rüdiger

2011/10/26 martin odersky :
>
>
> 2011/10/26 Cédric Beust ♔
>>
>> On Wed, Oct 26, 2011 at 8:00 AM, martin odersky
>> wrote:
>>>
>>> No, I mean if I have to teach hello world, compare
>>>
>>>   object Hello extends App {
>>>     println("hello world!")
>>>   }
>>>
>>> to its Java equivalent. How much do you have to explain? Or can you get
>>> away with saying: these are incantations that you just need to write, not
>>> understand? What feeling does that give to a newbie?
>>
>> Not to belabor this particular point, but yes, there is just as much to
>> explain to a beginner about the example above ("object", "extends" and
>> "App", and what's in App, and how come the example doesn't work if you
>> forget to extend, etc...) as with Java's main.
>
> I definitely disagree with that.
> class    -- need to explain what a class is, and why Hello is not really one
> (because no instances are ever created)
> public   -- need to explain privacy levels
> static    -- what the heck is that?
> void      -- void???
> main     OK, I might get that
> String[] -- need to explain irregular array syntax
> args     -- need to explain command line arguments
> Compare that to:
> object Hello   -- need to explain what objects are, it's definitely simpler
> than classes!
> extends App -- need to explain that Hello an instance of an `App', i.e.
> something that can be run.
> That's all. It's no contest really. The only way you could claim that java
> is as simple is if you take everything in Java for granted. I guess I have
> started working with Java earlier than you have, and I can tell you that for
> teaching the Hello world problem was a big deal. It eventually went away
> once everyone took Java for granted. But that does not mean that the problem
> does not exist, only that we do not see it anymore.
> Cheers
>  -- Martin
>
>

In my experience, COBOL programmers had an easier time understanding Scala than Java.

On Thu, Oct 27, 2011 at 10:13 AM, Rüdiger Klaehn <rklaehn@googlemail.com> wrote:

I have to agree with that.

I had the pleasure to try to teach java to a mixture of complete
programming newbies and old school C and COBOL programmers about a
decade ago, when I could not find better work due to the end of the
dotcom boom. It was quite an interesting experience.

Obviously I would start with a standard hello world program. The
amount of concepts you have to explain for the simple hello world
program is staggering. And then you always had so many exceptions.
Everything is an object. Except primitive types, which are not. This
wouldn't be so bad if primitives were some obscure part of the
language that you could ignore in the beginning. But they are pretty
much the first thing people will be confronted with.

Then you have to explain that all functions are part of an object, and
you have another exception for static methods. Again, this is not
something you can delay explaining, because the very first method
people are confronted with is a static method.

I ended up telling people that they should just ignore the noise and
that I would explain it later, but that is not very satisfactory from
a teaching point of view. The C and COBOL programmers would obviously
understand static fields and methods and immediately go to work,
ignoring all that newfangled object oriented stuff.

I think it would be quite interesting to try to teach scala to a
complete programming newbie without any java or C baggage. I could try
with my son, but I guess 11 months is a bit early... :-)

cheers

Rüdiger

2011/10/26 martin odersky <martin.odersky@epfl.ch>:
>
>
> 2011/10/26 Cédric Beust ♔ <cedric@beust.com>
>>
>> On Wed, Oct 26, 2011 at 8:00 AM, martin odersky <martin.odersky@epfl.ch>
>> wrote:
>>>
>>> No, I mean if I have to teach hello world, compare
>>>
>>>   object Hello extends App {
>>>     println("hello world!")
>>>   }
>>>
>>> to its Java equivalent. How much do you have to explain? Or can you get
>>> away with saying: these are incantations that you just need to write, not
>>> understand? What feeling does that give to a newbie?
>>
>> Not to belabor this particular point, but yes, there is just as much to
>> explain to a beginner about the example above ("object", "extends" and
>> "App", and what's in App, and how come the example doesn't work if you
>> forget to extend, etc...) as with Java's main.
>
> I definitely disagree with that.
> class    -- need to explain what a class is, and why Hello is not really one
> (because no instances are ever created)
> public   -- need to explain privacy levels
> static    -- what the heck is that?
> void      -- void???
> main     OK, I might get that
> String[] -- need to explain irregular array syntax
> args     -- need to explain command line arguments
> Compare that to:
> object Hello   -- need to explain what objects are, it's definitely simpler
> than classes!
> extends App -- need to explain that Hello an instance of an `App', i.e.
> something that can be run.
> That's all. It's no contest really. The only way you could claim that java
> is as simple is if you take everything in Java for granted. I guess I have
> started working with Java earlier than you have, and I can tell you that for
> teaching the Hello world problem was a big deal. It eventually went away
> once everyone took Java for granted. But that does not mean that the problem
> does not exist, only that we do not see it anymore.
> Cheers
>  -- Martin
>
>

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Ok, I’m starting to feel scared. That code actually looks fairly understandable to me.

 

Peter

 

From: scala-debate@googlegroups.com [mailto:scala-debate@googlegroups.com] On Behalf Of Razvan Cojocaru
Sent: Wednesday, October 26, 2011 13:38
To: 'martin odersky'
Cc: 'Kevin Wright'; 'scala-debate'
Subject: RE: [scala-debate] Re: [scala-user] White Elefant

 

 

trait *->*->** { implicit def *->*->** [A, F[_,_], B](a: F[A,b]): *->*->*[A, F, B] = new *->*->*[A, F, B] { val value = a } }

 

 

2011/10/27 Cédric Beust ♔ <cedric@beust.com>

2011/10/26 Josh Suereth <joshua.suereth@gmail.com>

Java was a *beast* to learn initially.  Lots of odd rules and strange behavior.

Obviously, everybody will have different experiences about the Java learning curve, but I can tell you that after ten years of a very grueling C++ career, Java felt like an immense breath of fresh air and it appeared so downright simple in pretty much all areas that I went through a constant stream of "This is so simple, why didn't anyone do it this way before?". About the syntax, the disappearance of the dichotomy header file/implementation file, the thread library, the standard collection and how simple they were compared to the STL, etc... It wasn't just the syntax, it was the whole platform.

I felt the same thing then.  And the platform has more than lived up to its initial promise. In fact it is a part of the platform's appeal that it allows languages different than Java to run well on it.

Cheers

-- Martin

On Thu, Oct 27, 2011 at 09:15, Peter C. Chapin wrote:
> Ok, I’m starting to feel scared. That code actually looks fairly
> understandable to me.

Here's the deal: this code was picked because it is short on words and
heavy on symbols. HOWEVER, it follows a very standard notation used to
describe higher order types, the notation for kinds:
http://en.wikipedia.org/wiki/Kind_(type_theory).

So, let's say you say a Java code like this:

for (String item : items) {
count++;
}

On the face of it, that code is incomprehensible. You have to
understand the notations -- you have to understand that "for" is
followed by two "blocks" of different, and particular meanings, and
that it repeats some code. You have to understand the "Type
identifier" pattern, you have to understand what ":" stands for in
this context, you have to understand "++", you have to understand
what's the meaning of ";". Once you do that, then the code is obvious.

The same things goes with that code. Even though it is missing a whole
class or trait -- very fundamental to the code in question, * -> * ->
* has a very clear meaning when it comes to kinds, and not a
particularly difficult one.

I Cannot comprehend this view. After more than 10 years of Java I stil don't feel like I understand the language in detail, i still feel like having a hand tied behind my back, I badly miss C++ (or did until scala came along)...
Yes... No header files, but the verbosity and lack of paradigms more than compensates for that... I also think my IQ dropped significantly because of the more typing than thinking needed in Java...
It's just how I feel and I know I'm in the minority on that, but still can't comprehend the opposite view...

Thanks,Razvan
On 2011-10-26, at 9:14 PM, Cédric Beust ♔ <cedric@beust.com> wrote:

2011/10/26 Josh Suereth <joshua.suereth@gmail.com>

Java was a *beast* to learn initially.  Lots of odd rules and strange behavior.

Obviously, everybody will have different experiences about the Java learning curve, but I can tell you that after ten years of a very grueling C++ career, Java felt like an immense breath of fresh air and it appeared so downright simple in pretty much all areas that I went through a constant stream of "This is so simple, why didn't anyone do it this way before?". About the syntax, the disappearance of the dichotomy header file/implementation file, the thread library, the standard collection and how simple they were compared to the STL, etc... It wasn't just the syntax, it was the whole platform.
A new language on the JVM will have to hit that mark if it wants to challenge Java's dominance.
-- Cédric

Do you see the typo, then? :)

  --Rex

P.S. I'm almost positive it is a typo, but without more context I can't be 100% sure.

On Thu, Oct 27, 2011 at 7:15 AM, Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:

Ok, I’m starting to feel scared. That code actually looks fairly understandable to me.

 

Peter

 

From: scala-debate@googlegroups.com [mailto:scala-debate@googlegroups.com] On Behalf Of Razvan Cojocaru
Sent: Wednesday, October 26, 2011 13:38
To: 'martin odersky'
Cc: 'Kevin Wright'; 'scala-debate'
Subject: RE: [scala-debate] Re: [scala-user] White Elefant

 

 

trait *->*->** { implicit def *->*->** [A, F[_,_], B](a: F[A,b]): *->*->*[A, F, B] = new *->*->*[A, F, B] { val value = a } }

 

 

See, Scala is a language just for children...

Just kidding :-)

When I was his age I was still stuck with Basic, Fortran, etc., but I did get to play with APL.

I seem to recall that when children were first exposed to SmallTalk they took to it readily, much more so than other languages.

Maybe this means that all us old fart programmers will lose our jobs to young people like this who have young open minds able to grok Scala early on. At least this means there will be more job opportunities for young people who have been complaining there are no job futures for them. It seems to me Scala is doing it's part for the 99%

By the was - this post was intended to be humor :-)

Cheers, Eric

On 2011-10-26 6:14 AM, martin odersky wrote:

CAENVNkb5qkhCCirRS+VDy-NXrvpyjqgnFy_zCdoojc7q6a_rhQ [at] mail [dot] gmail [dot] com" type="cite">For a great counter-argument to the original post, see:

  http://www.youtube.com/watch?v=6RwrT6N43lY

Cheers

 -- Martin

On Wed, Oct 26, 2011 at 2:52 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com" rel="nofollow">kev.lee.wright@gmail.com> wrote:

On 26 October 2011 13:18, Ittay Dror <ittay [dot] dror [at] gmail [dot] com" target="_blank" rel="nofollow">ittay.dror@gmail.com> wrote:

Josh Suereth wrote:

On Wed, Oct 26, 2011 at 2:49 AM, Roland Tepp <luolong [at] gmail [dot] com" target="_blank" rel="nofollow">luolong@gmail.com> wrote:

Why, yes, in the essence.
Quantum model is much simpler than Newtonian, as it manages to use one mathematical model to explain more phenomenons than the ones it replaced...

On the other end though, conceptually, the Quantum theory is much more difficult to grok than Newtonian physics, as the interactions it concerns itself with may seem somewhat unintuitive at first...

(btw - I am no physics expert, so my understanding of the fine detils is limited)

Huh, that sounds just like Scala.   It uses *one* model (say pattern matching) to express something and then you use that in many places, vs. lots of diverse strange rules (Java).   I think the comparison to Scala holds well, IMHO.   Lots of simple concepts (that may be hard to grok initially) working together.

Let's face it. Scala is complex. If it weren't, we wouldn't have needed to debate so much about it.

About Java's diverse rules. It is true that Java has a lot of corner cases. The sort that makes the spec big and gives a lot of fodder for things like Java Puzzlers. But the thing is, they are rare corner cases. The sort you don't encounter every day, or ever. On the other hand, Scala's spec is very clean, and there are far less corner cases, but it is because the concepts are harder to digest (at least to those whose mind is already wired for C/C++/C#/Java). Sometimes it's like making everything a corner.

I love Scala, it's a great language. Once I got the concepts I am able to do things I'd never think about in Java. But we should not kid ourselves that there's no barrier.

Ittay

But that's the rub...
Is this "barrier" something inherent to Scala, or something created by Java's vehement refusal to allow lambdas and functions as first-class entities, thereby denying millions of developers exposure to a whole class of solutions?
Scala's complex in the same way as Greek is complex. My first language was English and so I find that conjugation and gendered objects are really hard concepts to fit into my mental model.  These ideas aren't inherently difficult, billions of non-geniuses and non-academics can effortlessly speak conjugated languages every day.  The problems aren't a property of the language, they're only difficult concepts for people to whom they are foreign.
On the other hand... Greek is simple, because it has a strong relationship between how a word is spelled and how it's pronounced, invaluable to any learner.  This *is* an inherent property of Greek, and not the would-be learner.
Feel free to expand the metaphor (which is a Greek word) as you see fit :)

 

- Josh 

kolmapäev, 26. oktoober 2011 3:25.45 UTC+3 kirjutas Michael Thorpe:

The quantum model is simpler than the Newtonian model?

On 26 Oct 2011, at 01:10, stuart gordon <stuart...@hotmail.co.uk> wrote:

Hi,

I am a lot older that most of you out there and I have seen a lot of changes in computing in general. I was a Java programmer and trainer.
I am now looking at Scala and functional programming but I am now really doubting much that has been said about this language and the use of functional language.

Industry simplifies tools and process with time in all walks of life. It doesn't complicate them and doesn't lend to complicating the processes.
Copernicus  displaced the earth centric ideas; Quantum displaces or enhances Newtonian, Euclidean models. Every model is simpler.
Scala is the opposite. Now you are relying on very talented programmers who have to limit their semantics to make programs work.
The very power that leverage's Scala is its weakness, because to test it, is almost impossible and very difficult.
It relies on good programming practise  to write good programs. Even syntactically it is untidy.
This has not been the trend in software. The trend is to make it more simple, robust and hopefully more error free.
Scala with lazy evalution and psuedofuntional programming opens a minefield that will cost in production and in maintenance.
Even the code will have to take into account the behaviour of tail end recursion and optimising strategies. This should be done by the compiler, and run time virtual machines and with hooks into the OS.
Surely this should be transparent to any programming language.

OO simplifies the real domain model to the machine image. Scala does not.

I think most Scala will be unmaintainable and unpredictable.

The future will see programming languages change but Scala isn't going to be one of them. Compilers, virtual machines and therefore ultimately the OS will do some of the work to make programming easier with multi threading and multi core.
Think about parallel communication which is now replaced with a simple serial interface. Things get simpler not more elaborate.

Why is it popular. Because academics want to have an interesting time but are not really interested in real world problems. Every one thinks its going to be the paradigm shift like OO was to procedural; it  never will be.
Students think it cool or clever to do it. So is chess but for the most wont provide bread and butter on the table.  Its a dangerous fad that will produce horrible code like concrete did with architecture in the 1960´s.

Very, very sceptical.

Lunalobo

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

2011/10/26 Cédric Beust ♔ <cedric@beust.com>

Maybe for someone who's never programmed in their life, but I bet that most people who started programming in Java had some prior exposure to C and/or C++, so I still think the description above is vastly overblown.

I seriously doubt that. That may have been true 15+ years ago, but Java (and C#) are being taught as a first language in high schools now. I know we were taught it and we had exactly the problems Martin described; lots of confused kids. Our teacher dismissed it as just magic that we needed to do regardless. My young cousin is being taught C# in his high school and he has exactly the questions Martin described.
Languages like Python and Scala (if used as a scripting language) let people drop the cruft and work their way up a shallower learning curve.

Vista???

What about Microsoft C++, MFC, COM!!!, Visual Studio, Windows 7 Search, SharePoint, Office, Windows 8 Tiles, etc.?

Look at almost everything Microsoft does - it simply grows more and more complex over time. If it were not for Java, Microsoft COM might still be the dominant platform today, and we would all take twice as long to produce half as many features with twice as many defects.

If anyone seriously thinks that Scala is 'too complex' they need to spend a few years as a C++ COM ATL programmer.

.NET = Java + Standard Microsoft Frivolous Complexity

Cheers, Eric

On 2011-10-26 8:29 AM, Trond Olsen wrote:

CAMaY-vv+5Uws0E9HHe-fTop7+sht2gGxbjCaNvhUpiSeB0RhTg [at] mail [dot] gmail [dot] com" type="cite">How did Microsoft manage to produce Vista?

On 26 October 2011 02:10, stuart gordon <stuartgordon [at] hotmail [dot] co [dot] uk" rel="nofollow">stuartgordon@hotmail.co.uk> wrote:

Industry simplifies tools and process with time in all walks of life.

I agree Scala should be taught in high-school at least, and elementary school if possible. That is when young minds are really open to new things. Learning Scala then would also give many kids a better grounding in Mathematics, especially if they go on to University.

My personal experience with Java was that it was trivial to learn initially. This was because I was a long time C programmer, as well as C++ and Objective-C. Compared to C++ Java was trivial and made way more sense. Compared to Objective-C, it was just as neat and simple, but also had garbage collection, which was seriously missing in Objective-C.

Today I am increasingly getting frustrated with Java, but that is mostly because as I learn Scala better, when I am writing Java code I routinely know how I would do something in Scala, but I am at a loss of how to do it elegantly in Java.

Cheers, Eric


On 2011-10-26 6:01 PM, Josh Suereth wrote:

CAFLqJkyXx9m8P-R056CTPfcMcpnc4hWK5nRMGXaLKm4sZUogMg [at] mail [dot] gmail [dot] com" type="cite">I think Scala aims at being simple.  Not being simple for java developers.   Long term vision here.
Scala isn't trying to replace Java, Scala is trying to *be a general purpose programming language on the JVM*.   The fact that a lot of folk are moving from Java to Scala is a sign of pain in Java that's causing the to move to Scala.   But let's get this straight:
Scala needs to attract the young generation more than the older generation for long term success.   If we can attract children, they'll be comfortable with Scala, hopefully some FP and it's a big win for education everywhere.   
Java was a *beast* to learn initially.  Lots of odd rules and strange behavior.  I was able to pick up Scala and even write a book on it.  With Java I had to read all the books first, to really 'get it'.  With Scala, things are *much* more consistent in the language so you can focus on the *hard things* like API design, how much abstraction to use and solving real world problems.
In Java, the language always got in the way.   A great example:  I just read through all of JGit's source.  While a well done Java project, the command line library really confused me for a bit until I saw all the magical reflection things happening with annotations.   In Scala I can just pattern match arguments, no need for get opt and friends.
Scala's in it for the long haul.   We need to think past Java.   In fact, in Pittsburgh at least, the competition is trying to get people to move to Scala from C#.  They've already left the JVM....
- Josh


2011/10/26 Cédric Beust ♔ <cedric [at] beust [dot] com" rel="nofollow">cedric@beust.com>

2011/10/26 martin odersky <martin [dot] odersky [at] epfl [dot] ch" target="_blank" rel="nofollow">martin.odersky@epfl.ch>

I definitely disagree with that. 
class    -- need to explain what a class is, and why Hello is not really one (because no instances are ever created) public   -- need to explain privacy levels  static    -- what the heck is that? void      -- void??? main     OK, I might get that String[] -- need to explain irregular array syntax args     -- need to explain command line arguments

Maybe for someone who's never programmed in their life, but I bet that most people who started programming in Java had some prior exposure to C and/or C++, so I still think the description above is vastly overblown.
Either way, my original point stands: it's really no big deal to tell beginners to not pay attention to some details in the early stages.
--  Cédric

Are you talking about the lower case b in F[A, b]? I figured it was probably supposed to be F[A, B] but who knows… maybe there is a type ‘b’ in scope.

 

Peter

 

From: Rex Kerr [mailto:ichoran@gmail.com]
Sent: Thursday, October 27, 2011 12:16
To: Chapin, Peter @ VTC
Cc: scala-debate@googlegroups.com
Subject: Re: [scala-debate] Re: [scala-user] White Elefant

 

Do you see the typo, then? :)

  --Rex

P.S. I'm almost positive it is a typo, but without more context I can't be 100% sure.

On Thu, Oct 27, 2011 at 7:15 AM, Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:

Ok, I’m starting to feel scared. That code actually looks fairly understandable to me.

 

Peter

 

From: scala-debate@googlegroups.com [mailto:scala-debate@googlegroups.com] On Behalf Of Razvan Cojocaru
Sent: Wednesday, October 26, 2011 13:38
To: 'martin odersky'
Cc: 'Kevin Wright'; 'scala-debate'
Subject: RE: [scala-debate] Re: [scala-user] White Elefant

 

 

trait *->*->** { implicit def *->*->** [A, F[_,_], B](a: F[A,b]): *->*->*[A, F, B] = new *->*->*[A, F, B] { val value = a } }

 

 

 

This is a very interesting discussion! Thank you all for the different
insights offered here.

I would like to pour in a couple of my own personal thoughts. I have
been a fairly long time Java developer and still do a fair bit of
Java. I have also done a bit of Ruby (Rails really) and C# before I
tried my hands on Scala. There are some great things about Scala that
I absolutely love the language for, but well, I definitely found it a
tad more complex to learn than a RoR. Now this is my personal opinion,
but for the betterment of Scala, may be we should stop comparing it
with Java alone. We should look at Scala from the perspective of what
will make a massively useful language, look at the trends that the
developers across technologies are benefiting from and be still really
easy to learn.

One thing I definitely find lacking in the Scala API documentation is
examples. For example, refer to http://api.rubyonrails.org/classes/ActionMailer/Base.html
or http://api.rubyonrails.org/classes/ActiveRecord/Base.html. Now
while there can not be a direct comparison between rails and scala,
lets just look at the API documentation. The rails document cites
examples of how one could use the API in different cases, something if
added to Scala documentation would make it immensely easier to
leverage. Also, if there could be screen casts like railscasts that
could depict how common coding problems are addressed in scala, I
guess it would help new people learning the language.

just my personal opinion

Best regards
Aishwarya

On Oct 27, 9:43 pm, "Peter C. Chapin" wrote:
> Are you talking about the lower case b in F[A, b]? I figured it was probably
> supposed to be F[A, B] but who knows. maybe there is a type 'b' in scope.
>
> Peter
>
> From: Rex Kerr [mailto:icho...@gmail.com]
> Sent: Thursday, October 27, 2011 12:16
> To: Chapin, Peter @ VTC
> Cc: scala-debate@googlegroups.com
> Subject: Re: [scala-debate] Re: [scala-user] White Elefant
>
> Do you see the typo, then? :)
>
>   --Rex
>
> P.S. I'm almost positive it is a typo, but without more context I can't be
> 100% sure.
>
> On Thu, Oct 27, 2011 at 7:15 AM, Peter C. Chapin
> wrote:
>
> Ok, I'm starting to feel scared. That code actually looks fairly
> understandable to me.
>
> Peter
>
> From: scala-debate@googlegroups.com [mailto:scala-debate@googlegroups.com]
> On Behalf Of Razvan Cojocaru
> Sent: Wednesday, October 26, 2011 13:38
> To: 'martin odersky'
> Cc: 'Kevin Wright'; 'scala-debate'
> Subject: RE: [scala-debate] Re: [scala-user] White Elefant
>
> trait *->*->** { implicit def *->*->** [A, F[_,_], B](a: F[A,b]): *->*->*[A,
> F, B] = new *->*->*[A, F, B] { val value = a } }

FYI, this kind of discussion is best for the scala-debate mailing list :-)

scala-user is best for people who have questions about Scala and need answers.

Cheers, Eric

On 2011-10-25 5:10 PM, stuart gordon wrote:

BAY148-W1F0C74CBD77D50E63002B98ED0 [at] phx [dot] gbl" type="cite"> Hi,

I am a lot older that most of you out there and I have seen a lot of changes in computing in general. I was a Java programmer and trainer.
I am now looking at Scala and functional programming but I am now really doubting much that has been said about this language and the use of functional language.

Industry simplifies tools and process with time in all walks of life. It doesn't complicate them and doesn't lend to complicating the processes.
Copernicus  displaced the earth centric ideas; Quantum displaces or enhances Newtonian, Euclidean models. Every model is simpler.
Scala is the opposite. Now you are relying on very talented programmers who have to limit their semantics to make programs work.
The very power that leverage's Scala is its weakness, because to test it, is almost impossible and very difficult.
It relies on good programming practise  to write good programs. Even syntactically it is untidy.
This has not been the trend in software. The trend is to make it more simple, robust and hopefully more error free.
Scala with lazy evalution and psuedofuntional programming opens a minefield that will cost in production and in maintenance.
Even the code will have to take into account the behaviour of tail end recursion and optimising strategies. This should be done by the compiler, and run time virtual machines and with hooks into the OS.
Surely this should be transparent to any programming language.

OO simplifies the real domain model to the machine image. Scala does not.

I think most Scala will be unmaintainable and unpredictable.

The future will see programming languages change but Scala isn't going to be one of them. Compilers, virtual machines and therefore ultimately the OS will do some of the work to make programming easier with multi threading and multi core.
Think about parallel communication which is now replaced with a simple serial interface. Things get simpler not more elaborate.

Why is it popular. Because academics want to have an interesting time but are not really interested in real world problems. Every one thinks its going to be the paradigm shift like OO was to procedural; it  never will be.
Students think it cool or clever to do it. So is chess but for the most wont provide bread and butter on the table.  Its a dangerous fad that will produce horrible code like concrete did with architecture in the 1960´s.

Very, very sceptical.

Lunalobo

That's what I meant.  b is a very strange choice for a type name, and without using it in the argument, the type inferencer would be unlikely to find the correct type for B.
  --Rex

On Thu, Oct 27, 2011 at 12:43 PM, Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:

Are you talking about the lower case b in F[A, b]? I figured it was probably supposed to be F[A, B] but who knows… maybe there is a type ‘b’ in scope.

 

Peter

 

From: Rex Kerr [mailto:ichoran@gmail.com]
Sent: Thursday, October 27, 2011 12:16
To: Chapin, Peter @ VTC
Cc: scala-debate@googlegroups.com
Subject: Re: [scala-debate] Re: [scala-user] White Elefant

 

Do you see the typo, then? :)

  --Rex

P.S. I'm almost positive it is a typo, but without more context I can't be 100% sure.

On Thu, Oct 27, 2011 at 7:15 AM, Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:

Ok, I’m starting to feel scared. That code actually looks fairly understandable to me.

 

Peter

 

From: scala-debate@googlegroups.com [mailto:scala-debate@googlegroups.com] On Behalf Of Razvan Cojocaru
Sent: Wednesday, October 26, 2011 13:38
To: 'martin odersky'
Cc: 'Kevin Wright'; 'scala-debate'
Subject: RE: [scala-debate] Re: [scala-user] White Elefant

 

 

trait *->*->** { implicit def *->*->** [A, F[_,_], B](a: F[A,b]): *->*->*[A, F, B] = new *->*->*[A, F, B] { val value = a } }

 

 

 

2011/10/27 martin odersky :
> I felt the same thing then.  And the platform has more than lived up to its
> initial promise. In fact it is a part of the platform's appeal that it
> allows languages different than Java to run well on it.

this is obviously some definition of the term "well" that i wasn't
previously aware of. :-)

Damn straight mate. If you cannot read code as simple as this you're up shit creek without a paddle. You'll never comprehend any code, but fake it like the rest.

This "complex" thing cracks me up.

On 27/10/2011 10:51 PM, "Daniel Sobral" <dcsobral@gmail.com> wrote:

On Thu, Oct 27, 2011 at 09:15, Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:
> Ok, I’m starting to feel scared. That code actually looks fairly
> understandable to me.

Here's the deal: this code was picked because it is short on words and
heavy on symbols. HOWEVER, it follows a very standard notation used to
describe higher order types, the notation for kinds:
http://en.wikipedia.org/wiki/Kind_(type_theory).

So, let's say you say a Java code like this:

for (String item : items) {
 count++;
}

On the face of it, that code is incomprehensible. You have to
understand the notations -- you have to understand that "for" is
followed by two "blocks" of different, and particular meanings, and
that it repeats some code. You have to understand the "Type
identifier" pattern, you have to understand what ":" stands for in
this context, you have to understand "++", you have to understand
what's the meaning of ";". Once you do that, then the code is obvious.

The same things goes with that code. Even though it is missing a whole
class or trait -- very fundamental to the code in question, * -> * ->
* has a very clear meaning when it comes to kinds, and not a
particularly difficult one.

--
Daniel C. Sobral

I travel to the future all the time.

On Thu, Oct 27, 2011 at 11:11 PM, Tony Morris <tmorris@tmorris.net> wrote:

Damn straight mate. If you cannot read code as simple as this you're up shit creek without a paddle. You'll never comprehend any code, but fake it like the rest.

This "complex" thing cracks me up.

I believe that. But it is very real. And, surely, declaring people incompetent won't help. There is sometimes a real hurdle to get them over, and we need to help them. At other times, at least in my opinion, certain idioms are just not worth the extra complexity they introduce. I designed Scala to be scalable, but some of its uses are simply where I would never go. Totally fine by me if people go there, but please, don't assume that everyone needs to share the ride :-)
Cheers
 -- Martin

I don't mean to declare incompetence; rather, irrationally averse in extraordinary and often amusing ways. I also think it is a mistake to continue taking these claims seriously, so the best case scenario allows a good laugh, but nothing more.

On 28/10/2011 7:24 AM, "martin odersky" <martin.odersky@epfl.ch> wrote:

On Thu, Oct 27, 2011 at 11:11 PM, Tony Morris <tmorris@tmorris.net> wrote:

Damn straight mate. If you cannot read code as simple as this you're up shit creek without a paddle. You'll never comprehend any code, but fake it like the rest.

This "complex" thing cracks me up.

I believe that. But it is very real. And, surely, declaring people incompetent won't help. There is sometimes a real hurdle to get them over, and we need to help them. At other times, at least in my opinion, certain idioms are just not worth the extra complexity they introduce. I designed Scala to be scalable, but some of its uses are simply where I would never go. Totally fine by me if people go there, but please, don't assume that everyone needs to share the ride :-)
Cheers
 -- Martin

On Thu, Oct 27, 2011 at 11:30 PM, Tony Morris <tmorris@tmorris.net> wrote:

I don't mean to declare incompetence; rather, irrationally averse in extraordinary and often amusing ways. I also think it is a mistake to continue taking these claims seriously, so the best case scenario allows a good laugh, but nothing more.

Yes. Sometimes that's indeed the best way to react.
 -- Martin 

Using sliding was my first thought as well and I agree it is simpler.
However, timing the two approaches indicates the zipped solution is
much faster than the sliding one. (Just typing in the REPL it looks
like 10,000 elements in 2.5ms for zipped and ~15ms for sliding on a
3GHz x86. Both will early out if an out of order element is found.)
I'm guessing either sliding has to construct the entire result list
before forall is called or perhaps the zipped approach is using Tuples
where sliding is using two element Lists. How does one analyze and
reason about the difference between these two pieces of code? Is there
something fundamental to the zipped solution winning or is it an
artifact of implementation? (Or am I just wrong?)

A few other things I'm interested in re: how to write Scala code:

- How reusable is the idiom across different collections?

- Can the idiom easily be used with parallel collections?

- How hard is it to define a generic high order function using one
style or the other? If one is using this idiom over and over,
introducing an isOrdered function seems natural. But doing so seems to
require annotation with a number of types from inside the collections
infrastructure. Perhaps it is equally difficult for all such idioms,
but some guidance on this is pretty important. Perhaps there is an
easier way to do that.

Zalman Stern

On Oct 26, 12:53 pm, HamsterofDeath wrote:
> imho simpler: sliding(2).forall(e => e.head <= e.last)
>
> in the zipped example, you need to think a bit about what happens to the
> leftover element
>
> Am 26.10.2011 16:48, schrieb Ittay Dror:
>
>
>
>
>
>
>
>
>
> > martin odersky wrote:
>
> >> On Wed, Oct 26, 2011 at 3:57 PM, Ittay Dror >> > wrote:
>
> >>     martin odersky wrote:
> >>>     For a great counter-argument to the original post, see:
>
> >>>      http://www.youtube.com/watch?v=6RwrT6N43lY
>
> >>     (since we're on the debate list...)
>
> >>     You only show that there is a child that can understand Scala.
> >>     For this to be a counter-argument, you need to show that there
> >>     are more children that can understand Scala than those that get
> >>     Java.
>
> >> Oh, I know lots more children (see recent Kojo story, and also people
> >> I know privately). But they don't have youtube videos :-).
>
> >> I firmly believe that Scala is easier to learn than Java. For a
> >> starter: public static void main( String[] args) what?
>
> > I think you view this from the "spec" point of view. Has this
> > definition of 'main' ever cause tricky bugs? Made code harder to write
> > or change?
>
> >> The main problem that I see is that the Scala community as a whole
> >> sometimes overcomplicates things.
>
> > Hence my suggestion for 'idiomatic' approach a-la python.
>
> > See this for example:
> >http://stackoverflow.com/questions/7852471/idiomatic-construction-to-...
> > Runar answered with a post containing semigroups and traverse,
> > pointing to a haskell paper
> > I answered with a solution using iteratees, which is no better
> > The best solution IMHO was: |(l, l.tail).zipped.forall(_ <= _) (by
> > missingfaktor)
>
> > A newbie should have a rich resource of such snippets instead of
> > finding answers about traverse/iteratee which are harder to learn,
> > read and more code to write.
> > |
>
> >> Cheers
>
> >>  -- Martin

sliding created a lot of new collections of the same type as the
original one, so using a view might help here.

in general, i just go with the most simple way until my profiler tells
me it's too slow or it's obviously the wrong algorithm (bubble sort)

Am 29.10.2011 00:41, schrieb Z:
> Using sliding was my first thought as well and I agree it is simpler.
> However, timing the two approaches indicates the zipped solution is
> much faster than the sliding one. (Just typing in the REPL it looks
> like 10,000 elements in 2.5ms for zipped and ~15ms for sliding on a
> 3GHz x86. Both will early out if an out of order element is found.)
> I'm guessing either sliding has to construct the entire result list
> before forall is called or perhaps the zipped approach is using Tuples
> where sliding is using two element Lists. How does one analyze and
> reason about the difference between these two pieces of code? Is there
> something fundamental to the zipped solution winning or is it an
> artifact of implementation? (Or am I just wrong?)
>
> A few other things I'm interested in re: how to write Scala code:
>
> - How reusable is the idiom across different collections?
>
> - Can the idiom easily be used with parallel collections?
>
> - How hard is it to define a generic high order function using one
> style or the other? If one is using this idiom over and over,
> introducing an isOrdered function seems natural. But doing so seems to
> require annotation with a number of types from inside the collections
> infrastructure. Perhaps it is equally difficult for all such idioms,
> but some guidance on this is pretty important. Perhaps there is an
> easier way to do that.
>
> Zalman Stern
>
> On Oct 26, 12:53 pm, HamsterofDeath wrote:
>> imho simpler: sliding(2).forall(e => e.head <= e.last)
>>
>> in the zipped example, you need to think a bit about what happens to the
>> leftover element
>>
>> Am 26.10.2011 16:48, schrieb Ittay Dror:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> martin odersky wrote:
>>>> On Wed, Oct 26, 2011 at 3:57 PM, Ittay Dror >>> > wrote:
>>>> martin odersky wrote:
>>>>> For a great counter-argument to the original post, see:
>>>>> http://www.youtube.com/watch?v=6RwrT6N43lY
>>>> (since we're on the debate list...)
>>>> You only show that there is a child that can understand Scala.
>>>> For this to be a counter-argument, you need to show that there
>>>> are more children that can understand Scala than those that get
>>>> Java.
>>>> Oh, I know lots more children (see recent Kojo story, and also people
>>>> I know privately). But they don't have youtube videos :-).
>>>> I firmly believe that Scala is easier to learn than Java. For a
>>>> starter: public static void main( String[] args) what?
>>> I think you view this from the "spec" point of view. Has this
>>> definition of 'main' ever cause tricky bugs? Made code harder to write
>>> or change?
>>>> The main problem that I see is that the Scala community as a whole
>>>> sometimes overcomplicates things.
>>> Hence my suggestion for 'idiomatic' approach a-la python.
>>> See this for example:
>>> http://stackoverflow.com/questions/7852471/idiomatic-construction-to-...
>>> Runar answered with a post containing semigroups and traverse,
>>> pointing to a haskell paper
>>> I answered with a solution using iteratees, which is no better
>>> The best solution IMHO was: |(l, l.tail).zipped.forall(_ <= _) (by
>>> missingfaktor)
>>> A newbie should have a rich resource of such snippets instead of
>>> finding answers about traverse/iteratee which are harder to learn,
>>> read and more code to write.
>>> |
>>>> Cheers
>>>> -- Martin

Someone could invent a programming language that requires the statement "Do not think about a pink elephant" on every other line, but after a while experienced users would not even notice it. Then some newbie would suggest removing it, and he would be scolded for trying to reinvent the language.

You mean like Asterisk dialplans, with every line starting with exten => n, ? 

--Russ P.

--
http://RussP.us