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: Nicholas Collin Paul de Gloucester on 4 Jun 2010 07:29 On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent: |-----------------------------------------------------------------------| |"Le Thu, 03 Jun 2010 18:54:57 +0200, Colin Paul Gloster | |<Colin_Paul_Gloster(a)acm.org> a écrit: | | | |[..] | |+---------------------------------------------------------+ | || " Passing a parameter to an Ada subprogram can look | | || like choosing an element of an Ada array, with a very | | || different execution cost. " | | |+---------------------------------------------------------+ | |[..] | | | |And you will nor see difference of execution cost between two different| |functions." | |-----------------------------------------------------------------------| Actually, you would. Different functions would have different bodies would tend to have different execution costs. Aside from that, inlined functions would tend to cost differently than other functions. However, I had not been posting re different functions. I posted re utilizing an array and utilizing a subprogram. These can look identical but cost very differently.
From: Nicolas Cóilin Paul de Gloucester on 4 Jun 2010 07:40 On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent: |---------------------------------------| |"> Box design: (c) Colin Paul Gloster."| |---------------------------------------| Nicolas Cóilin Paul de Gloucester to you. Actually I did not invent it, but thank you for a bit of fun. |---------------------------------------| |"(was confused with names)" | |---------------------------------------| Francophones had been historically noted for being confused by names, not least of all Gaelic names. Bye, me
From: Ludovic Brenta on 4 Jun 2010 09:54 Nicolas Cóilin Paul de Gloucester wrote: > On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent: > > |---------------------------------------| > |"> Box design: (c) Colin Paul Gloster."| > |---------------------------------------| This box design is a nuisance to me; I don't want to have to teach emacs how to fill a boxed paragraph in gnus; M-q fills paragraphs beginning with most quoting characters (>, !, |, etc.) correctly but not boxed ones. In Google Groups, boxed paragraphs are ugly when in proportional font. > Nicolas Cóilin Paul de Gloucester to you. > > Actually I did not invent it, but thank you for a bit of fun. > > |---------------------------------------| > |"(was confused with names)" | > |---------------------------------------| > > Francophones had been historically noted for being confused by names, > not least of all Gaelic names. That's your fault. How many different names or spellings thereof do you post under? Just in the past 24 hours I've seen variations like: Colin Paul Gloster Nicolas Cóilin Paul Gloucester Nicolas Collin Paul de Gloucester Nicolas Cóilin Paul de Gloucester Nicholas Cóilin Paul de Gloucester So, is your name really a regexp? Is this one in extended syntax correct? (Nich?olas)|(C[óo]l?lin) Paul (de)? Glo(uce)?ster How about just "Paul" which seems to be the only constant? -- Ludovic Brenta.
From: Luis Espinal on 5 Jun 2010 15:58 In article <hu5e4u$6il$1(a)news.eternal-september.org>, Alex R. Mosteo says... > > >Hi Luis, thanks for the detailed reply. I understand your points clearly. > >My days of Java are a bit behind so I'm not sure what I'm about to say can >be done in Java. In Ada, one could extend an interface adding a new method >like this: > >procedure Moo (This : A) is null; > >And effectively it won't break any client, since it provides a default "no- >op" implementation. It won't work for functions, obviously. In any case, >clients would need to recompile, since in Ada land we're not talking of a >world of JVMs and dynamic hot-plugging, I presume. This alone (the use of >stand-alone executables) may make the problem much less of an issue. > >Also, not needing to specify defaults to overload a method could be of help? > >procedure Foo (This : A) is abstract; -- Added in 1st spec > >procedure Foo (This : A; Bar : A'Class) is null; -- Added in 2nd spec > >I've done sometimes the thing of having a insulating base class providing >some/most of the interface core functionality, but at the same time I >realized that this defeats to some degree the point of interfaces, since you >can't inherit from two such base classes. > >In any case I feel your pain about the lot of Java programmers and >frameworks ;-) I guess it has its goods and its bads. > >Alex. > That actually seems like a much better implementation of interfaces than Java's. I think it would have been interesting if Ada interfaces were to provide a default behavior for function that throws an exception when called. In Java, we usually have to inherit functions off interfaces for which no appropriate behavior exist, and thus the usual convention (manually implemented mind you) is to add a throw UnsuportedOperationException() for those functions. That'd probably be appropriate for enterprise systems, but not for critical systems which is probably why it is not implemented in Ada. You are right to point out that in Ada things compile or do not. In Java we never really know who is going to dynamically load (or inherit) from artifacts of our making. - Luis.
From: Luis Espinal on 5 Jun 2010 16:13
In article <op.vdob5ebexmjfy8(a)garhos>, =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= says... > >Le Tue, 01 Jun 2010 23:30:54 +0200, Luis Espinal <Luis_member(a)newsguy.co= >m> = > >a =E9crit: >> 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 >Is it one of the reason why Java is virtual machine based ? is it relate= >d = > >to this process or not ? > Not quite Yannick. Originally Java (called Oak then) was intended to run in certain embedded devices. Having a streamlined virtual machine with a uniform set of libraries and I/O abstractions would allow the language to run in multiple architectures. As it evolved, its potential for networked/distributed systems development became more apparent. All that was occurring at a juncture when enterprises were moving into the client-server area (and then into internet-based systems). Java fitted the bill better than what was available then. You didn't have to drop your previous investment in AS/400 machines, for example. You could run your Java apps there, and as you buy new hardware (almost any type of hardware) when you needed to scale up (again, w/o having to throw away your previous machinery.) So basically, the jvm (java virtual machine) was created to allow the java compiler to spit Java bytecode that would run in any hardware architecture that had a jvm written for it. Now the tables seem to be turning. Java is no longer the target, but the jvm and the bytecode that it runs that are the target. People are now developing new languages for the jvm (and for .NET clr, Window's vm), languages that provide better programming facilities than Java. Scala is one example. The promise is also to have the same exact bytecode (or at least have the same source code compiled) running on both jvm and .NET clr. Google is implementing a different java virtual machine called Dalvik for the android platform. Dalvik's is register based whereas Sun's is stack-based. Not to belittle Java's contribution, but it seems that in the long run, Sun's long lasting legacy will be its Java virtual machine instead of the Java language itself. - Luis. |