From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5af5c381381ac5a7,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!drn From: Luis Espinal Newsgroups: comp.lang.ada Subject: Re: Ada requires too much typing! Date: 27 May 2010 22:25:15 -0700 Organization: NewsGuy - Unlimited Usenet $19.95 Message-ID: NNTP-Posting-Host: p41980d031258cfc2b78d93435cd4d15828057de134223b90.newsdawg.com User-Agent: Direct Read News 5.60 Xref: g2news2.google.com comp.lang.ada:12104 Date: 2010-05-27T22:25:15-07:00 List-Id: In article , Peter C. Chapin says... > >However, the argument that I see some people putting forth on the Scala group >is that conciseness is good because it saves typing. I really can't >understand that. How hard is it to type? You have to understand the Scala argument within the context of verbosity in Java (I'm a Java developer btw.) For many things in Java, Swing programming for example, we require the creation of (usually anonymous) classes implementing listener interfaces or swingthread base classes. After a few non-trivial additions, the syntax becomes horrendously heavy and unwieldy. There is no notion of nested methods, much less passing functions as parameters (as in Scala.) That is the type of syntax conciseness and facilities (which are missing in Java) that makes this type of task easier to read, reuse and maintain. With the addition of generics in Java, the situation has gotten worse. We need to use generics to make typing stronger (and to avoid run-time casting errors). And yet, the syntax is terrible. Try to create, say, create a function that takes as argument, say, a Map parametrized with subclasses of a given parametrized class as keys, and container parametrized to a different type as values. It's an abomination. In Scala, it is much simpler and efficient, ergo more economical. > >One of the people on that group posted this comment related to the fact that >Java requires public/private access specifiers on methods whereas Scala uses >public by default. Thus in the "common" case of a public method you don't >have to type the word 'public'... > I don't think that is much of an issue. Mutability is. This is a big issue for Java as it has turned out. The commonly accepted best practice now is to mark variables and parameters as final unless you know before hand that you want to change them. This is a big improvement, but it is not the default behavior. It is in Scala. > >The whole "I will make you do extra work coding just so you can demonstrate >to me that you're not being lazy" attitude of Java is perhaps useful in some >situations, but we already have Java for that.  I don't think adopting that >attitude of making you do busywork would be an asset for Scala. > >  --Rex This doesn't make any sense. It has nothing to do with being lazy. Verbosity has its place when you want to make some sort of intention clear. That is not the case in Java. The verbosity that we get now in Java with the addition of generics (which you don't get in Scala), the inability to create lambdas (which we can in Scala, Groovy and JavaScript), lack of "elvis" operators, and the boiler plate required for checked exceptions (which no other language has), that's what makes things very difficult to create. And you can create something that can compile and still not work as intended because the verbosity gets in the way (specially when you need to throw "super" or "extend" into the parameter declaration.) The code that we create now, post Java 1.5 is a lot different from what was being built when the language was first envision. After the addition of generics, the verbosity that we use to praise now gets in ways we never imagined. We have also come to learn that interfaces, the prohibition of multiple inheritance, lack of operator overloading and checked exceptions were not a good idea at all. Scala represents a re-thinking on programming on the JVM that has come out of necessity, and it will most definitely engender Java's replacement within the next 10-15 years. Verbosity only has its place if it makes your intentions readable and if it has precise, easy-to-understand semantics. Verbosity with obscure semantics, that doesn't give you anything, that can compile and give you hard-to-find errors, we don't need that. You got it completely wrong. That's not laziness. It is cleaning out the garbage and bring a new (and hopefully better) way to program the type of systems we want to run on the JVM. I would strongly suggest you listen to the JavaPosse and Software Engineering Radio podcasts that relate to Scala and other alternative JVM languages. They do a good job at explaining the reasoning behind the shrinking of verbosity. If you don't believe me, just try the example I mentioned (the parametrized Map with subclasses of a parametrized parent as keys, and collections parametrized to a different type as values.) It is not an uncommon construct or a proof-of-concept toy. It is very easy to have combination of 3, 4 parametrized types, or more. Try to get that to work on Java, and then on Scala. You'll soon appreciate their point of view has nothing to do with being lazy.