tag:blogger.com,1999:blog-22587889.post2490093962475520401..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Guido's thoughts on ScalaAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-22587889.post-36512589806178853332008-12-19T21:44:00.000+05:302008-12-19T21:44:00.000+05:30Mine was not a complaint about Tony, but about Ced...Mine was not a complaint about Tony, but about Cedric.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-22377738196776281182008-12-19T21:31:00.000+05:302008-12-19T21:31:00.000+05:30Tony, I think that Ricky's complaint is valid simp...Tony, I think that Ricky's complaint is valid simply due to the lack of semantic cues from single-character variable names (t) and names with highly generalized English semantics (apply). As much as anything, I personally find it difficult to rapidly visually distinguish single-character names from the surrounding syntactic markup. It's not that your code doesn't make sense; it's that it's difficult to take in its meaning at a glance due to the lack of adequate semantic cues and your penchant for terseness.Kris Nuttycombehttps://www.blogger.com/profile/06347383351250086727noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-81358983439054008962008-12-07T02:14:00.000+05:302008-12-07T02:14:00.000+05:30I'd like to correct you Ricky. I care more about r...I'd like to correct you Ricky. I care more about readability - perhaps more than you do. To use Cedric's example, this is exactly why I write that. Would you like to see the alternative in Java? I don't mean a direct translation; rather how a typical Java programmer would solve that computational problem.<BR/><BR/>The code snippet that Cedric gave is entirely readable. There is some excess Scala noise of course; type annotations and type argument declarations.<BR/><BR/>To use another example, let reverse = foldl' (flip (:)) is far more readable than an explicit pattern match, however, I'll bet any poorly disciplined programmer is going to object. This programmer has failed to understand what it means to be readable.<BR/><BR/>An appropriate response to Cedric is "so?" but I suspect he has a lot of learning to do before a meaningful discussion can take place around that level of abstraction.Tony Morrishttps://www.blogger.com/profile/17206456907461293947noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-48722030537420855962008-12-06T19:46:00.000+05:302008-12-06T19:46:00.000+05:30My argument is not that you can write DSLs in Scal...My argument is <B>not</B> that you can write DSLs in Scala for non-programmers to use.<BR/><BR/>Digression. I have done a <A HREF="http://video.google.com/videoplay?docid=-8103284744220333344" REL="nofollow">significant amount of work related to DSLs</A> over the years. There's definitely a choice between DSLs that are simply libraries in a given language and have access to all the language features. This is the "Ruby Way" of doing DSLs and there are a couple of DSLs of this type in Lift (SiteMap and Machine). There's also the "new language, new syntax" mechanism where you create a mini language. Examples of this are spreadsheets, Textile/Markdown, etc. Once again, Scala shines for dealing with these kinds of DSLs. Finally, there are DSLs expressed in XML that are generated using external GUI tools and interpretted by your program. Ant and Maven are two examples. While I haven't written these kind of DSLs with Scala, Scala's awesome XML support should make working with DSL in XML very simple.<BR/><BR/>Undigression... My argument is that being a library producer requires different thinking are reasoning. I don't think you can dismiss my argument until you've spent 6 months writing libraries in Scala, OCaml, F#, or some other language that allows for reasoning about code using types. It's not dissimilar from someone who has never designed a language dismissing your comments about design decisions in Python.<BR/><BR/>As a practical matter, there's only been one case on the Lift list of someone getting confused about a compiler error message. On a list that averages 15-20 messages a day, one problem in 18 months of the type your describing seems to indicate that your assertion is unfounded.David Pollakhttps://www.blogger.com/profile/16630520857988769066noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-79695712624334471462008-12-05T14:29:00.000+05:302008-12-05T14:29:00.000+05:30Guido,Scala is stuck with some arguably dubious sy...Guido,<BR/><BR/>Scala is stuck with some arguably dubious syntax, but there is a lot that is still malleable, and some breaking changes are coming in the next major release.<BR/><BR/>Regarding DSLs, I would guess that half of all user errors are "cannot find symbol" errors due to a missing import, etc. For example, Specs has an experimental 'data tables' feature, and uses both ! and | as operator names. I got this wrong the first time I used it, and so did my boss. These are trivial problems.<BR/><BR/>Of the other half, probably you would understand 80% of them if you understand generics (from Scala, Java or C#). That leaves 10% of the original whole, where you would (mock horror) have to read the source for the DSL, or consult the author.<BR/><BR/>TIMTOWTDI, and yes, some of them suck.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-50684798276499869552008-12-03T23:08:00.000+05:302008-12-03T23:08:00.000+05:30Thanks for the response. I hope the Scala communi...Thanks for the response. I hope the Scala community can live with backwards incompatibilities -- if you stick to strict compatibility this early. you'll end up with C++-scale warts. (Or the horrible "tab" rule in Unix Make, which was an early design mistake that couldn't be fixed "because there were already a dozen users".)<BR/><BR/>My concern about the DSL example is that I would expect that typos and other mistakes by users who don't know the whole language might cause really confusing error messages, since the compiler doesn't know that the user is using a very constrained subset of the language. If the user accidentally uses syntax they don't know but which has some advanced meaning, they won't be able to understand the error messages at all.<BR/><BR/>So you could say that I don't buy the "library consumers don't need to know the whole language" argument.Guido van Rossumhttps://www.blogger.com/profile/12821714508588242516noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-53620876445825899012008-12-03T22:51:00.000+05:302008-12-03T22:51:00.000+05:30Cedric, if one dense code sample proves that an en...Cedric, if one dense code sample proves that an entire language is unreadable then there are no readable languages.James Iryhttps://www.blogger.com/profile/02835376424060382389noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-12967175709967763542008-12-03T22:48:00.000+05:302008-12-03T22:48:00.000+05:30Cedric -I have 2 observations to make ..1. One can...Cedric -<BR/><BR/>I have 2 observations to make ..<BR/><BR/>1. One can very well limit oneself to the Java/C# syntax subset even in languages like Scala. Only if you want to have the additional batteries of the more powerful type system or the power of functional languages, do u need to use the additional stuff.<BR/><BR/>2. With the incremental improvement in syntax, don't you feel that we will be stuck with the C/C++ legacy syntax for ever ? Only today I read the following quote in Bill De hOra's <A HREF="http://www.dehora.net/journal/2008/12/02/qotd-mock-objects/" REL="nofollow">blog</A>, regarding Clojure ..<BR/><BR/><I>"The downside is that it's a Lisp. As a syntax, Lisp is a fail, which if you understand what Lisp syntax provides is a (the) great irony of programming. When you see how difficult it is for JRuby/Jython or even Groovy to break the syntax stranglehold Algol/C based languages have on the industry, you despair. Arguably, it loses out to those more syntactically appealing languages, who have a hard enough time knocking down the door."</I>Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-29445202280600958662008-12-03T22:44:00.000+05:302008-12-03T22:44:00.000+05:30Cedric,I can tell without even checking, that you ...Cedric,<BR/><BR/>I can tell without even checking, that you took that code snippet from Tony Morris's blog. He is probably the Scala programmer who cares least about readability. I know you chose it on purpose.<BR/><BR/>I suggest you look at (and post snippets of) Specs instead. And be fair, post Specs uses rather than backend implementation code.<BR/><BR/>I don't mean to rubbish Tony here, he's a great programmer, but he doesn't really care about identifier names, and this is deliberate.<BR/><BR/>You'll find Tony's Java code just as readable, and apparently he's writing some C#, so prepare yourself.<BR/><BR/>Anyway, if you have any difficulties with Scala, drop me a line and I'll be pleased to help, or find someone who can.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-8402272510150771232008-12-03T22:32:00.000+05:302008-12-03T22:32:00.000+05:30Ricky,Of course, everyone is a newcomer to Scala a...Ricky,<BR/><BR/>Of course, everyone is a newcomer to Scala at some point, but don't underestimate the power of incremental improvements.<BR/><BR/>The reason why C, C++, Java and C# became so popular is because each of these languages was an incremental improvement over the previous one, and programmers of one language could usually dive in pretty quickly into the next language of that family.<BR/><BR/>I'm afraid Scala had made a leap in syntax and semantic that will turn off all but the most determined programmers.<BR/><BR/>For example, I picked the following from a Scala blog:<BR/><BR/> def flatMap[TT <: T, X](g: R => RichFunction1[TT, X]) =<BR/> rich[TT, X](t => g(apply(t))(t))Cedrichttps://www.blogger.com/profile/13274064962794267826noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-35182500717316229932008-12-02T04:46:00.000+05:302008-12-02T04:46:00.000+05:30"bang! I have to deal with the type system".Yes, y..."bang! I have to deal with the type system".<BR/><BR/>Yes, you're using a typed language. Scala has a better and more pleasant type system than Java does, so "bang! I have to deal with the type system" is replaced by "great! I can use the type system".<BR/><BR/>As for Cedric's assertions that newcomers find Scala too complex, I don't suppose he considers that most Scala users were newcomers once. As I've said elsewhere, most of the initial complexities in Scala are quite superficial; you won't need to think about them much to write Scala code, only if you want to have a kneejerk reaction to a language you've never used.<BR/><BR/>That's not to diminish the point that there are real problems in Scala that could be, and might well be, cleaned up. There are already some breaking changes planned for 2.8.0, so it might be a good time to make some other cosmetic improvements.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-66299353259467087612008-12-02T02:17:00.000+05:302008-12-02T02:17:00.000+05:30personally i am so absolutely no longer willing to...personally i am so absolutely no longer willing to buy the "oh the complexity will only impact people writing libraries-for-other-people" claim. that's the same thing people said about some of the weirdnesses of generics in java.<BR/><BR/>i can be writing code that is just for me, and want to use abstraction to make the code Not Suck. which pretty much then means *bang* i suddenly have to deal with the type system. this is my experience with generics in Java, and i do not believe there is any reason it would be too different were i working in Scala; inevitably i would run into the various weirdnesses and pain points of the system.Raoul Dukehttps://www.blogger.com/profile/07354740962526930549noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-88456256300481133832008-12-02T00:09:00.000+05:302008-12-02T00:09:00.000+05:30Hi Cedric -I didn't mean reducing the complexity o...Hi Cedric -<BR/><BR/>I didn't mean reducing the complexity of Scala's syntax. I meant smoothening out the currently existing inconsistencies some of which have been mentioned by Guido himself in his post. As of today, there are some rough edges in Scala syntax which are considered exceptions to rules for writing idiomatic Scala. I have mentioned a few of them in my post, you can get a more comprehensive list if u follow some of the discussions in the scala-debate forum.<BR/><BR/>I know you have some reservations over the apparent complexity of Scala syntax (particularly compared to Java). I have a different opinion on this - I feel the basic syntax of Scala is a good compromise of expressiveness and succinctness. The language just needs to evolve and mature over time and Martin has mentioned about a more mature release for 2.8.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-8065761225440869252008-12-01T23:54:00.000+05:302008-12-01T23:54:00.000+05:30Hi Debasish,You write:"none of them look insurmoun...Hi Debasish,<BR/><BR/>You write:<BR/><BR/>"<BR/>none of them look insurmountable and will surely be addressed by the language designers in the versions to come<BR/>"<BR/><BR/>I don't think this is realistic. Over time, languages get more complex, not less complex, and I don't know how it would be possible for Scala to become less complex (both in syntax and semantics) without completely breaking backward compatibility.<BR/><BR/>Also, I'm surprised to see Martin use the size of the grammar as an argument to claim that Scala is not complex: it's possible to create very obfuscated syntaxes with just a few lines of EBNF.<BR/><BR/>The bottom line is that gurus in a language will never see the language they are comfortable with as complex: the only credible judges are newcomers, and so far, the verdict has been pretty negative for Scala.<BR/><BR/>-- <BR/>CedricCedrichttps://www.blogger.com/profile/13274064962794267826noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-82762496990600313552008-12-01T16:59:00.000+05:302008-12-01T16:59:00.000+05:30Hi Martin:Thanks for reading my blog. I also find ...Hi Martin:<BR/><BR/>Thanks for reading my blog. <BR/><BR/>I also find the usage of underscores to be very consistent across Scala - it serves as a universal placeholder and allows powerful binding idioms. But very frequently I come across opinions where people gripe about underscores and (maybe) I fail to explain them clearly enough. Your 2 lines explanation clears it all very succinctly.<BR/><BR/>Thanks again - I am sure we will have a huge 2.8.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-38237468601142307932008-12-01T16:39:00.000+05:302008-12-01T16:39:00.000+05:30Hi Debasish:Nice post. The only point I want to ra...Hi Debasish:<BR/><BR/>Nice post. The only point I want to raise is your mention about underscores. I think it's simply not true that underscores have "a number of interpretations". Fundamentally, it's always the same: an underscore denotes something that's missing. When used as an expression, the missing thing needs to be supplied as a parameter. When used as a type, the type inferencer will find a type for you. That's all. I find it very consistent, really.martinhttps://www.blogger.com/profile/05955349008001468964noreply@blogger.com