Ada requires too much typing!
in [ADA]
|
Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Luis Espinal on 28 May 2010 01:25 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.
From: Yannick Duchêne (Hibou57) on 28 May 2010 02:47 Le Fri, 28 May 2010 07:25:15 +0200, Luis Espinal <Luis_member(a)newsguy.com> a écrit: > the > boiler plate required for checked exceptions (which no other language > has), > [...] > lack of operator overloading and checked exceptions were What is this about âcheckedâ exceptions ? (a non-Java guru talking). > lack of "elvis" operators, and Elvis ? Does it mean the same as with the good-old Borland Turbo-Pascal ? -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Georg Bauhaus on 28 May 2010 05:48 On 28.05.10 07:25, Luis Espinal wrote: > 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. Just for a better understanding, does the following example exhibit some of the generic syntax "abomination"? import java.util.HashMap; import java.util.TreeSet; public class News<T extends Comparable> { class Things extends TreeSet<T> {} class Counts extends HashMap<Integer, Things> {} int howmany(final Counts in_here) { int sum = 0; for (Things t : in_here.values()) { sum += t.size(); } return sum; } } Has Andrew Appel's Critique of ML influenced the syntax? I would hope so; Appel explains in some detail the mistakes that were carved in stone when defining ML; a quick scan of FunDef and Expr in the Scala syntax makes me assume---perhaps wrongly---that once again I need not mark the end of things!!! (Which typically entails horrible error messages such as when the next definition is parsed as the second argument to the foregoing definition, in which the programmer had forget the second argument *and* omitted the optional end marker.)
From: Alex R. Mosteo on 28 May 2010 06:10 Luis Espinal wrote: >(...) > We have also come to learn that interfaces, the prohibition of multiple > inheritance, (...) were not a good idea at all. Thanks for the elaborate reply. Not expert in Scala/Java so I can't comment about most of it. However, seeing that Ada has just copied Java interfaces, I'd like to known a bit more in detail why you say what I quoted, if you have the time. I have used interfaces a bit and indeed have some grudges with them, but I'd like to know if the situation is worse than I think -- or perhaps I'm not using them 100% properly. Thanks in advance, Alex.
From: Warren on 28 May 2010 11:26
Adam Beneschan expounded in news:c86a76ae-5b25-4c13-a026-5439a57803f6 @k25g2000prh.googlegroups.com: > On May 27, 10:10�am, Warren <ve3...(a)gmail.com> wrote: >> Not so (snickers) - Perl is read once, rewritten many times. >> >> Even the perl code's author can't remember how it worked, >> 3 months later ;-) > > That's why Perl, and many other computer languages, provide features > called "comments". But I suspect our friend Rex would think that the > purpose of comments is just busywork to prove to some evil IT > supervisor that his employees aren't lazy. :) > > -- Adam I once had the, ahem, pleasure of fixing a summer student's program after he left to resume his education. He obviously did not understand what comments where for. They were mostly like this one: -- The next statement adds 1 to the current value of I I = I + 1 Yikesy! The comments not only didn't help but they got in the way of reading the code (not to mention that variables were also poorly named). Warren |