On Thu, May 20, 2010 at 09:35, Nick Wiedenbrueck <[email protected]> wrote: > Do you think, these concerns are valid?
I would tend to agree with you. I think the best language is that can solve most with less different paradigms. The less to learn for new young developers, the faster they can get productive, the better anyone can read someone else's code (which seems very important to me because a lot of projects are abandoned as soon as the main developers leave). On the other hand, if a language has many "features", it might be more attractive for the experienced developer. In Java I already have a few things I never missed in other languages. Generics - as you mentioned them - are in my opinion very useful to ensure a collection does only contain objects of a type you are expecting. They are very useful also as without generics a lot of auto-completion in IDE would not work. But in the past (using VB for example where I didn't have generics) it happened in veeeery rare cases that I attempted to add a wrong object to a collection and the bug was easily discovered in early testing phase. On the other hand I had a lot of use cases where it was intended to deal with different object types in a collection. I have seen Java code making excessive use of anonymous classes. I would never ever code that way - maybe it is because I either hadn't that option in VB. On the other hand I had properties in VB which is desired for Java by many Java developers. I can say, that I prefer the java way with getters and setters just by convention. It is more flexible with usage of less "reserved words" - the simpler approach. - And in VB I had to invent different prefixes for internal and property variables - that is simply more straightforward in Java. Maybe the amount of reserved words help measuring the complexity of a language. ;-) I think, the main issue with all discussions like this - which is related to the discussions about the future of Java - is: On one hand the language should allow the developer to do much quickly (by writing less "boilerplate" code) and on the other hand following the KISS principle to make it easy readable also by less experienced developers or newcomers and to avoid bugs. The golden way of the middle is not so easy to find. On Thu, May 20, 2010 at 10:40, Kevin Wright <[email protected]> wrote: > Be careful that you don't make the mistake of assuming Java is simple, just > because you know the language. I consider myself being still new to Java (in comparision with most other Java developers I am in contact with). > On Mon, May 17, 2010 at 10:49 PM, Erik > Engbrecht <[email protected]> wrote: >> I think Scala is very large compared to languages like Python or Java, but >> smaller than C++. >> By "large" I mean there are a lot of concepts in the language. Just to >> list a few that aren't in Java... > ... I am always a bit uneasy when reading a list like this and arguing with > it. Yes, Scala has a lot of features but it tries very hard to make them > facets of a uniform core which is not that large. I realize that for a > newcomer, in particular someone brought up in the C/Java tradition, Scala > might look large. For instance, objects/companion objects which you mention. > If you do an in-depth study of language specs, these are actually > significantly simpler then Java's static class members. I would doubt if most programmers would dig so deep into the specs. Many just learn by looking first of all at examples for instance. > I don't want to get into a feature to feature comparison between languages. > My main point is, that, if you draw up a list of bullet points you can make > any language look forbiddingly complex. You are right, I agree with you. > I certainly agree that if Java is your point of departure, then there is a > lot of new stuff to learn in Scala. My argument is that there is also a lot > of stuff in Java that people take more or less for granted but that is > pretty complicated under the covers (and I argue from quite intimate > experience here). I learned the basics of Java very fast - the most "work" when learning Java was for me to get all those abbrevations and get an overview over the big standard libraries and then all the other 3rd party stuff available. The Java world is huge in comparison to .NET for instance from my feeling. Strange because at the client you don't see that really. But I think on the server side it is full of Java. > Some measures: The grammar of Scala is actually smaller than the grammar of > Java. Surprising for me. I watched a presentation of Scala (unfortunately I can't find it now) where there have been demonstrated for a few things about 5 styles of writing exactly the same one-liner thing. I find this simply stupid. A computer program is not like a poem that should allow the writer to introduce his own "art". One important goal of a language nowadays should be that it is easy to use and understand (which helps to reduce bugs). The user is the programmer. If it is complicated under the hood in reality is a different story (I think that quite everything can be complicated if you look under the hood). > The typechecker of Scala is about the same length in lines of code as > the type checker for Java, or the type checker for Haskell. Of course, every > type checker is written in its own language, so you can draw an infinite > number of conclusions form that, all of the form: If there is an infinite number of possible conclusions it is maybe not worth thinking of either one. And BTW: Who cares about the length of the type checker? - One that is developing the language itself may find it great or annoying, for an application developer using the language surely not. I never knew the length of the type checker (or other similar under-the-hood things) for any language I used. > Scala's type system is X-times more complicated than Java's or Haskell's, > but code written in the language is X-times more compact When I was writing in C++ it was mostly harder to read other's code then when developing VB - not only, but also because often people wrote very "compact" C++-code. Compact code is not always good. That said, I hated the COBOL programming. - Java is a good way of the middle - IMHO. I will not ignore people's need of adding new language features to Java but I do really agree that there is a lot of thinking before doing. Wisely choose what to add and how! What once got into is hard to drop later if it turns out of being a wrong decision. BTW: Nobody argues that there pass many years before a new C++ version is released (actually there is planned an update for next year or so) and so many still use the language. I further do consider new languages a good testing field for paradigms, but a developer should have the choice to use something stable (comparison like with Debian stable vs Ubuntu). I consider Java as a stable language and languages like Groovy or Scala as "testing". I don't want to say that those languages can't be used in production - I also use Ubuntu servers in production. But I want to have the option. -- Martin Wildam -- 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.
