I agree that optional empty parameter lists are a bad idea, but for slightly different reasons. If, as in Python, Scala made foo always just refer to something, and foo() always call something, that would simplify some syntax, probably even making the standalone _ unnecessary (val referenceToPrintln = println _). It would of course get rid of the possibility of each coder doing it in a different way to each other, but you have that kind of choice all over programming. Even if you removed it from everything you can think of, each person would still differ. That's why you have to actually collaborate and read each other's code. But sure, technical solutions exist for enforcing some elements of style.
It would, however, mean Scala would have to drop the uniform access principle, in which all public Scala fields get an accessor and mutator (if appropriate) automatically and calls that look like they are reading the field directly are actually calling the accessor, allowing one to change the internal representation without changing client code. So I'm not suggesting it for Scala, but in any new language. I'm not especially bothered about punctuation in my definition of simple, though. I'd argue that non-punctuation tokens, where they aren't in the target domain, take more away from readability, as in my invokeLater example Runnable, public, void and run are clearly irrelevant to understanding what the code *means* rather than what it *does*. On Fri, Sep 17, 2010 at 11:30 AM, Reinier Zwitserloot <[email protected]>wrote: > That just sounds like equating "simple" to "less verbose". > > For example, with optional () for args-less method calls, you get a > number of things which one might deem "simpler": > > - Less characters to type and read > - The ability to not have to care about whether the doClick member is > a method or a field > > On the other hand, you also get a few things which are decidedly more > complicated: > > - A stylistic choice about whether or not you add the (). Having to > make an irrelevant choice of any sort clearly seems like a lack of > simplicity to me. > - The INability to tell if doClick is a field or a method. In certain > circumstances it matters, and having to look it up is more complicated > than being able to tell at a casual glance. > > > These are clearly conflicting requirements. Forcing you to care > whether doClick is a field or a method is needless complexity.... > unless it isn't, in which case not being able to tell is needless > complexity. Offering the programmer the choice doesn't help, because > the choice in it self is needless complexity, and by existing we still > can't tell, given "foo.doClick", if doClick is a field or a method. > We'd have to rely on a programmer following the local style guidelines > (if, say, these state that non-fields ought to be called with parens), > which you can' even unit test. Now we're introducing needless > complexity there. > > Oh, how complicated. > > There's also the issue of moving complexity around to the problem > domain. My usual retort to those complaining about the complexity of > generics is simply this: Co- and Contravariance is _inherently_ > complicated. When you have a problem where generics is required or > seems quite useful, then the problem has this complexity, inherently. > You can choose not to use generics, but then the complexity is just > hidden away in javadocs and a bunch of casts. You can tweak generics a > bit, declaration-site generics probably being the most drastic, but a > truly "simple" generics will never be, because co/contravariance isn't > simple. > > So, did java become more complex when 1.5 was introduced? Yes. Does > this mean java 1.5 is worse than 1.4? No - in fact, it's better. > > So, in certain ways, a more complex language is actually a good thing. > > Hence my conclusion that all this talk about "complexity" is not going > to convince anybody one way or another, because its very very easy for > anyone reading the word "complexity" and imagine whatever situation is > least likely to convince them. > > So, to try and mitigate this, here's where I believe scala has added > needless complexity: > > Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean by > DSLish features (yet another vague term that can mean just about > anything). Should I put () after an args-less method call? There's a > stylistic choice there. dots to dereference? Another stylistic choice. > Use operator overloading, or not, and if I do, left-associative or > right-associative? There's also boatloads of semantic choice in scala. > If I need to iterate over a map and, say, produce a list containing > the concatenation of each key and associated value, in java there's > really only two obvious ways to do it. Both involve looping, and the > only difference is whether I iterator over entrySet() or keySet(). In > scala, there's _way_ more choices. I can do a java-style loop, or I > can use an each construct that fills the list, or I can turn the keys > and the values into two sets, and then zip them up, functional style, > or I could use a comprehension of some sort. > > Why is this bad: > > Well, obviously a language can't eliminate _all_ stylistic choice. At > the very least you have to pick a name for your methods, and naming is > clearly up to you, the API author. But, scala goes _way_ too far in my > opinion. While it seems like a nice idea, give an API designer, and an > API user, the ability to write in whatever feels most natural (i.e. > readable, easy to maintain), that's great! Except when it isn't: By > introducing all these stylistic choices, you're forcing the API user > to pick at every stage. Sometimes, this choice is good, because the > benefits of picking the best option available outweigh the burden of > having the choice. In all other situations, though, this choice is not > useful at all. It makes sharing code harder (because Joe likes 'each', > but Jack likes 'for'). This is like spaces v. tabs: The flexibility of > using either really isn't helping. We'd have been better off if back > in the day someone put their foot down and declared some indent style > to be the only one compilers will accept from here on out. Deviation > from this one rule results in compiler warnings. I can't claim to be > very scientific about it, but to me it feels like Scala has gone > waaaay too far down the "give the programmers the flexibility" path. > Where the flexibility helps me make code do different things, that's > fantastic. Where this flexibility boils down to the exact same end > result, and I just have many different ways of expressing the same > concept, usually, it's just a bother. It's needless complication. > > The python folks differentiated themselves from the Perl folks early > by turning Larry Wall's "There Are Many Ways To Do It" around into > "There Is Only One Way To Do It" and I subscribe to the theory. > Introducing stylistic choice needlessly is always bad. But yet again > there's a dichotomy here: Where stylistic choice turns from pointless > to useful is a moving target, there isn't a single answer to the > question. > > Perhaps I was unclear about my comment in regards to using java > libraries in scala code: If you're going to write scala, then... write > scala. Which means you use THEIR collection APIs. If you stick with > java.util.List, then interopping with other scala code is going to be > a nightmare, and even if most scala programmers are familiar with the > java APIs (which is clearly an argument that can't scale: If scala > outgrows java in popularity, or gets even remotely close to it, how > can that possibly be true?), its like not following the camelcasing > conventions in java code. It throws people off, makes your code > ridiculously hard to understand. Just don't do it. There's no going > halfway, and there's not much point (as you said too) in trying to > stay up to date with both java and scala. Pick one. That's your go-to > language for larger projects where static typing is nice, and/or speed > is not unimportant. If you want to learn more languages, fantastic. > But don't pick java and scala. That's a silly combination, the problem > domains where these 2 languages shine overlap far too much. > > On Sep 17, 10:42 am, Ricky Clarkson <[email protected]> wrote: > > Reinier, > > > > You want a definition of simple? Ok, some code is more simple than some > > other code if it contains fewer tokens that are outside the domain. > E.g., > > Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++. Java's > > SwingUtilities.invokeLater(new Runnable() { public void run() { > > button.doClick(); } }) is not as simple as Scala's: > doLater(button.doClick). > > > > Staying cutting edge on Scala is easier as it does not require a cutting > > edge runtime. > > > > In my opinion, for tasks for which Java is a reasonable option, so is > Scala, > > as it is typed and runs in the same environment. I wouldn't look at > Groovy, > > JRuby or Jython for those, because they are untyped. > > > > Regarding writing in DSLs, pretty much all code unless it is spaghetti > ends > > up being written in a DSL. For example, at college I saw plenty of > Pascal > > users writing lots of lines like: > > > > gotoxy(3,4); > > write('|'); > > gotoxy(5,6); > > write('-'); > > > > to draw ASCII forms etc. I wasn't actually studying computing at the > time, > > so I didn't have to write any of that code, but it seemed logical to me > to > > make a procedure writexy(x: Integer, y: Integer, char: Character) to > write > > the above as: > > > > writexy(3,4,'|'); > > writexy(5,6,'-'); > > > > That is, I invented a DSL and used it, without knowing what one was. It > has > > nothing to do with missing out a dot in Scala. > > > > (Incidentally, Pascal was the first semi-colon delimited language I came > > across after years of BASIC, and I was learning it by following the > compile > > errors. The compiler told me it was expecting a ; at the beginning of > the > > line, so that's where I put them! I got some funny looks when I showed > the > > Computing students that code) > > > > Regarding productivity loss or gain from moving to Scala, I did screw up > one > > project by doing this, but that was more to do with my then lack of good > > engineering practices. For example, I had moved from 20031112-source.tgz > > style 'version control' to darcs, and then moved to Windows, where darcs > was > > not then supported very well, so I went without version control for a > while > > (the real issue being that I had no server to speak of to store code). > That > > was manageable, though not ideal, but when I moved to Scala I could > really > > have done with 'game save points'. As a result I went some months > porting > > to Scala without a successful compile, and being unable to roll back to a > > working point. Eventually I got it compiling and all the unit tests > running > > again, but the UI was in tatters. I still hope to resurrect it (I was > > allowed to make it open source when I left, meaning I could finally host > it > > on a public svn/git server, oh the irony). > > > > I expect nobody on this list is at the point I was then; we probably all > use > > version control and use it reasonably well, and it is easier now to port > to > > Scala than it was, as Scala can do mixed-language compilation (by being > able > > to parse just enough Java). Thankfully it was a pretty low risk project, > > but it did sadden me. > > > > Since then I've only had benefits from using Scala, but then I have > become > > competent in version control, I now use tickets to manage tasks instead > of > > emails or bugs.txt files in the codebase, and perhaps more importantly > I'm > > kept honest by the fact that I'm expected to make releases all the time. > > The project I screwed up was only used from February to May every year > > (apart from some random people in Colombia who got hold of it). I don't > > think the screwup was Scala-specific at all, I'd have made the same > mistakes > > porting to any language. > > > > Your point about Scala users being uninterested in your code because it > uses > > Java libraries seems completely false. Most Scala programmers are very > good > > Java programmers, and probably over half of them know Java's standard > > library better than Scala's. > > > > On Fri, Sep 17, 2010 at 1:05 AM, Reinier Zwitserloot <[email protected] > >wrote: > > > > > > > > > > > > > On Sep 16, 6:22 am, Sean Griffin <[email protected]> wrote: > > > > 1. People say Scala is complex, but the actual examples that attempt > > > > to prove this complexity are rare. > > > > > No they aren't. > > > > > > Features that support *writing* > > > > DSLs are often used as those examples. I've done a fair amount of > > > > Scala development. I have yet to write a DSL. > > > > > You've written in DSL plenty of times already. Ever omitted the 'dot' > > > when dereferencing? Ever decided not append "()" to a method call that > > > doesn't require any arguments? You're a winner already! The DSL nature > > > of scala does in fact leak out more during using a library intended to > > > be used that way than vice versa. Operator overloading, omission of > > > dot for dereference, omission of parens, the underscore shortcut when > > > inline-specifying a closure, these are what are meant (or at least, > > > what I mean) when I refer to scala's DSL features, and these are ALL > > > things that are to be typed by the USER of a library, not the writer > > > of one. Unlike e.g. generics wildcards which casual use of a library > > > won't ever bother you with. > > > > > > 2. Capabilities that currently exist in Java are simpler in their > > > > Scala equivalent > > > > > You keep using that word, "simpler". This discussion is a lot more > > > nuanced than that, unfortunately. What you keep calling "simpler" I > > > tend to consider more complicated. And yes, I've used scala, rather a > > > lot even. I'm not equating "simpler" with "doesn't look familiar". > > > Until you define what you mean with simpler, I don't think this is > > > going to get past the "he said, she said" phase. > > > > > > I won't be able to use Java 7 for probably 4 more years. I can't > even > > > > use Java 6 yet because I have to remain compatible with a Java 5 JRE. > > > > > But staying cutting edge on scala is legit? Talk about using two > > > yardsticks. You're actually going with "scala is better because its > > > more stable"? Good luck with that argument. > > > > > > Lombok could give me easier data classes but wouldn't allow me to use > > > > them in pattern matches. > > > > > Ah, yes, just keep moving the goalposts, I forgot. > > > > > > only that it's worth a serious look. > > > > > In contrast to, let's say, groovy, jruby, or jython? Are those not > > > worth serious looks? > > > > > > Finally, the whole "drastic as switching to an entirely new language" > > > > argument doesn't hold much water with me. Learning the language is a > > > > one time thing. > > > > > Of course it isn't. That's ridiculous. Scala revs fast (an argument > > > being used by e.g. Kevin to convince people to switch, no less!). I > > > need only point at scala 2.8 which is a massive update, for example. > > > Even if scala didn't rev like its a fairly new language, there's the > > > community. They release new, major libraries all the time. Styles > > > change, too. Even java has this quirk: 5 years ago, the builder > > > pattern wasn't all that famous and methods returning self so they > > > could be changed where quite rare. Now you see them everywhere. joda- > > > time and guava are used in lots of places, but they didn't exist 5 > > > years ago. Somebody's kicking the tires on the web framework world > > > every other year, it seems. Scala is of course no different. > > > > > Long story short: Claiming that learning a language is a one-time > > > investment is a falsehood. > > > > > This isn't a bad thing, but it does highlight yet again what I keep > > > saying: If you're going to switch to scala, then switch. Going halfway > > > is not a good idea. > > > > > Any product you can write in scala, you could write in java, and vice > > > versa with no more than a ~25% productivity loss, and that's in rare > > > and extreme cases. The "right tool for the job" is not useful in such > > > a scenario. The effort in keeping up to date at two languages costs > > > you more in total productivity loss using either language than what > > > you gain by being able to switch to the one that's better suited at > > > the job. No, if you're going to go down this path, you should learn > > > javascript (because html+web is something completely new from giving > > > people a swing app to download, for example), or javafx (because > > > writing certain GUIs in javaFX is easily 2 to 3x faster than doing so > > > in swing), or a new web framework, or something like haskell (more to > > > learn more about writing code in java/scala than actually add a tool, > > > but that's good too!) > > > > > > Learning each new library's API or framework, > > > > regardless of the language, is a continual thing and we never > question > > > > that! > > > > > Scala, by for example replacing the collections library, means you > > > need to not just learn a new language, no, you've got to learn an > > > entirely new API too. Yes, you can interop with java's libraries, but > > > then you're on your own. The vast majority of java programmers can't > > > read your stuff very well because its scala, but the vast majority of > > > scala users don't really want to mess with your code because its using > > > non-standard libraries. This doesn't work. You need to switch over > > > completely, as I keep saying. > > > > > Technically the idea of a java clone that just cleans up a few issues > > > may even work (I doubt it'll be compelling enough to cause many people > > > to switch), but at the very least such a language will not introduce a > > > significant amount of new API. Scala is not that language. Scala is a > > > major change from java. Most actually prefer it that way. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
