|
On 06/12/2010 09:18, martin odersky wrote:
What I'm reading is not a case for everyone. I'm reading the language specification. |
|
I'm not surprised you can't write programs fluently after a year if
all you're reading is the SLS. Unless you're an absolute genius, with the insight of a dozen lesser men, you will not be able to imagine every usage available / applicable to a situation purely from the spec. By design, specifications are narrow, sterile things which nail down as many details as possible. You need to look at how other people have approached problems to gain any appreciation (this goes for any language - anyone who could only read the c++ spec and then write something of any significance that actually worked would have my undying admiration) On Mon, Dec 6, 2010 at 3:17 PM, De Gao <[hidden email]> wrote: > On 06/12/2010 09:18, martin odersky wrote: > > On Sun, Dec 5, 2010 at 10:00 PM, De Gao <[hidden email]> wrote: >> >> On 05/12/2010 20:49, Roland Kuhn wrote: >>> >>> On Dec 5, 2010, at 21:16 , Randall R Schulz wrote: >>>> >>>> On Sunday December 5 2010, Seth Tisue wrote: >>>>>>>>>> >>>>>>>>>> "Erik" == Erik Engbrecht<[hidden email]> writes: >>>>>>> >>>>>>> Programming is an expert activity. All its tools are for experts. >>>>> >>>>> ... >>>>> >>>>> Erik> Programming is like reading and writing. Most people can >>>>> derive Erik> significant benefit from knowing the basics of how to do >>>>> it, [...] >>>>> >>>>> Amen, brother. >>>> >>>> And what does that have to do with Scala? Is every programming language >>>> to be designed with readability and understandability by members of the >>>> general public in mind? >>>> >>>> Sorry, I don't buy it. First things first here means what professionals >>>> need takes strong precedence over what any other audience would like. >>> >>> Yes, and there are two kinds of “professionals”: computer scientists (I >>> mean the real ones, which is imperfectly correlated with a university >>> faculty of the same name) and all others who need to do programming in order >>> to get their jobs done (e.g. high energy particle physics community). While >>> the latter have to write code which produces the right result for a specific >>> input set while being just clean enough to allow debugging, the former are >>> capable of producing libraries and frameworks to be used by others. In a >>> sense these groups are in a producer–consumer relationship. Can we agree >>> that both are important? >>> >>> Note how the “general public” does not appear in my previous paragraph. >>> From my own experience I must conclude that any programming activity which >>> is entirely private (meaning not motivated by business or contributions to >>> other—sizable—projects) does not reach a significant level. >>> >>> Now, what was the original question again: Is Scala only suited for >>> “experts”? (I take this to mean the antonym to “beginners”.) I don’t think >>> so, since it is possible to write beautiful libraries which are easy to use, >>> albeit hard to understand internally (e.g. the Scala collections). What may >>> be lacking are more resources like tutorials, blogs, etc. geared towards >>> beginners, so that they can use the language without having to look under >>> the hood. But my knowledge here is a bit outdated since I did no surveys >>> wrt. this in the recent past. >>> >>> Regards, >>> >>> Roland >>> >>> -- >>> [scala-debate on 2009/10/2] >>> Viktor Klang: When will the days of numerical overflow be gone? >>> Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038 >>> >> Can we call some stuff is for 'expert' that you need to read quite a lot >> of document to use it, like the Airebus A380, but some don't need to read >> any document (or not so much document) to use it, like a dish washer? > > Let me ask again: What did you read? -- Martin > > What I'm reading is not a case for everyone. I'm reading the language > specification. > |
|
In reply to this post by De Gao
On 6 December 2010 20:17, De Gao <gaode.ml@gmail.com> wrote:
and what other language specifications have you also read, by way of comparison? |
|
In reply to this post by Alec Zorab
On 06/12/2010 20:34, Alec Zorab wrote:
> I'm not surprised you can't write programs fluently after a year if > all you're reading is the SLS. Unless you're an absolute genius, with > the insight of a dozen lesser men, you will not be able to imagine > every usage available / applicable to a situation purely from the > spec. By design, specifications are narrow, sterile things which nail > down as many details as possible. You need to look at how other people > have approached problems to gain any appreciation (this goes for any > language - anyone who could only read the c++ spec and then write > something of any significance that actually worked would have my > undying admiration) > > On Mon, Dec 6, 2010 at 3:17 PM, De Gao<[hidden email]> wrote: >> On 06/12/2010 09:18, martin odersky wrote: >> >> On Sun, Dec 5, 2010 at 10:00 PM, De Gao<[hidden email]> wrote: >>> On 05/12/2010 20:49, Roland Kuhn wrote: >>>> On Dec 5, 2010, at 21:16 , Randall R Schulz wrote: >>>>> On Sunday December 5 2010, Seth Tisue wrote: >>>>>>>>>>> "Erik" == Erik Engbrecht<[hidden email]> writes: >>>>>>>> Programming is an expert activity. All its tools are for experts. >>>>>> ... >>>>>> >>>>>> Erik> Programming is like reading and writing. Most people can >>>>>> derive Erik> significant benefit from knowing the basics of how to do >>>>>> it, [...] >>>>>> >>>>>> Amen, brother. >>>>> And what does that have to do with Scala? Is every programming language >>>>> to be designed with readability and understandability by members of the >>>>> general public in mind? >>>>> >>>>> Sorry, I don't buy it. First things first here means what professionals >>>>> need takes strong precedence over what any other audience would like. >>>> Yes, and there are two kinds of “professionals”: computer scientists (I >>>> mean the real ones, which is imperfectly correlated with a university >>>> faculty of the same name) and all others who need to do programming in order >>>> to get their jobs done (e.g. high energy particle physics community). While >>>> the latter have to write code which produces the right result for a specific >>>> input set while being just clean enough to allow debugging, the former are >>>> capable of producing libraries and frameworks to be used by others. In a >>>> sense these groups are in a producer–consumer relationship. Can we agree >>>> that both are important? >>>> >>>> Note how the “general public” does not appear in my previous paragraph. >>>> From my own experience I must conclude that any programming activity which >>>> is entirely private (meaning not motivated by business or contributions to >>>> other—sizable—projects) does not reach a significant level. >>>> >>>> Now, what was the original question again: Is Scala only suited for >>>> “experts”? (I take this to mean the antonym to “beginners”.) I don’t think >>>> so, since it is possible to write beautiful libraries which are easy to use, >>>> albeit hard to understand internally (e.g. the Scala collections). What may >>>> be lacking are more resources like tutorials, blogs, etc. geared towards >>>> beginners, so that they can use the language without having to look under >>>> the hood. But my knowledge here is a bit outdated since I did no surveys >>>> wrt. this in the recent past. >>>> >>>> Regards, >>>> >>>> Roland >>>> >>>> -- >>>> [scala-debate on 2009/10/2] >>>> Viktor Klang: When will the days of numerical overflow be gone? >>>> Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038 >>>> >>> Can we call some stuff is for 'expert' that you need to read quite a lot >>> of document to use it, like the Airebus A380, but some don't need to read >>> any document (or not so much document) to use it, like a dish washer? >> Let me ask again: What did you read? -- Martin >> >> What I'm reading is not a case for everyone. I'm reading the language >> specification. >> thinking by what situation that Scala could become popular. |
|
In reply to this post by Alec Zorab
I actually found the spec quite useful in learning - and still learning - Scala. Of course I would never consider it as a singular source. But it is an unquestionably valuable resource.
On Mon, Dec 6, 2010 at 3:34 PM, Alec Zorab <[hidden email]> wrote: I'm not surprised you can't write programs fluently after a year if -- http://erikengbrecht.blogspot.com/ |
|
Undoubtedly, but I think the argument of "I've been studying the SLS
for a year and can't write fluent scala, so scala hasn't got a future" is a bit like saying "I've been studying internal combustion engines for a year, but I still can't drive properly, so cars are never going to get popular". On Mon, Dec 6, 2010 at 7:48 PM, Erik Engbrecht <[hidden email]> wrote: > I actually found the spec quite useful in learning - and still learning - > Scala. Of course I would never consider it as a singular source. But it is > an unquestionably valuable resource. > > On Mon, Dec 6, 2010 at 3:34 PM, Alec Zorab <[hidden email]> wrote: >> >> I'm not surprised you can't write programs fluently after a year if >> all you're reading is the SLS. Unless you're an absolute genius, with >> the insight of a dozen lesser men, you will not be able to imagine >> every usage available / applicable to a situation purely from the >> spec. By design, specifications are narrow, sterile things which nail >> down as many details as possible. You need to look at how other people >> have approached problems to gain any appreciation (this goes for any >> language - anyone who could only read the c++ spec and then write >> something of any significance that actually worked would have my >> undying admiration) >> >> On Mon, Dec 6, 2010 at 3:17 PM, De Gao <[hidden email]> wrote: >> > On 06/12/2010 09:18, martin odersky wrote: >> > >> > On Sun, Dec 5, 2010 at 10:00 PM, De Gao <[hidden email]> wrote: >> >> >> >> On 05/12/2010 20:49, Roland Kuhn wrote: >> >>> >> >>> On Dec 5, 2010, at 21:16 , Randall R Schulz wrote: >> >>>> >> >>>> On Sunday December 5 2010, Seth Tisue wrote: >> >>>>>>>>>> >> >>>>>>>>>> "Erik" == Erik Engbrecht<[hidden email]> writes: >> >>>>>>> >> >>>>>>> Programming is an expert activity. All its tools are for experts. >> >>>>> >> >>>>> ... >> >>>>> >> >>>>> Erik> Programming is like reading and writing. Most people can >> >>>>> derive Erik> significant benefit from knowing the basics of how to >> >>>>> do >> >>>>> it, [...] >> >>>>> >> >>>>> Amen, brother. >> >>>> >> >>>> And what does that have to do with Scala? Is every programming >> >>>> language >> >>>> to be designed with readability and understandability by members of >> >>>> the >> >>>> general public in mind? >> >>>> >> >>>> Sorry, I don't buy it. First things first here means what >> >>>> professionals >> >>>> need takes strong precedence over what any other audience would like. >> >>> >> >>> Yes, and there are two kinds of “professionals”: computer scientists >> >>> (I >> >>> mean the real ones, which is imperfectly correlated with a university >> >>> faculty of the same name) and all others who need to do programming in >> >>> order >> >>> to get their jobs done (e.g. high energy particle physics community). >> >>> While >> >>> the latter have to write code which produces the right result for a >> >>> specific >> >>> input set while being just clean enough to allow debugging, the former >> >>> are >> >>> capable of producing libraries and frameworks to be used by others. In >> >>> a >> >>> sense these groups are in a producer–consumer relationship. Can we >> >>> agree >> >>> that both are important? >> >>> >> >>> Note how the “general public” does not appear in my previous >> >>> paragraph. >> >>> From my own experience I must conclude that any programming activity >> >>> which >> >>> is entirely private (meaning not motivated by business or >> >>> contributions to >> >>> other—sizable—projects) does not reach a significant level. >> >>> >> >>> Now, what was the original question again: Is Scala only suited for >> >>> “experts”? (I take this to mean the antonym to “beginners”.) I don’t >> >>> think >> >>> so, since it is possible to write beautiful libraries which are easy >> >>> to use, >> >>> albeit hard to understand internally (e.g. the Scala collections). >> >>> What may >> >>> be lacking are more resources like tutorials, blogs, etc. geared >> >>> towards >> >>> beginners, so that they can use the language without having to look >> >>> under >> >>> the hood. But my knowledge here is a bit outdated since I did no >> >>> surveys >> >>> wrt. this in the recent past. >> >>> >> >>> Regards, >> >>> >> >>> Roland >> >>> >> >>> -- >> >>> [scala-debate on 2009/10/2] >> >>> Viktor Klang: When will the days of numerical overflow be gone? >> >>> Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January >> >>> 2038 >> >>> >> >> Can we call some stuff is for 'expert' that you need to read quite a >> >> lot >> >> of document to use it, like the Airebus A380, but some don't need to >> >> read >> >> any document (or not so much document) to use it, like a dish washer? >> > >> > Let me ask again: What did you read? -- Martin >> > >> > What I'm reading is not a case for everyone. I'm reading the language >> > specification. >> > > > > > -- > http://erikengbrecht.blogspot.com/ > |
|
On 07/12/2010 13:04, Alec Zorab wrote:
> Undoubtedly, but I think the argument of "I've been studying the SLS > for a year and can't write fluent scala, so scala hasn't got a future" > is a bit like saying "I've been studying internal combustion engines > for a year, but I still can't drive properly, so cars are never going > to get popular". > > On Mon, Dec 6, 2010 at 7:48 PM, Erik Engbrecht<[hidden email]> wrote: >> I actually found the spec quite useful in learning - and still learning - >> Scala. Of course I would never consider it as a singular source. But it is >> an unquestionably valuable resource. >> >> On Mon, Dec 6, 2010 at 3:34 PM, Alec Zorab<[hidden email]> wrote: >>> I'm not surprised you can't write programs fluently after a year if >>> all you're reading is the SLS. Unless you're an absolute genius, with >>> the insight of a dozen lesser men, you will not be able to imagine >>> every usage available / applicable to a situation purely from the >>> spec. By design, specifications are narrow, sterile things which nail >>> down as many details as possible. You need to look at how other people >>> have approached problems to gain any appreciation (this goes for any >>> language - anyone who could only read the c++ spec and then write >>> something of any significance that actually worked would have my >>> undying admiration) >>> >>> On Mon, Dec 6, 2010 at 3:17 PM, De Gao<[hidden email]> wrote: >>>> On 06/12/2010 09:18, martin odersky wrote: >>>> >>>> On Sun, Dec 5, 2010 at 10:00 PM, De Gao<[hidden email]> wrote: >>>>> On 05/12/2010 20:49, Roland Kuhn wrote: >>>>>> On Dec 5, 2010, at 21:16 , Randall R Schulz wrote: >>>>>>> On Sunday December 5 2010, Seth Tisue wrote: >>>>>>>>>>>>> "Erik" == Erik Engbrecht<[hidden email]> writes: >>>>>>>>>> Programming is an expert activity. All its tools are for experts. >>>>>>>> ... >>>>>>>> >>>>>>>> Erik> Programming is like reading and writing. Most people can >>>>>>>> derive Erik> significant benefit from knowing the basics of how to >>>>>>>> do >>>>>>>> it, [...] >>>>>>>> >>>>>>>> Amen, brother. >>>>>>> And what does that have to do with Scala? Is every programming >>>>>>> language >>>>>>> to be designed with readability and understandability by members of >>>>>>> the >>>>>>> general public in mind? >>>>>>> >>>>>>> Sorry, I don't buy it. First things first here means what >>>>>>> professionals >>>>>>> need takes strong precedence over what any other audience would like. >>>>>> Yes, and there are two kinds of “professionals”: computer scientists >>>>>> (I >>>>>> mean the real ones, which is imperfectly correlated with a university >>>>>> faculty of the same name) and all others who need to do programming in >>>>>> order >>>>>> to get their jobs done (e.g. high energy particle physics community). >>>>>> While >>>>>> the latter have to write code which produces the right result for a >>>>>> specific >>>>>> input set while being just clean enough to allow debugging, the former >>>>>> are >>>>>> capable of producing libraries and frameworks to be used by others. In >>>>>> a >>>>>> sense these groups are in a producer–consumer relationship. Can we >>>>>> agree >>>>>> that both are important? >>>>>> >>>>>> Note how the “general public” does not appear in my previous >>>>>> paragraph. >>>>>> From my own experience I must conclude that any programming activity >>>>>> which >>>>>> is entirely private (meaning not motivated by business or >>>>>> contributions to >>>>>> other—sizable—projects) does not reach a significant level. >>>>>> >>>>>> Now, what was the original question again: Is Scala only suited for >>>>>> “experts”? (I take this to mean the antonym to “beginners”.) I don’t >>>>>> think >>>>>> so, since it is possible to write beautiful libraries which are easy >>>>>> to use, >>>>>> albeit hard to understand internally (e.g. the Scala collections). >>>>>> What may >>>>>> be lacking are more resources like tutorials, blogs, etc. geared >>>>>> towards >>>>>> beginners, so that they can use the language without having to look >>>>>> under >>>>>> the hood. But my knowledge here is a bit outdated since I did no >>>>>> surveys >>>>>> wrt. this in the recent past. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Roland >>>>>> >>>>>> -- >>>>>> [scala-debate on 2009/10/2] >>>>>> Viktor Klang: When will the days of numerical overflow be gone? >>>>>> Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January >>>>>> 2038 >>>>>> >>>>> Can we call some stuff is for 'expert' that you need to read quite a >>>>> lot >>>>> of document to use it, like the Airebus A380, but some don't need to >>>>> read >>>>> any document (or not so much document) to use it, like a dish washer? >>>> Let me ask again: What did you read? -- Martin >>>> >>>> What I'm reading is not a case for everyone. I'm reading the language >>>> specification. >>>> >> >> >> -- >> http://erikengbrecht.blogspot.com/ >> beginning to end. I just spend more time on the spec because I thought that's the book that provide all of the information. But seems your guys don't think so. It seems that several people agreed that not all the features of Scala needs to be involved in development. So to make this thread more meaningful, could I beg those skilled Scala developers that make a brief list of features that suit beginner, advanced user and expert of Scala? Thank you very much. |
|
On Wed, Dec 8, 2010 at 4:47 PM, De Gao <gaode.ml@gmail.com> wrote:
I don't like to learn languages this way because not all "beginners" need to create the same programs. So, for example, if you're doing a lot of I/O work as a beginner you would want to know about Option (and exceptions) in some detail, in order to handle errors in input data. In contrast, if you were doing numeric work, you would want to understand tail recursion and the differences between for loops and while loops and possibly a little about implicits. If you had particularly intricate data, you might want to understand the type system better, including co- and contravariance. If you wanted to make a responsive GUI app, you would want to know something about actors. If you have programmed in Java, you probably want to leverage that when starting out ("this works almost like Java, except better!"), but if not, you might want to start out emphasizing the functional features ("If you have a list xs, xs.map(x => x*2) will multiply everything by two!"). Thus, when learning a new language, I try to read through at least one fairly comprehensive book (like Programming in Scala) so I am familiar with the kinds of things that are out there, but then I learn by doing--I try to write example programs, at least, and look up the information I need (in the book(s) I've read if I've forgotten, in the spec if necessary, or on a mailing list or site like StackOverflow). This way, I can end up expert in some areas and barely a beginner in others, but in a way that _suits what I need to do_. Anyway, those things that really do take considerable study to understand are: (1) Exactly how the types and builders in the collections library work (2) The intricacies of the type system (including aliases and this.type) (3) How to create a robust and informative parser from the given parser libraries (4) How to maximally leverage functional programming to solve problems but in each case, you can get a lot done practically without understanding every detail. --Rex |
|
In reply to this post by De Gao
I could be wrong, but I don't think a formal language spec really has any place in learning to use a language -- unless perhaps you are talking about very advanced usage. A formal spec is more for language designers and implementors. Using a formal spec to learn the basics of a language seems to me a bit like reading official family law volumes to learn how to raise a family.
Russ P. On Wed, Dec 8, 2010 at 1:47 PM, De Gao <gaode.ml@gmail.com> wrote:
-- http://RussP.us |
|
In reply to this post by De Gao
>It seems that several people agreed that not all the features of Scala
needs to be involved in development. So to make this thread >more meaningful, could I beg those skilled Scala developers that make a brief list of features that suit beginner, advanced user and >expert of Scala? >Thank you very much. I don't think it's about NOT using some parts of the language, it's more about not abusing them... I tried to gather some abuses that should be avoided by the "average java Joe" here: https://gist.github.com/595556 and it's really meant to go on top of the scala style guide linked to from there. Needless to say, it led to a revolt and heated discussions etc. Feel free to ignore them "rules" :) I don't believe the basic scala is complicated. You can use the advanced type system... just enough, a lot or at all. In Pascal, there was no List and you had to make your own and you couldn't type it. Here you're provided a few and each can be typed with variance or not... you could use List[Any] everywhere and not worry about it any more than a List<void*>. Most of the time you probably don't need to worry about variance and can get away with List[Student], which is simple enough... So, unless you're building a library or advanced API and not just coding the guts of a component hidden 3 layers deep... I wouldn't waste time to worry about these things. Reading any of the scala books should be more than enough. Cheers, Razvan Razvan Cojocaru,
Work: http://www.sigma-systems.com Playground: http://wiki.homecloud.ca Latest cool toys: Scripster and Gremlins Follow me: RSS Feed, Twitter, GitHub. |
|
In reply to this post by De Gao
Well, I'm not that skilled in Scala but I've been using it for a long time. I started with C++ which I learned in college. That language also got lots of complaints for being too advanced, which surprised me since I thought it was fairly straight forward to use if you exclude template programming. I think the type system in Scala's equivalent of C++ templates. I never learned any advanced C++ template programmming, though I did get the Modern C++ Design book and it's still sitting unread in my book shelf together with the Bjarne's bible :).
Now I'm pretty sure people new to programming shouldn't start with Scala so you'd have to assume experience with some other OO/general-purpose language. For beginners of Scala I think traits (interfaces with code) and basic usage of the collection library (map,reduce,filter,foreach) is fine. As you get more familiar you learn to use case classes/object in pattern matching. If you're coming for OO-programming it's going to take some time getting used to functional programming, so expect this to grow on you for 1-2 years. For more intermediate level, I reckon usage of the type system with type parameters and type members. Partial functions. Function closures (if you're coming for OO). Some usage of implicits. Modelling with actors instead of object aggregation/members. For advanced I don't know since I'm not there yet and maybe I'll never be, but I'm pretty sure it'll involve the type system with type classes. In summary: Don't Panic!
On Wed, Dec 8, 2010 at 10:47 PM, De Gao <gaode.ml@gmail.com> wrote: Not really. I've read the Scala by Example and Program in Scala from beginning to end. I just spend more time on the spec because I thought that's the book that provide all of the information. But seems your guys don't think so. |
|
Trond Olsen skrev 2010-12-09 05:39:
> Well, I'm not that skilled in Scala but I've been using it for a long > time. I started with C++ which I learned in college. That language also > got lots of complaints for being too advanced, which surprised me since > I thought it was fairly straight forward to use *if* you exclude > template programming. I think the type system in Scala's equivalent of > C++ templates. I never learned any advanced C++ template programmming, > though I did get the Modern C++ Design book and it's still sitting > unread in my book shelf together with the Bjarne's bible :). Having done a fair bit of type level programming in both Scala and C++, I would say that Scala's type system is in some ways superior to C++ templates, i.e. separate compilation, traits, and in some ways inferior, i.e. specialization, performance, type equality checks. Type level programming (including implicits to some extent) is often viewed by many as complex, and to some level I agree as the syntax is often much more cumbersome than it have to be. Look at Clay and D for some examples of simplified type level programming. Like C++ both languages support TC type level programming (which I personally don't see as a disadvantage). /Jesper Nordenberg |
|
In reply to this post by Razvan Cojocaru-2
On Thu, Dec 9, 2010 at 3:42 AM, Razvan Cojocaru <[hidden email]> wrote:
I think that's very a good list, even though some of the rules are gradual, not absolute. -- Martin Needless to say, it led to a revolt and heated discussions etc. Feel free to |
|
In reply to this post by De Gao
On Wed, Dec 8, 2010 at 10:47 PM, De Gao <gaode.ml@gmail.com> wrote:
It's an intriguing question. I believe the answer will differ a little bit for everyone, but I'll put up a strawman nevertheless. I assume here that programmers have already a good knowledge of Java, so we can take at least pre-generics Java for granted. If that's not the case, some of the early concepts such as classes and exceptions need to be moved to more advanced levels. Also, I distinguish between application programmers and library designers, because the required skill sets are radically different. So here's something for y'all to knock down ;-): Level A1: Beginning application programmer Java-like statements and expressions: standard operators, method calls, conditionals, loops, try/catch class, object, def, val, var, import, package Infix notation for method calls Simple closures Collections with map, filter, etc for-expressions Level A2: Intermediate application programmer Pattern matching Trait composition Recursion, in particular tail recursion XML literals Level A3: Expert application programmer Folds Streams Actors Combinator parsers Level L1: Junior library designer Type parameters Traits Lazy vals Control abstraction, currying By-name parameters Level L2: Senior library designer Variance annotations Existential types (to interface with Java wildcards) Abstract types Self types Structural types Level L3: Expert library designer Early initializers Extractors Implicit definitions Higher-kinded types Defining map/flatmap/withFilter for new kinds of for-expressions Cheers -- Martin |
|
On Thu, Dec 9, 2010 at 11:11 AM, martin odersky <[hidden email]> wrote:
One additional remark: if one insists in a total order, I'd probably group into four levels as follows: A1, A2/L1, A3/L2, L3 I.e. A2 is about the same level of difficulty as L1, same for A3 and L2. Cheers -- Martin |
|
In reply to this post by Martin Odersky
Big boss steps in J All that’s missing is a compiler setting now J (or plugin, I guess) or can it be handled by some tools like FindBugs. From: [hidden email] [mailto:[hidden email]] On Behalf Of martin odersky On Wed, Dec 8, 2010 at 10:47 PM, De Gao <gaode.ml@gmail.com> wrote:
Not really. I've read the Scala by Example and Program in Scala from beginning to end. I just spend more time on the spec because I thought that's the book that provide all of the information. But seems your guys don't think so.
Razvan Cojocaru,
Work: http://www.sigma-systems.com Playground: http://wiki.homecloud.ca Latest cool toys: Scripster and Gremlins Follow me: RSS Feed, Twitter, GitHub. |
|
i already poked into almost any of that points, and i don't find them to be very far apart. the only measureable difference was:
application programmer: "i want to lib that does x so i can do y easily" lib coder: "yes of course, but let me hide in the architect's room until i've figured out a solution that works not only for your special case, but for the generalized problem without adding complexity for the caller. *some time later* appl coder: omg this is so awesome, i'll tell all my appl coding friends, they'll love it. next time i'll think a bit more about what i want and maybe define a more general api from the beginning. the next day, a web frontend coder talks to the appl coder: "i need another method on your webservice so i can do x and y" appl: "sure, just let me hide in my personal dungeon and wait until i've figured out a solution that also solved that similar problem you had last week" frontend guy: nice. lib: more architecturing, less coding appl: less architecturing, more coding. one can do both, imho. -------- Original-Nachricht -------- > Datum: Thu, 9 Dec 2010 06:52:51 -0500 > Von: "Razvan Cojocaru" <[hidden email]> > An: "\'martin odersky\'" <[hidden email]> > CC: [hidden email] > Betreff: RE: [scala-debate] Is Scala an expert language? > Big boss steps in J All that's missing is a compiler setting now J (or > plugin, I guess) or can it be handled by some tools like FindBugs. > > > > From: [hidden email] [mailto:[hidden email]] On Behalf Of martin > odersky > Sent: December-09-10 5:11 AM > To: De Gao > Cc: Alec Zorab; Erik Engbrecht; Roland Kuhn; Randall R Schulz; > [hidden email] > Subject: Re: [scala-debate] Is Scala an expert language? > > > > > > On Wed, Dec 8, 2010 at 10:47 PM, De Gao <[hidden email]> wrote: > > ... > > Not really. I've read the Scala by Example and Program in Scala from > beginning to end. I just spend more time on the spec because I thought > that's the book that provide all of the information. But seems your guys > don't think so. > It seems that several people agreed that not all the features of Scala > needs > to be involved in development. So to make this thread more meaningful, > could > I beg those skilled Scala developers that make a brief list of features > that > suit beginner, advanced user and expert of Scala? > Thank you very much. > > > It's an intriguing question. I believe the answer will differ a little bit > for everyone, but I'll put up a strawman nevertheless. I assume here that > programmers have already a good knowledge of Java, so we can take at least > pre-generics Java for granted. If that's not the case, some of the early > concepts such as classes and exceptions need to be moved to more advanced > levels. > > Also, I distinguish between application programmers and library designers, > because the required skill sets are radically different. > > So here's something for y'all to knock down ;-): > > Level A1: Beginning application programmer > > Java-like statements and expressions: standard operators, method calls, > conditionals, loops, try/catch > class, object, def, val, var, import, package > Infix notation for method calls > Simple closures > Collections with map, filter, etc > for-expressions > > Level A2: Intermediate application programmer > > Pattern matching > Trait composition > Recursion, in particular tail recursion > XML literals > > Level A3: Expert application programmer > > Folds > Streams > Actors > Combinator parsers > > Level L1: Junior library designer > > Type parameters > Traits > Lazy vals > Control abstraction, currying > By-name parameters > > Level L2: Senior library designer > > Variance annotations > Existential types (to interface with Java wildcards) > Abstract types > Self types > Structural types > > Level L3: Expert library designer > > Early initializers > Extractors > Implicit definitions > Higher-kinded types > Defining map/flatmap/withFilter for new kinds of for-expressions > > Cheers > > -- Martin > -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl |
|
In reply to this post by Martin Odersky
Just a minor note that I don't think existential types are only useful for dealing with Java. In particular, paulp brought up a situation where:
type Foo = x.T forSome { val x } was the best solution to represent the type T on the object x. In any case, I like the list. It seems like a natural progression. I would move Extractors down to A3/L2 though, as you find yourself using them *a lot* when integrating with existing java libraries.... for example: Google collections provides pair/tupleN classes that are just *dieing* for someone to provide extractors. Albeit, this could be filled by a library designer, I think the sophistication is at the L2 level rather than L3.
One that same note, I think defining map/flatMap/filter happens a bit earlier in the library designer mindset as well, probably around L2 as well. In any case, the beauty to this list is that you'll notice a programmer can be productive in scala at each level. It's a good language to get things done in, regardless of skill level. Granted, I'd rather look at code I write now than when I started learning Scala, but the code I wrote when I started worked just fine and solved whatever problem I needed to solve.
Scala may get complex in interactions at the highest level, but that's only needed to solve complex problems. That and the complexity you face, IMHO is more appropriate to the complexity of the problem. When creating the same solution in Java or C++ I usually feel burdened with a lot of other noise when solving these more complex issues.
- Josh
On Thu, Dec 9, 2010 at 5:11 AM, martin odersky <[hidden email]> wrote:
|
|
On Thu, Dec 9, 2010 at 2:05 PM, Josh Suereth <[hidden email]> wrote:
Just a minor note that I don't think existential types are only useful for dealing with Java. In particular, paulp brought up a situation where:
True. In fact you can then write S#T, where S is the type of x, it means the same thing. But I agree that existentials have other uses beyond wildcards. It's just that these other uses would suggest that existentials should be placed in L3. Wildcards make it more urgent to deal with existentials that's why I have put them in L2.
Good point. It seems in practice I read much more about people using implicits than people using extractors. I agree it should rather be the other way, though.
Yes, I tend to agree with that also. Cheers -- Martin |
|
In reply to this post by Martin Odersky
I responded privately to Martin how much I like this list. But it does raise the point: if someone who knows what they were doing were so minded, I think this list (or one like it) could be used as the basis for a really great multi-level course in Scala. A website structured along exactly these lines might well do the language a lot of good, by making it really *clear* how a programmer can dive into the language quickly, and gradually get better at it.
(Granted, the Scala books tend to follow similar lines. But simply by drawing somewhat arbitrary crisp lines, I think this makes the language less intimidating.) I can't volunteer: besides not having the time, I just plain am not at the A3 or L3 levels myself. But it's the website I'd love to have as a guideline myself, as someone slowly getting better at it...
On Thu, Dec 9, 2010 at 5:11 AM, martin odersky <[hidden email]> wrote:
|
| Powered by Nabble | See how NAML generates this page |
