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: Dmitry A. Kazakov on 30 May 2010 03:27 On Sat, 29 May 2010 20:49:09 -0400, BrianG wrote: > -- If writing programs were more important than reading them, we'd be > programming with invisible ink. Mean this: http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on 30 May 2010 05:17 Le Sun, 30 May 2010 09:27:58 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: >> -- If writing programs were more important than reading them, we'd be >> programming with invisible ink. > > Mean this: > > http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 I like the quote on the homepage: http://compsoc.dur.ac.uk/whitespace/ > What are the advantages of Whitespace? > > Some things which are difficult in other languages are made much > easier in Whitespace. For example, literate programming is simply a > matter of writing your helpful comments in between program > instructions. Dear friends, we have our UML killer. Have a Merry Christmas -- 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: Simon Wright on 30 May 2010 05:51 "Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes: >> What are the advantages of Whitespace? >> >> Some things which are difficult in other languages are made much >> easier in Whitespace. For example, literate programming is simply a >> matter of writing your helpful comments in between program >> instructions. I see there is an Emacs mode -- life is complete http://compsoc.dur.ac.uk/whitespace/tools.php
From: Luis Espinal on 1 Jun 2010 17:30 In article <hto4st$7g2$1(a)news.eternal-september.org>, Alex R. Mosteo says... > >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. Hi Alex - sorry I didn't reply sooner. I've been on the grind at work in the last couple of days. The issue with interfaces (which is not universally accepted among Java developers) is that they cannot be changed without incurring in changes to classes implementing that interface. This is a big issue for the way in which code is developed in Java. Let me try to illustrate: The common practice in Java is find a platform or framework (some sort of high-level "virtual" OS for lack of a better word.) Then, either write your apps on it, or develop another platform on top of it (another, more refined, more business-specific "virtual" OS. So pretty much we (try to) gradually refine the architecture of an application via an architecture pre-defined by the runtime below it. Examples of this are JEE, Spring and the Eclipse framework (and all the stuff + the kitchen sink that we throw on top of them.) All those layers are typically defined with interfaces (since we don't get multiple inheritance or mixin/traits). We end up with these long class hierarchies, and lots and lots of artifacts implementing lots and lots of interfaces. Libraries and libraries, and platforms and platforms... without a concept of versions. So for example, you have an interface named A that defines a method foo(): public interface A { public void foo(); } And then you have a large number of classes implementing A, which are distributed to 3rd parties. A while later, you find you must include a new method on interface A: public interface A { public void moo(); } The moment you do that, you render every library that depended on old A unusable. Either your clients won't be able to compile it, or if they will get nasty run-time errors. The JVM will even refuse to load the old classes because they do not conform with the new interface anymore. The folks in the eclipse framework, for example, have had to deal with this problem by implementing "versioned" interfaces and have code deal with them at run-time: public interface A { public void foo(); } public interface A_1 { public void moo(); } class clientOfA { void dooFooAndMaybeMoo( A someA ) { ... if( someA instanceof A_1 ) { ((A_1)someA).moo(); } ... } This could get out of hand (specially with sloppy programmers which, in Java, unfortunately we have too many.) This can also be a concern with people that develop frameworks and libraries for both external and internal use. So what we do is that, in addition to implementing an interface, we typically extend a an abstract base class that can insulate us from possible changes to the interface: public interface A {...} public abstract class AbstractA implements A {...} public class ConcreteA extends AbstractA {...} If we need to change A, we simply change AbstractA so that clients of A that extend AbstractA don't get forced to change their source... but that doesn't do anything for those that still extend A directly. And having an abstract base class like that defeats the purpose of being able of creating arbitrary implementations of an interface. Other folks deal with that problem by creating Adapters... ending up with a soup of design patterns going wild. Some people still think this is still a better trade-off over C++ styled multiple inheritance because of the dreaded "diamond" problem. To me (and this is strictly a personal opinion), it isn't. That's a lot of manual shamanism that should be better dealt with syntactically. We should have had multiple implementation inheritance from the get-go and just deal with it using the tools of the language and careful planning. I think the Scala guys had the most wonderful of ideas by implementing Traits. They offer many of the benefits of interfaces while simplifying the ability of inheriting multiple implementations. The focus is no longer on building behavior not just with inheritance but also with composition. I don't need to worry if my object is a-something to that can do a-task; I just have to worry that it can perform the task. I do think that interfaces have been great for specifying contracts. They enforce an order on things. However, it is important to plan ahead regarding interface versions. I don't know if this is a big deal in Ada-land, but in the JVM-land, it has been. Please take it with a grain of salt. It is simply my observation, and with software YMMV from one context to another :) - Luis Espinal (luis.espinal(a)gmail.com)
From: BrianG on 1 Jun 2010 21:42
Simon Wright wrote: > "Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes: > >>> What are the advantages of Whitespace? >>> >>> Some things which are difficult in other languages are made much >>> easier in Whitespace. For example, literate programming is simply a >>> matter of writing your helpful comments in between program >>> instructions. > > I see there is an Emacs mode -- life is complete > > http://compsoc.dur.ac.uk/whitespace/tools.php But what about a translator to-from Ada? Could you 'polyglot' the same program for added security? :-) --IN A WORLD WHERE I FEEL SO SMALL, -- I CAN'T STOP THINKING BIG. |