* If not Ada, what else... @ 2011-04-20 10:39 Alex R. Mosteo 2011-04-20 10:51 ` Ludovic Brenta ` (7 more replies) 0 siblings, 8 replies; 168+ messages in thread From: Alex R. Mosteo @ 2011-04-20 10:39 UTC (permalink / raw) Hello, I'm a big supporter of Ada, but I'm the only person that I know that uses it in my work environment (mobile robotics research). Everyone is using either C, C++, python or java. I ceased looking into other languages because I am so comfortable with Ada. I fear I may have missed some interesting boat. Do you know of other languages worth to look at (i.e. that will make an Ada programmer somewhat happy), that are at least as "popular" as Ada, besides these ones mentioned above? ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo @ 2011-04-20 10:51 ` Ludovic Brenta 2011-04-21 8:47 ` Alex R. Mosteo 2011-04-20 11:53 ` Maciej Sobczak ` (6 subsequent siblings) 7 siblings, 1 reply; 168+ messages in thread From: Ludovic Brenta @ 2011-04-20 10:51 UTC (permalink / raw) Alex R. Mosteo wrote on comp.lang.ada: > Hello, > > I'm a big supporter of Ada, but I'm the only person that I know that uses it > in my work environment (mobile robotics research). Everyone is using either > C, C++, python or java. > > I ceased looking into other languages because I am so comfortable with Ada. > I fear I may have missed some interesting boat. > > Do you know of other languages worth to look at (i.e. that will make an Ada > programmer somewhat happy), that are at least as "popular" as Ada, besides > these ones mentioned above? Modula 2? Plain old Pascal? Modula 3 and Eiffel could be contenders but probably not in robotics because they mandate garbage collection; this probably precludes any kind of hard real-time work. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:51 ` Ludovic Brenta @ 2011-04-21 8:47 ` Alex R. Mosteo 0 siblings, 0 replies; 168+ messages in thread From: Alex R. Mosteo @ 2011-04-21 8:47 UTC (permalink / raw) Ludovic Brenta wrote: > Alex R. Mosteo wrote on comp.lang.ada: >> Hello, >> >> I'm a big supporter of Ada, but I'm the only person that I know that uses >> it in my work environment (mobile robotics research). Everyone is using >> either C, C++, python or java. >> >> I ceased looking into other languages because I am so comfortable with >> Ada. I fear I may have missed some interesting boat. >> >> Do you know of other languages worth to look at (i.e. that will make an >> Ada programmer somewhat happy), that are at least as "popular" as Ada, >> besides these ones mentioned above? > > Modula 2? Plain old Pascal? > > Modula 3 and Eiffel could be contenders but probably not in robotics > because they mandate garbage collection; this probably precludes any > kind of hard real-time work. Eiffel is something I will have to check eventually, even if only as a hobby. > > -- > Ludovic Brenta. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo 2011-04-20 10:51 ` Ludovic Brenta @ 2011-04-20 11:53 ` Maciej Sobczak 2011-04-21 8:46 ` Alex R. Mosteo 2011-04-21 17:19 ` Robert Matthews ` (5 subsequent siblings) 7 siblings, 1 reply; 168+ messages in thread From: Maciej Sobczak @ 2011-04-20 11:53 UTC (permalink / raw) On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote: > Do you know of other languages worth to look at (i.e. that will make an Ada > programmer somewhat happy), that are at least as "popular" as Ada, besides > these ones mentioned above? Don't take me wrong, but your question can be translated as: "Do you know of other languages that are *popular*, but that I never heard of and none of my friends have heard of?" So what is the meaning of "popular", then? :-) My advice: don't make your life more difficult that it already is and stick to what you know and like. These are the two most important factors of successful project. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 11:53 ` Maciej Sobczak @ 2011-04-21 8:46 ` Alex R. Mosteo 2011-04-23 2:08 ` Peter C. Chapin 0 siblings, 1 reply; 168+ messages in thread From: Alex R. Mosteo @ 2011-04-21 8:46 UTC (permalink / raw) Maciej Sobczak wrote: > On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> > wrote: > > >> Do you know of other languages worth to look at (i.e. that will make an >> Ada programmer somewhat happy), that are at least as "popular" as Ada, >> besides these ones mentioned above? > > Don't take me wrong, but your question can be translated as: > > "Do you know of other languages that are *popular*, but that I never > heard of and none of my friends have heard of?" Yeah, I guess it was somewhat contradictory. But from time to time I hear about D, Ruby, Scala, and wonder if these are going somewhere or what. Alex. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-21 8:46 ` Alex R. Mosteo @ 2011-04-23 2:08 ` Peter C. Chapin 0 siblings, 0 replies; 168+ messages in thread From: Peter C. Chapin @ 2011-04-23 2:08 UTC (permalink / raw) On Thu, 21 Apr 2011 10:46:06 +0200, "Alex R. Mosteo" <alejandro@mosteo.invalid> wrote: >Yeah, I guess it was somewhat contradictory. But from time to time I hear >about D, Ruby, Scala, and wonder if these are going somewhere or what. I am fond of Scala. It's a very different sort of language than Ada, but in its world it is also very nice. I believe it may be going somewhere as well. Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo 2011-04-20 10:51 ` Ludovic Brenta 2011-04-20 11:53 ` Maciej Sobczak @ 2011-04-21 17:19 ` Robert Matthews 2011-04-21 19:02 ` Georg Bauhaus 2011-04-21 19:25 ` Florian Weimer 2011-04-23 9:52 ` björn lundin ` (4 subsequent siblings) 7 siblings, 2 replies; 168+ messages in thread From: Robert Matthews @ 2011-04-21 17:19 UTC (permalink / raw) Alex R. Mosteo wrote: > Hello, > > I'm a big supporter of Ada, but I'm the only person that I know that uses > it in my work environment (mobile robotics research). Everyone is using > either C, C++, python or java. > > I ceased looking into other languages because I am so comfortable with > Ada. I fear I may have missed some interesting boat. > > Do you know of other languages worth to look at (i.e. that will make an > Ada programmer somewhat happy), that are at least as "popular" as Ada, > besides these ones mentioned above? This may not be quite what you are looking for, but I find it intriguing: "Mercury", located at: http://www.mercury.csse.unimelb.edu.au/index.html For an old Ada programmer the following from the web site gives me a warm fuzzy feeling ;) "Mercury is a new logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features." Shame it doesn't have an Ada back end. Robert Matthews ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-21 17:19 ` Robert Matthews @ 2011-04-21 19:02 ` Georg Bauhaus 2011-04-21 19:25 ` Florian Weimer 1 sibling, 0 replies; 168+ messages in thread From: Georg Bauhaus @ 2011-04-21 19:02 UTC (permalink / raw) On 4/21/11 7:19 PM, Robert Matthews wrote: > "Mercury is a new logic/functional programming language, which combines the > clarity and expressiveness of declarative programming with advanced static > analysis and error detection features." > > Shame it doesn't have an Ada back end. Once I have tried to translate the compiler's sources (in C) on Mac OS X. Only went so far. And only after tackling automess, IIRC. Sad. ;-) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-21 17:19 ` Robert Matthews 2011-04-21 19:02 ` Georg Bauhaus @ 2011-04-21 19:25 ` Florian Weimer 2011-04-22 15:50 ` Robert Matthews 1 sibling, 1 reply; 168+ messages in thread From: Florian Weimer @ 2011-04-21 19:25 UTC (permalink / raw) * Robert Matthews: > For an old Ada programmer the following from the web site gives me > a warm fuzzy feeling ;) > > "Mercury is a new logic/functional programming language, which combines the > clarity and expressiveness of declarative programming with advanced static > analysis and error detection features." If Mercury is in, then the ML family (Standard ML, Objective Caml, Visual F#, Haskell) is probably not too distant, either. 8-) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-21 19:25 ` Florian Weimer @ 2011-04-22 15:50 ` Robert Matthews 2011-04-22 17:49 ` Brad Cantrell 2011-04-22 21:39 ` Florian Weimer 0 siblings, 2 replies; 168+ messages in thread From: Robert Matthews @ 2011-04-22 15:50 UTC (permalink / raw) Florian Weimer wrote: > If Mercury is in, then the ML family (Standard ML, Objective Caml, > Visual F#, Haskell) is probably not too distant, either. 8-) I thnk you are placing Mercury in the "functional" category; think of it rather as a strongly typed Prolog (though with some extra functional bits). Robert Matthews ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-22 15:50 ` Robert Matthews @ 2011-04-22 17:49 ` Brad Cantrell 2011-04-23 2:20 ` Peter C. Chapin 2011-04-22 21:39 ` Florian Weimer 1 sibling, 1 reply; 168+ messages in thread From: Brad Cantrell @ 2011-04-22 17:49 UTC (permalink / raw) If you really want to compare Ada with functional languages, you should try Erlang. The promise of functional languages are in non- mutable variables and functions with no side effects which qualifies a language as being a "pure functional" language. Erlang is almost a subset of Haskell, the only difference is that its dynamically typed. It relies on pattern matching with guards much as Haskell does. But what sets Erlang apart from Haskell is that threading is built into the language so that it has practical value in dealing with the outside world. Whereas with Haskell needing modads to communicate with the outside world, program state is saved in threads with Erlang. I think if you experiment with threading with Erlang and then with Ada you will find that the tasks in Erlang will provide more practical concurrency. Im not saying one is better than the other, I leave that up to you to decide. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-22 17:49 ` Brad Cantrell @ 2011-04-23 2:20 ` Peter C. Chapin 2011-04-23 9:55 ` Georg Bauhaus 0 siblings, 1 reply; 168+ messages in thread From: Peter C. Chapin @ 2011-04-23 2:20 UTC (permalink / raw) On Fri, 22 Apr 2011 10:49:41 -0700 (PDT), Brad Cantrell <cantrellb@gmail.com> wrote: >If you really want to compare Ada with functional languages, you >should try Erlang. The promise of functional languages are in non- >mutable variables and functions with no side effects which qualifies a >language as being a "pure functional" language. Erlang is almost a >subset of Haskell, the only difference is that its dynamically typed. >It relies on pattern matching with guards much as Haskell does. But >what sets Erlang apart from Haskell is that threading is built into >the language so that it has practical value in dealing with the >outside world. Erlang is cool but I have to put in a pitch for Scala here. Scala comes with an "actors" library that is modeled after Erlang's approach to concurrency (message passing). However, like Ada, Scala is statically typed. The upcoming 2.9 release of Scala will also include parallel collections that can be iterated over with parallel for loops (and, in fact, support many other parallelized operations). This is accomplished without adding any syntax to the language. Scala's native syntax is extensible enough as is. For example: // This method operates on a sequence of type T. def someMethod[T](data: Seq[T]) = { for (item <- data par) { // Parallelized loop. Iterations are spread over multiple cores. } } In the above code 'par' is actually a method being applied to 'data.' The for loop ends up being parallelized not because the compiler treats it in a special way, but rather because of the behavior of the 'par' method. Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 2:20 ` Peter C. Chapin @ 2011-04-23 9:55 ` Georg Bauhaus 2011-04-23 11:17 ` Peter C. Chapin 0 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2011-04-23 9:55 UTC (permalink / raw) On 4/23/11 4:20 AM, Peter C. Chapin wrote: > // This method operates on a sequence of type T. > def someMethod[T](data: Seq[T]) = { > for (item<- data par) { > // Parallelized loop. Iterations are spread over multiple cores. > } > } > > In the above code 'par' is actually a method being applied to 'data.' The > for loop ends up being parallelized not because the compiler treats it in a > special way, but rather because of the behavior of the 'par' method. Would 'par' be a normal method or would the programmer make sure that it operates nicely in parallel, e.g. does not mess with "shared" variables? ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 9:55 ` Georg Bauhaus @ 2011-04-23 11:17 ` Peter C. Chapin 0 siblings, 0 replies; 168+ messages in thread From: Peter C. Chapin @ 2011-04-23 11:17 UTC (permalink / raw) On Sat, 23 Apr 2011 11:55:56 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote: >On 4/23/11 4:20 AM, Peter C. Chapin wrote: > >> // This method operates on a sequence of type T. >> def someMethod[T](data: Seq[T]) = { >> for (item<- data par) { >> // Parallelized loop. Iterations are spread over multiple cores. >> } >> } >> >> In the above code 'par' is actually a method being applied to 'data.' The >> for loop ends up being parallelized not because the compiler treats it in a >> special way, but rather because of the behavior of the 'par' method. > >Would 'par' be a normal method or would the programmer >make sure that it operates nicely in parallel, e.g. >does not mess with "shared" variables? 'par' is a method provided by the collections library. The programmer is responsible for making sure the loop body is parallel-safe. Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-22 15:50 ` Robert Matthews 2011-04-22 17:49 ` Brad Cantrell @ 2011-04-22 21:39 ` Florian Weimer 2011-04-23 2:26 ` Peter C. Chapin 1 sibling, 1 reply; 168+ messages in thread From: Florian Weimer @ 2011-04-22 21:39 UTC (permalink / raw) * Robert Matthews: > Florian Weimer wrote: > >> If Mercury is in, then the ML family (Standard ML, Objective Caml, >> Visual F#, Haskell) is probably not too distant, either. 8-) > > I thnk you are placing Mercury in the "functional" category; think of > it rather as a strongly typed Prolog (though with some extra > functional bits). I know that it's closer to Prolog, but it's so far away from Ada that at this point, the distinction does not matter anymore. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-22 21:39 ` Florian Weimer @ 2011-04-23 2:26 ` Peter C. Chapin 0 siblings, 0 replies; 168+ messages in thread From: Peter C. Chapin @ 2011-04-23 2:26 UTC (permalink / raw) On Fri, 22 Apr 2011 23:39:29 +0200, Florian Weimer <fw@deneb.enyo.de> wrote: >I know that it's closer to Prolog, but it's so far away from Ada that >at this point, the distinction does not matter anymore. I also have an interest in Mercury but I haven't had the time to study it much yet. The language is very different than Ada... which is good. I've heard it said (maybe in this newsgroup) that a programming language isn't worth learning unless it changes the way you think about programming. If you've never used a logic language before, learning Mercury will probably have that effect. However, unlike Prolog, Mercury does a lot more analysis statically (and consequently it has much high execution efficiency). My understanding is that one of its goals is to be a logic language suitable for software engineering. On the other hand Mercury is very much a niche language. Is it even out of the research stage yet? Languages like Erlang, Scala, and F# (to name three) bring functional programming to the table and are also being used in at least some commercial ventures. Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo ` (2 preceding siblings ...) 2011-04-21 17:19 ` Robert Matthews @ 2011-04-23 9:52 ` björn lundin 2011-04-23 11:50 ` Piotr Trojanek ` (3 subsequent siblings) 7 siblings, 0 replies; 168+ messages in thread From: björn lundin @ 2011-04-23 9:52 UTC (permalink / raw) On 20 Apr, 12:39, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote: > Hello, > > I'm a big supporter of Ada, but I'm the only person that I know that uses it > in my work environment (mobile robotics research). Everyone is using either > C, C++, python or java. Instead of looking for a new language, you could perhaps talk to these guys? <http://mdh.diva-portal.org/smash/get/diva2:319413/FULLTEXT01> To me, it looks like mobile robotics research. And they do use Ada. /Björn ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo ` (3 preceding siblings ...) 2011-04-23 9:52 ` björn lundin @ 2011-04-23 11:50 ` Piotr Trojanek 2011-04-23 12:23 ` Dmitry A. Kazakov 2011-04-28 12:55 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Alex R. Mosteo 2015-07-03 19:21 ` If not Ada, what else luvhed ` (2 subsequent siblings) 7 siblings, 2 replies; 168+ messages in thread From: Piotr Trojanek @ 2011-04-23 11:50 UTC (permalink / raw) On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote: > Hello, > > I'm a big supporter of Ada, but I'm the only person that I know that uses it > in my work environment (mobile robotics research). Everyone is using either > C, C++, python or java. > > I ceased looking into other languages because I am so comfortable with Ada. > I fear I may have missed some interesting boat. > > Do you know of other languages worth to look at (i.e. that will make an Ada > programmer somewhat happy), that are at least as "popular" as Ada, besides > these ones mentioned above? Alex, I am in a kind of similar position - in my robotics team all the people are using C++. I have simply decided not to bother and do my work with Ada. There are a lot of programming languages around and people use ALL of them to program their robots. Please take a look at the list of languages, which you can use for Lego NXT programming (Ada is also there!): http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Programming The question is what is your focus in a robotics research? If it is a RT control, than I see no point in not using Ada. If you are interested in AI, then Lisp is probably the way to go. It has been shown, that virtually any language can be used for a robotic research. I think you should simply pick a one, which allows you to focus on what is your primary goal. -- Piotr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 11:50 ` Piotr Trojanek @ 2011-04-23 12:23 ` Dmitry A. Kazakov 2011-04-23 14:30 ` Georg Bauhaus 2011-04-23 16:16 ` Piotr Trojanek 2011-04-28 12:55 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Alex R. Mosteo 1 sibling, 2 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 12:23 UTC (permalink / raw) On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote: > The question is what is your focus in a robotics research? If it is a RT control, > than I see no point in not using Ada. If you are interested in AI, then Lisp is > probably the way to go. I always did AI in Ada and see no point in using Lisp for that. There is a common opinion that Lisp and Prolog are good for AI, which is as ungrounded as the opinion that C is good for drivers. I think that Ada is especially good for AI because AI is quite nasty when it comes to testing. Often you cannot figure out whether the problem is due to a bug or a logical error. Ada sufficiently reduces the bug rate. That helps much. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 12:23 ` Dmitry A. Kazakov @ 2011-04-23 14:30 ` Georg Bauhaus 2011-04-23 15:04 ` Dmitry A. Kazakov 2011-04-23 16:16 ` Piotr Trojanek 1 sibling, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2011-04-23 14:30 UTC (permalink / raw) On 4/23/11 2:23 PM, Dmitry A. Kazakov wrote: > On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote: > >> The question is what is your focus in a robotics research? If it is a RT control, >> than I see no point in not using Ada. If you are interested in AI, then Lisp is >> probably the way to go. > > I always did AI in Ada and see no point in using Lisp for that. There is a > common opinion that Lisp and Prolog are good for AI, which is as ungrounded > as the opinion that C is good for drivers. I think that Ada is especially > good for AI because AI is quite nasty when it comes to testing. Often you > cannot figure out whether the problem is due to a bug or a logical error. > Ada sufficiently reduces the bug rate. That helps much. Would the work have been just a little easier if there was a plugable standard garbage collector? ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 14:30 ` Georg Bauhaus @ 2011-04-23 15:04 ` Dmitry A. Kazakov 0 siblings, 0 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 15:04 UTC (permalink / raw) On Sat, 23 Apr 2011 16:30:42 +0200, Georg Bauhaus wrote: > On 4/23/11 2:23 PM, Dmitry A. Kazakov wrote: >> On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote: >> >>> The question is what is your focus in a robotics research? If it is a RT control, >>> than I see no point in not using Ada. If you are interested in AI, then Lisp is >>> probably the way to go. >> >> I always did AI in Ada and see no point in using Lisp for that. There is a >> common opinion that Lisp and Prolog are good for AI, which is as ungrounded >> as the opinion that C is good for drivers. I think that Ada is especially >> good for AI because AI is quite nasty when it comes to testing. Often you >> cannot figure out whether the problem is due to a bug or a logical error. >> Ada sufficiently reduces the bug rate. That helps much. > > Would the work have been just a little easier if there > was a plugable standard garbage collector? No, because I doubt that a standard collector would work with the heuristics I used, e.g. for factorization of decision trees, pruning, cloning upon modification etc. GC does not help in establishing various "uses", "depends" relationships, like strong, weak, read-only, weakly-ordered references etc. Which is the whole work. These relationships cannot be derived from the program, they must be programmed. Since you have to do this anyway, collection becomes a negligible problem. I don't remember if I even had a memory leak. I am very suspicious about usefulness of standard GC in general. I think that Ada represents a good example of why GC is not needed. If Ada supported unconstrained components in a less boring form, I bet that the issue of GC support could be closed. I also think that semantically the idea of magically working GC contradicts to higher level abstractions. It can work only in some strata, not too high, not too low. Hence GC is bad for design. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-23 12:23 ` Dmitry A. Kazakov 2011-04-23 14:30 ` Georg Bauhaus @ 2011-04-23 16:16 ` Piotr Trojanek 1 sibling, 0 replies; 168+ messages in thread From: Piotr Trojanek @ 2011-04-23 16:16 UTC (permalink / raw) On Apr 23, 2:23 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote: > > The question is what is your focus in a robotics research? If it is a RT control, > > than I see no point in not using Ada. If you are interested in AI, then Lisp is > > probably the way to go. > > I always did AI in Ada and see no point in using Lisp for that. There is a > common opinion that Lisp and Prolog are good for AI, which is as ungrounded > as the opinion that C is good for drivers. I think that Ada is especially > good for AI because AI is quite nasty when it comes to testing. Often you > cannot figure out whether the problem is due to a bug or a logical error. > Ada sufficiently reduces the bug rate. That helps much. I did not mean, that it is not possible to do an AI in Ada. And of course you will benefit from all the strong points of Ada, when it comes to AI. This was just an example. My point is, that you should take a tool, which allows you to focus on your task at hand. In other words - you can also do a multi-threading in Lisp, right? But when it comes to the real-time programming it is not just a matter of garbage collector, that we will do the job in Ada. -- Piotr ^ permalink raw reply [flat|nested] 168+ messages in thread
* C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) 2011-04-23 11:50 ` Piotr Trojanek 2011-04-23 12:23 ` Dmitry A. Kazakov @ 2011-04-28 12:55 ` Alex R. Mosteo 2011-04-28 16:34 ` C++/cmake project, injecting Ada Ludovic Brenta 2011-05-28 17:33 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Dirk Heinrichs 1 sibling, 2 replies; 168+ messages in thread From: Alex R. Mosteo @ 2011-04-28 12:55 UTC (permalink / raw) As I was writing this reply, I realized that focusing in a particular case at hand may provide better food for though and more precise solutions. So I have renamed the thread accordingly. Now, the scenario is like this: A fairly conventional open source project for doing some high-level simulations. C++ based, using cmake for building. Developers using an assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3 versions). Eventually, MacOSX could enter the fray. Remember, this is loosely cooperative research, nobody mandates the devel platform to a particularly tight version. The project uses several libraries: boost, YARP, opencv, etc, which are located by cmake. Somehow all this compiles in such varied environments. Now, let's suppose the contributions are fairly self-contained (e.g., providing a particular class instance for an abstract base class). I know how to interface Ada and C/C++, don't mind to write glue code as needed, etc. The challenge: throwing Ada into this mix without disrupting everyone's workflow to an unreasonable level. The obstacles that I see, and for which your ideas are most welcome: 1) Compiler. Debian/Ubuntu could be easy (Debian in particular): the Ada compiler is packaged and uses the system gcc. No idea about Fedora. The AdaCore GPL package brings in its own gcc/g++ versions, which have to be used to compile the C/C++ parts. Thus, it forces people to throw the stock system compiler in favor of the one I need. Not nice in my book. No workaround that I can see. Perhaps the .cgpr file offers a way? My early conclusion: use stock Ada compilers, doable with Debian, no-go in Mac? 2) Build framework: I read somewhere that gprbuild should be used instead. Obviously, I don't like being the newcomer and having to propose that cmake has to go in favor of an unknown tool. Also, not sure of how gprbuild would deal with C/c++ libraries that can be packaged differently depending on OS versions. Alternatively, I confess not having any idea how a few Ada sources could be integrated with cmake. Would very much like to know if this is doable. I read quite some time ago about difficulties (that were solved IIRC) faced by the PlPlot project with their Ada binding; I failed when I tried to replicate that, mostly because my very limited knowledge of cmake. Anyone here has done it? 3) Ada compiler bugs: given my personal experience, better to stick to "conservative" Ada coding. No synchronized interfaces or other fancy novelties. A minor sacrifice. 4) ??? Basically, I'd like to blend in some Ada as painlessly as possible, if possible at all... Piotr Trojanek wrote: > On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> > wrote: >> Hello, >> >> I'm a big supporter of Ada, but I'm the only person that I know that uses >> it in my work environment (mobile robotics research). Everyone is using >> either C, C++, python or java. >> >> I ceased looking into other languages because I am so comfortable with >> Ada. I fear I may have missed some interesting boat. >> >> Do you know of other languages worth to look at (i.e. that will make an >> Ada programmer somewhat happy), that are at least as "popular" as Ada, >> besides these ones mentioned above? > > Alex, I am in a kind of similar position - in my robotics team all the > people > are using C++. I have simply decided not to bother and do my work with > Ada. < This was written before the scenario above: > I do that when it's my own code, that most likely nobody will touch. But it feels rude to impose an unknown (for the rest) language on a group of people which are not my subordinates (some might say that I would be doing them a favor ;-)). It's also a hard decision if you'd like to attract contributors in an open source project (which is the case for the one that I'm just starting). I guess a good chance is to keep using Ada in "boundary" things that may make people exposed to Ada without having to "fight" it head-on. The interested ones can go further. > > There are a lot of programming languages around and people use ALL of > them > to program their robots. Please take a look at the list of languages, > which > you can use for Lego NXT programming (Ada is also there!): > http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Programming > > The question is what is your focus in a robotics research? If it is a > RT control, > than I see no point in not using Ada. If you are interested in AI, > then Lisp is > probably the way to go. It has been shown, that virtually any language > can be > used for a robotic research. I think you should simply pick a one, > which allows > you to focus on what is your primary goal. I'm actually into planning/task allocation (although I have to use robot hardware, but using non-RT libraries like player, ROS or YARP). Also lots of networking. So in my case Ada is a better choice than Lisp, I think. Alex. > > -- > Piotr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C++/cmake project, injecting Ada... 2011-04-28 12:55 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Alex R. Mosteo @ 2011-04-28 16:34 ` Ludovic Brenta 2011-04-29 8:17 ` Alex R. Mosteo 2011-05-28 17:33 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Dirk Heinrichs 1 sibling, 1 reply; 168+ messages in thread From: Ludovic Brenta @ 2011-04-28 16:34 UTC (permalink / raw) "Alex R. Mosteo" <alejandro@mosteo.invalid> writes: > As I was writing this reply, I realized that focusing in a particular > case at hand may provide better food for though and more precise > solutions. So I have renamed the thread accordingly. Now, the scenario > is like this: > > A fairly conventional open source project for doing some high-level > simulations. C++ based, using cmake for building. Developers using an > assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3 > versions). Eventually, MacOSX could enter the fray. Remember, this is > loosely cooperative research, nobody mandates the devel platform to a > particularly tight version. > > The project uses several libraries: boost, YARP, opencv, etc, which > are located by cmake. Somehow all this compiles in such varied > environments. > > Now, let's suppose the contributions are fairly self-contained (e.g., > providing a particular class instance for an abstract base class). I > know how to interface Ada and C/C++, don't mind to write glue code as > needed, etc. > > The challenge: throwing Ada into this mix without disrupting > everyone's workflow to an unreasonable level. The obstacles that I > see, and for which your ideas are most welcome: My first reaction is: don't do it. The chances of failure are very high, if only because of the diversity of platforms and the absence of a "stock" Ada compiler on each. The integration between Ada and cmake is another potential hurdle. Any failure will be promptly blamed on "your non-standard language and tools" even though cmake is just as "non-standard" as gprbuild; you'll end up being the only person in charge of debugging everyone else's build problems. It should be possible, however, to create separate add-ons in Ada. Compile these add-ons independently from the main project, using gnatmake or gprmake; do not require any developer not interested in your add-ons to change anything to their toolchain. The interfacing between the add-ons and the main project is the crux of the matter; if you could do it via some sort of interprocess communications, you would be able to isolate your add-ons from the main project very well. Otherwise, provide a shared library that the main project can dlopen() and call (use pragma Export to expose the API to the shared library). A last resort perhaps: fork the open source project; do anything you like in Ada, replace cmake with gprbuild or whatever. Merge from the open source project from time to time. Care only about your platform; if anyone is interested in building on another, provide assistance as needed. Publish your sources in a separate branch in their version control system if you can (and if the VCS supports merges well, i.e. it is not CVS or subversion...) or in a monotone database if you must. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C++/cmake project, injecting Ada... 2011-04-28 16:34 ` C++/cmake project, injecting Ada Ludovic Brenta @ 2011-04-29 8:17 ` Alex R. Mosteo 2011-04-29 12:45 ` stefan-lucks 2015-07-02 10:44 ` Alejandro R. Mosteo 0 siblings, 2 replies; 168+ messages in thread From: Alex R. Mosteo @ 2011-04-29 8:17 UTC (permalink / raw) Ludovic Brenta wrote: > "Alex R. Mosteo" <alejandro@mosteo.invalid> writes: >> As I was writing this reply, I realized that focusing in a particular >> case at hand may provide better food for though and more precise >> solutions. So I have renamed the thread accordingly. Now, the scenario >> is like this: >> >> A fairly conventional open source project for doing some high-level >> simulations. C++ based, using cmake for building. Developers using an >> assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3 >> versions). Eventually, MacOSX could enter the fray. Remember, this is >> loosely cooperative research, nobody mandates the devel platform to a >> particularly tight version. >> >> The project uses several libraries: boost, YARP, opencv, etc, which >> are located by cmake. Somehow all this compiles in such varied >> environments. >> >> Now, let's suppose the contributions are fairly self-contained (e.g., >> providing a particular class instance for an abstract base class). I >> know how to interface Ada and C/C++, don't mind to write glue code as >> needed, etc. >> >> The challenge: throwing Ada into this mix without disrupting >> everyone's workflow to an unreasonable level. The obstacles that I >> see, and for which your ideas are most welcome: > > My first reaction is: don't do it. The chances of failure are very > high, if only because of the diversity of platforms and the absence of a > "stock" Ada compiler on each. The integration between Ada and cmake is > another potential hurdle. Any failure will be promptly blamed on "your > non-standard language and tools" even though cmake is just as > "non-standard" as gprbuild; you'll end up being the only person in > charge of debugging everyone else's build problems. I see my fears are then reasonable, because that's how I feel too. It's not bad enough that few people know/use Ada, one is further excluded by things like this. > It should be possible, however, to create separate add-ons in Ada. > Compile these add-ons independently from the main project, using > gnatmake or gprmake; do not require any developer not interested in your > add-ons to change anything to their toolchain. The interfacing between > the add-ons and the main project is the crux of the matter; if you could > do it via some sort of interprocess communications, you would be able to > isolate your add-ons from the main project very well. Otherwise, > provide a shared library that the main project can dlopen() and call > (use pragma Export to expose the API to the shared library). This is an interesting possibility, and in fact IPC in this particular lab is many times done via YARP (tell about killing flies with cannons), meaning, if you don't know it, that processes are totally independent, communicating over sockets. So this is a possibility to keep in mind. Also the dlopen possibility is interesting, although a bit less attractive because dlopen shenaningans are not used right now (I suspect). Still worth to keep in mind, thanks. > A last resort perhaps: fork the open source project; do anything you > like in Ada, replace cmake with gprbuild or whatever. Merge from the > open source project from time to time. Care only about your platform; > if anyone is interested in building on another, provide assistance as > needed. Publish your sources in a separate branch in their version > control system if you can (and if the VCS supports merges well, i.e. it > is not CVS or subversion...) or in a monotone database if you must. Last resort indeed :) Although interesting from the POV of seeing how gprbuild would deal with a large complex cmake project. Perhaps worth it (once) only for that part of the experience. Thank for your opinions, much valued because I know you're deeply experienced into the Debian/open source community. I see that basically my understanding of the situation was on target :( Going again over it, I still think that perhaps exploring the cmake+Ada way is the more promising in terms of achieving something with relative ease? I see two venues here: 1) Just drop all advantages of gprbuild dependency management, and compile each Ada file to object code. Problems I see: what happens with gnatbind? 2) Somehow massage cmake into using a single call to gprbuild, and normally use it to compile the Ada part into a library. I guess this library can be easily linked with the rest of C/C++ compiled sources, since I have seen cmake projects which build many intermediate libraries. Since there's only one interaction between cmake and Ada (launching gprbuild), perhaps the problem of debugging everyone's else builds would be a reasonable burden; especially if the Ada parts are disabled by default and only compiled by people interested in them. Alex. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C++/cmake project, injecting Ada... 2011-04-29 8:17 ` Alex R. Mosteo @ 2011-04-29 12:45 ` stefan-lucks 2015-07-02 10:44 ` Alejandro R. Mosteo 1 sibling, 0 replies; 168+ messages in thread From: stefan-lucks @ 2011-04-29 12:45 UTC (permalink / raw) On Fri, 29 Apr 2011, Alex R. Mosteo wrote: > 2) Somehow massage cmake into using a single call to gprbuild, and normally > use it to compile the Ada part into a library. If your sub-project is strictly Ada only, then perhaps you could massage cmake into using a single call of gnatmake. Disadvantage: less flexibility than with gprbuild Advantage: you don't need to maintain any project-file -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C++/cmake project, injecting Ada... 2011-04-29 8:17 ` Alex R. Mosteo 2011-04-29 12:45 ` stefan-lucks @ 2015-07-02 10:44 ` Alejandro R. Mosteo 1 sibling, 0 replies; 168+ messages in thread From: Alejandro R. Mosteo @ 2015-07-02 10:44 UTC (permalink / raw) On Friday, April 29, 2011 at 10:17:18 AM UTC+2, Alex R. Mosteo wrote: > >> The challenge: throwing Ada into this mix without disrupting > >> everyone's workflow to an unreasonable level. > 2) Somehow massage cmake into using a single call to gprbuild, and normally > use it to compile the Ada part into a library. I guess this library can be > easily linked with the rest of C/C++ compiled sources, since I have seen > cmake projects which build many intermediate libraries. Since there's only > one interaction between cmake and Ada (launching gprbuild), perhaps the > problem of debugging everyone's else builds would be a reasonable burden; > especially if the Ada parts are disabled by default and only compiled by > people interested in them. Sorry for resurrecting this 4-year old thread, but yesterday I gave a new shot at this and I think things have changed for the better with CMake. To summarize, the challenge was to contribute Ada code to a C/C++ project using the CMake build environment and with minimal disruption for all parts involved. What I've found is that CMake 2.8 adds an "external project" build command that enables calling gprbuild with ease. If you're in a debian-based distro which packages gnat, the other contributors that are interested in compiling your Ada part just need to install a package. To me that qualifies as minimal disruption :) Advantages to each side: 1) The Ada contributor can keep using the wonderful Ada built-in dependency management. If he wants to share a library, an appropriately crafted gpr file will expose the code to the C/C++ side in the usual way. If the result is a mere executable things are even simpler. 2) The C/C++ side just keeps working as usual, enabling the Ada parts if needed. I've prepared a couple of CMake helper macros that give the basic idea and can be enhanced for more involved actions (like installing the Ada library, etc). It is here [1]. Basically, you issue an add_ada_library() and that's it for the CMake side. Incidentally, I saw another effort to integrate gnat and CMake, but it seems it is going the full CMake way: adding Ada support so source files are recognized and compiled individually and so on. I'm not sure how the binding stage is managed there, but for interested people here it is too [2]. [1] https://github.com/mosteo/ada4cmake [2] https://github.com/offa/cmake-ada ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) 2011-04-28 12:55 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Alex R. Mosteo 2011-04-28 16:34 ` C++/cmake project, injecting Ada Ludovic Brenta @ 2011-05-28 17:33 ` Dirk Heinrichs 1 sibling, 0 replies; 168+ messages in thread From: Dirk Heinrichs @ 2011-05-28 17:33 UTC (permalink / raw) Alex R. Mosteo wrote: > 2) Build framework: I read somewhere that gprbuild should be used instead. > Obviously, I don't like being the newcomer and having to propose that > cmake has to go in favor of an unknown tool. Also, not sure of how > gprbuild would deal with C/c++ libraries that can be packaged differently > depending on OS versions. Alternatively, I confess not having any idea how > a few Ada sources could be integrated with cmake. Would very much like to > know if this is doable. I use omake (from the Mojave project) to build my Ada stuff, so it is doable. Just read chapter 2 (The GNAT Compilation Model) of the GNAT User's Guide. This should tell you all you need to compile your Ada sources with any build tool you want. The reason for using omake? Well, it's not GNU make, thus it comes with dependency tracking, build command checksumming, built-in build cache, background execution with source file monitoring, etc. Bye... Dirk ^ permalink raw reply [flat|nested] 168+ messages in thread
* If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo ` (4 preceding siblings ...) 2011-04-23 11:50 ` Piotr Trojanek @ 2015-07-03 19:21 ` luvhed 2015-07-03 20:50 ` Paul Rubin 2015-07-04 8:19 ` Rod Kay 2015-07-08 18:11 ` jm.tarrasa 7 siblings, 1 reply; 168+ messages in thread From: luvhed @ 2015-07-03 19:21 UTC (permalink / raw) C/C++ with MIRSA rules enabled? At least you will get some of the checks that Ada performs for you. H. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-03 19:21 ` If not Ada, what else luvhed @ 2015-07-03 20:50 ` Paul Rubin 0 siblings, 0 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-03 20:50 UTC (permalink / raw) luvhed@gmail.com writes: > C/C++ with MIRSA rules enabled? At least you will get some of the > checks that Ada performs for you. You still would face way too many trip-ups and pitfalls. People who think they know C well enough to avoid those pitfalls should look at: http://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-discussion.html There is also the famous "C++ FQA" (frequently questioned answers). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo ` (5 preceding siblings ...) 2015-07-03 19:21 ` If not Ada, what else luvhed @ 2015-07-04 8:19 ` Rod Kay 2015-07-08 18:11 ` jm.tarrasa 7 siblings, 0 replies; 168+ messages in thread From: Rod Kay @ 2015-07-04 8:19 UTC (permalink / raw) ... gardening ? (In response to subject line.) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo ` (6 preceding siblings ...) 2015-07-04 8:19 ` Rod Kay @ 2015-07-08 18:11 ` jm.tarrasa 2015-07-08 20:33 ` Anh Vo 2015-07-08 22:15 ` David Botton 7 siblings, 2 replies; 168+ messages in thread From: jm.tarrasa @ 2015-07-08 18:11 UTC (permalink / raw) nim, at http://nim-lang.org/index.html There are things I don't like. Nevertheless, It's an interesting language. It looks that the author has experience in languages. And it looks that has an active and growing community. Hardtyped, generics with much more semantic information than Ada, concurrency, closures, iterators, named loops, positional or named parameters, lists, hash arrays, sets, array slices, overloaded operators, OOP, exptions tye except and try finally. The compiler (initially was written in Pascal) compiles to C and then to binary. As I said, there are things I don't like: * Indentation is meaningful, marks blocks, like python * Identifiers are case sensitive... only the first letter. !! astonishing * Arrays are declared in a weird way, base type looks like an index: array [1..20,int] translates to Ada array[1..20] of integer. !! weird. Nevertheless it's interesting and has interesting features. Not my language but interesting. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-08 18:11 ` jm.tarrasa @ 2015-07-08 20:33 ` Anh Vo 2015-07-09 6:36 ` jm.tarrasa 2015-07-08 22:15 ` David Botton 1 sibling, 1 reply; 168+ messages in thread From: Anh Vo @ 2015-07-08 20:33 UTC (permalink / raw) On Wednesday, July 8, 2015 at 11:11:13 AM UTC-7, jm.ta...@gmail.com wrote: > nim, at http://nim-lang.org/index.html > array [1..20,int] translates to Ada array[1..20] of integer. !! weird. Ada does not this syntax. Indeed, you hands will be slapped if you attempt to compile it. Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-08 20:33 ` Anh Vo @ 2015-07-09 6:36 ` jm.tarrasa 0 siblings, 0 replies; 168+ messages in thread From: jm.tarrasa @ 2015-07-09 6:36 UTC (permalink / raw) > Ada does not this syntax. Indeed, you hands will be slapped if you attempt to compile it. > Uuups Sorry. :-P Yeah, that's Pascal, that's what I'm doing now. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-08 18:11 ` jm.tarrasa 2015-07-08 20:33 ` Anh Vo @ 2015-07-08 22:15 ` David Botton 2015-07-09 7:28 ` jm.tarrasa 1 sibling, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-08 22:15 UTC (permalink / raw) > nim The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed), not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects, if you are going to use a Python like language may as well just use python. If compiled Python needed use cython or Nuitka. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-08 22:15 ` David Botton @ 2015-07-09 7:28 ` jm.tarrasa 2015-07-09 9:54 ` G.B. ` (2 more replies) 0 siblings, 3 replies; 168+ messages in thread From: jm.tarrasa @ 2015-07-09 7:28 UTC (permalink / raw) El jueves, 9 de julio de 2015, 0:15:42 (UTC+2), David Botton escribió: > > nim > > The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed), That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled? >not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects, Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An . > if you are going to use a Python like language may as well just use python. If compiled Python needed use cython or Nuitka. Well, Nim is not a Python like language at all. It uses indentation to mark blocks instead of curly brackets or begin..end. Anyway, I don't see my self programming Nim, I'm not supporting it. I was just answering the post about other languages, but leaving the mainstream. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 7:28 ` jm.tarrasa @ 2015-07-09 9:54 ` G.B. 2015-07-09 12:57 ` Dennis Lee Bieber 2015-07-09 18:25 ` David Botton 2 siblings, 0 replies; 168+ messages in thread From: G.B. @ 2015-07-09 9:54 UTC (permalink / raw) On 09.07.15 09:28, jm.tarrasa@gmail.com wrote: > El jueves, 9 de julio de 2015, 0:15:42 (UTC+2), David Botton escribió: >>> nim >> >> The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed), > > That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled? > >> not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects, > > Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An . Is Nim one of those languages that its authors develop because they like developing programming languages, and be it based mainly on personal acquaintance with some language theory and a few translation techniques? If feels like it is the 1970s again, people succeeding in finding someone who pays them for writing yet another separate programming language. ("Ah! Goal getters...!") Industry not co-ordinating its own needs, just waiting to be presented with something that has "won"... After skimming the Nim docs, the concepts I see make me think: What's unique about it? Something that would let industry switch from competitive offerings of "the same"? ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 7:28 ` jm.tarrasa 2015-07-09 9:54 ` G.B. @ 2015-07-09 12:57 ` Dennis Lee Bieber 2015-07-09 18:25 ` David Botton 2 siblings, 0 replies; 168+ messages in thread From: Dennis Lee Bieber @ 2015-07-09 12:57 UTC (permalink / raw) On Thu, 9 Jul 2015 00:28:53 -0700 (PDT), jm.tarrasa@gmail.com declaimed the following: >Well, Nim is not a Python like language at all. It uses indentation to mark blocks instead of curly brackets or begin..end. > Pardon? Looking at the nim main page, the code samples shown are practically python with a few added keywords ("let" -- shades of original K&K BASIC, although nim is using that to define a write-once name [claims to define an immutable object, but if the name itself can't be reused?], named "block", etc.) -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 7:28 ` jm.tarrasa 2015-07-09 9:54 ` G.B. 2015-07-09 12:57 ` Dennis Lee Bieber @ 2015-07-09 18:25 ` David Botton 2015-07-09 21:15 ` Bob Duff 2 siblings, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-09 18:25 UTC (permalink / raw) > That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled? D is lacking - #1 no way to switch braces to begin and end :), the ability to create new ranged types no via OO. It does have a concept of types above C and C++ but no where near Ada's. As an extension of that it can only create 0 indexed arrays, but you can use enumerations, so some support. There are other issues but mostly revolve around lacks in terms of defining types and as a direct result compile time checks related to those lacks. It's way ahead of C/C++, Java, etc. and there are ways to create types in OO but then all checks become dynamic. D is ahead - 3 true open source (no virused runtimes) implementations (dmd, lcd2, gdc), phobos (D's runtime) is incredibly rich, functional, parallel computing, concurrency, etc. Ada's annexes are primitive in comparison. Easier interfacing with C. Community support, resources, etc. etc. dub - package management and build system, etc. built in unit testing, better syntax for pre and post conditions, and tons more. A few tweaks to D's type system and not sure Ada would have anything all that unique or beneficial at all. > Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An . Goes to show you both languages no more than a fad. The author of Rust went to nim because of C output since he is working on an OS. BTW, D has already successfully been used for creating OSes, etc. > Well, Nim is not a Python like language at all. Oh my, it was created to be a compilable Python from the start..... David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 18:25 ` David Botton @ 2015-07-09 21:15 ` Bob Duff 2015-07-09 22:23 ` David Botton 0 siblings, 1 reply; 168+ messages in thread From: Bob Duff @ 2015-07-09 21:15 UTC (permalink / raw) David Botton <david@botton.com> writes: > D is lacking - #1 no way to switch braces to begin and end :),... But (and I'm sure you know this), Ada doesn't merely use begin and end. It uses (e.g.) if/else/end if and the like. I don't find Pascal's begin/end syntax any better than C's curly braces; begin/end contains the same information as {}, is more verbose for no reason, and suffers from the dangling else problem, just like C. "if/else/end if" is superior to both -- you can tell what "end if" is the "end" of. And no dangling else. > D is ahead ... Garbage collection (if I recall correctly). - Bob ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 21:15 ` Bob Duff @ 2015-07-09 22:23 ` David Botton 2015-07-09 22:39 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-09 22:23 UTC (permalink / raw) > But (and I'm sure you know this), Ada doesn't merely use begin and end. > It uses (e.g.) if/else/end if and the like. Of course, just a preference and half joking. I think the main reason I haven't jumped in to D is the lack of Ada's type system. I also really like having spec and body. > D is ahead ... > > Garbage collection (if I recall correctly). Yes, you can also control in code what is or is not under the GC's eye. There are numerous other features I like, such as being able to mark safety levels of code, of course the normalized use of a class for defining objects, etc. D (or more specifically D2) was a smart move, take the best of the past and remodel with out concern for breaking with that past. Unfortunately they didn't fully get the importance of static typing to the point of being able to set ranges, etc. I'm actually surprised considering the great work done on the rest of D, I consider it a major oversight and it seems there is little interest to fix it. It would be nice for Ada to do a rethink. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 22:23 ` David Botton @ 2015-07-09 22:39 ` Paul Rubin 2015-07-10 0:20 ` David Botton 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-09 22:39 UTC (permalink / raw) David Botton <david@botton.com> writes: > It would be nice for Ada to do a rethink. Ada 2012 seems like a move in the right direction. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-09 22:39 ` Paul Rubin @ 2015-07-10 0:20 ` David Botton 2015-07-10 4:26 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-10 0:20 UTC (permalink / raw) > Ada 2012 seems like a move in the right direction. You could say that about every version even the first. It is unlikely that there will be a rethink from the top down (not enough financial incentive since no one pursuing new markets), but perhaps if there is ever a new front end effort it can be done from the bottom up. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 0:20 ` David Botton @ 2015-07-10 4:26 ` Paul Rubin 2015-07-10 15:01 ` David Botton 2015-07-11 11:10 ` If not Ada, what else Pascal Obry 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-10 4:26 UTC (permalink / raw) David Botton <david@botton.com> writes: > You could say that about every version even the first. Well, the big win of Ada 2012 is SPARK integration, it seems to me. There's nothing like that for D. I looked at the Wikipedia page about D and didn't see much to recommend it over Ada, except garbage collection which puts it in a different class of languages. For desktop and server applications I like lightweight concurrency, garbage collection, functional idioms, and maybe even dynamic types, but for low level systems code Ada is still looking good to me. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 4:26 ` Paul Rubin @ 2015-07-10 15:01 ` David Botton 2015-07-10 16:07 ` David Botton 2015-07-10 18:22 ` Paul Rubin 2015-07-11 11:10 ` If not Ada, what else Pascal Obry 1 sibling, 2 replies; 168+ messages in thread From: David Botton @ 2015-07-10 15:01 UTC (permalink / raw) > Well, the big win of Ada 2012 is SPARK integration, it seems to me. Adding Pre/Post, etc. is more like Eiffel integration. Not that big a deal to be officially part of the language itself, but not unwelcome. If you manage your types well in Ada you need far less of these "extras". More emphasis on Ada's real strength in typing is a smarter investment in the language and leaving proving tools outside the language. I certainly hope things don't go further than they already have in this direction. From a marketing perspective AdaCore made a mistake reversing the original direction of SPARK to distance itself as far from Ada as possible. The Ada name is burnt in the US and it was good marketing to create distance. They should have just changed their name to CodeCore and marketed their multiple language products all focused on "correct code". > There's nothing like that for D. Actually there is and has been there for some time. Pre/Post, invariants, etc. and with a syntax that is far cleaner. > I looked at the Wikipedia page about D Better to look at dlang.org and if you are comfortable directly with the language specs and as per another post to look at Phobos (the runt time) which puts D way ahead in most areas. (Of course D is also truly open source no runtime license games) The feature of Ada (and is a big one) that places Ada ahead of D (and other languages) is the type system of Ada that has been in place since Ada 83. Since then Ada has suffered from feature creep issues due to reluctance to throw away the dross and accept more incompatibilities between versions. > and didn't see much to recommend it over Ada, except garbage collection The funny thing is that I don't consider that a big deal at all. I enjoy Ada in particular because of the ways I get around needing to have a GC because of it (interestingly enough those features like nested procedures are part of D too). > which puts it in a different class of languages. That is one of the nice things about D, that it doesn't put it in a different class of languages given the ability to avoid use of the GC if you choose and when you choose. BTW, Ada has always considered a D like implementation of a GC, just that only 3 implementations of Ada, that I know of, ever did it. Does that put Ada in a different category now too? In fact D and Ada are _exactly_ in the same space, designed to be systems languages and general purpose. (Actually there are a number of device drivers written in D at least 2 OSes, etc.) Ada unlike SPARK is not a niche language, just being forced in to one. My point in bringing up D, a language that is almost there, is that the extreme niche thinking that is towing Ada around has harmed Ada acceptance and is creating road blocks for Ada's long term future. If D tweaked its type system a bit not sure Ada would make much sense for anyone other than long term old projects. > For desktop and server > applications I like lightweight concurrency, garbage collection, > functional idioms, and maybe even dynamic types, but for low level > systems code Ada is still looking good to me. I am not advocating D, nor asking the D people to consider improving their type system, I'm advocating community efforts to improve Ada's general purpose use and avoid it further sinking in to extreme niche use that will make Ada in to SPARK or another niche language of little use outside that niche. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 15:01 ` David Botton @ 2015-07-10 16:07 ` David Botton 2015-07-10 17:39 ` Bob Duff 2015-07-10 18:22 ` Paul Rubin 1 sibling, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-10 16:07 UTC (permalink / raw) To be fair, subtype predicates (and any work in the direction of tighter type contracts) are a clear step in the direction I was referring to as real Ada worthy additions. I have an agenda of only three things in connection to Ada 1) Stopping Ada from being closed off to general purpose use by those that want it to become a completely niche language 2) To bolster and advocate use and community support of non-GPL virused runtime versions of GNAT to offset (as best as possible) the damage caused by license games from small minded thinking 3) Encourage people in AdaCore's niche market to hire AdaCore for their top notch support services. (There is no conflict here, good engineers often make poor businessmen.) My reason for the agenda is simple, I enjoy using Ada and appreciate its benefits to facilitate correct and readable code in most project scenarios and wish I could be freely advocating its use and pushing it more, but hard to convince some one to get in to bed with GPL runtimes on the only compiler around without "IP" and license scares being tossed at it to discourage use. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 16:07 ` David Botton @ 2015-07-10 17:39 ` Bob Duff 0 siblings, 0 replies; 168+ messages in thread From: Bob Duff @ 2015-07-10 17:39 UTC (permalink / raw) David Botton <david@botton.com> writes: > To be fair, subtype predicates (and any work in the direction of tighter type > contracts) are a clear step in the direction I was referring to as real Ada > worthy additions. Subtype predicates are my favorite feature added in Ada 2012. I did much of the design work on them. I'd prefer they be called "invariants", though -- but that's a different feature. I did not agree with the split into Static_Predicate and Dynamic_Predicate. (And GNAT has Predicate as an implementation defined feature -- that's what I use in my code.) - Bob ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 15:01 ` David Botton 2015-07-10 16:07 ` David Botton @ 2015-07-10 18:22 ` Paul Rubin 2015-07-10 19:10 ` David Botton 2015-07-27 9:09 ` Assertions in SPARK (Was: If not Ada, what else...) Jacob Sparre Andersen 1 sibling, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-10 18:22 UTC (permalink / raw) David Botton <david@botton.com> writes: >> Well, the big win of Ada 2012 is SPARK integration, it seems to me. > Adding Pre/Post, etc. is more like Eiffel integration. Not that big a > deal to be officially part of the language itself, but not unwelcome. The old SPARK overloaded Ada's comment syntax, which has always felt crufty to me. Similar things happen in other languages and I've never been enamored of it. E.g. Doxygen, Haddock, etc. It's ok if an experimental tool like Liquid Haskell works by munching code comments, but I'd want it to become part of the official language when it grows up. > If you manage your types well in Ada you need far less of these > "extras". More emphasis on Ada's real strength in typing is a smarter > investment in the language and leaving proving tools outside the > language. I certainly hope things don't go further than they already > have in this direction. I remember being disappointed that (unless I missed something) there doesn't seem to be a way to put assertions in the middle of a function body and have Spark check them statically. Am I mistaken about that? I hope they add it. > From a marketing perspective AdaCore made a mistake reversing the > original direction of SPARK to distance itself as far from Ada as > possible. The Ada name is burnt in the US and it was good marketing to > create distance. They should have just changed their name to CodeCore > and marketed their multiple language products all focused on "correct > code". I think Ada is somewhat rehabilitated now, partly because of Ada 2012. I was aware of SPARK before that, when it was a separate expensive tool from a specialty vendor. Without it, Ada was just a clumsy and bureaucratic Pascal-like language. I got much more interested in using it when it became part of the GNAT collection. >> There's nothing like that for D. > Actually there is and has been there for some time. Pre/Post, > invariants, etc. and with a syntax that is far cleaner. Are there tools like SPARK for statically verifying the D annotations? > The feature of Ada (and is a big one) that places Ada ahead of D (and > other languages) is the type system of Ada that has been in place > since Ada 83. I may be missing something here, but I don't see where Ada's type system is that much better than C++'s, and it's way behind Haskell's. Ranged types are useful but you can implement them (with runtime checks) in other languages. They're interesting in Ada 2012 mostly because of the possibility of checking them statically with Spark. Another big advantage of Ada is much more precisely defined semantics than C++'s. To quote another poster, the Ada community has put colossal effort into certifying compilers and solidifying the standard. I don't know how D fares in this comparison. > The funny thing is that I don't consider that a big deal at all. I > enjoy Ada in particular because of the ways I get around needing to > have a GC because of it There are generally ways to program without a GC, but if your application constraints allow you to use one, it can make your code simpler and more maintainable, as well as speeding development. Are you programming to solve puzzles or are you trying to get a task accomplished? If you like puzzles, try Forth ;-). > BTW, Ada has always considered a D like implementation of a GC, just > that only 3 implementations of Ada, that I know of, ever did it. Does > that put Ada in a different category now too? Ada with a GC would be interesting and in a different category but it would lose its suitability for constrained, realtime environments. At that point it's competing with Java (and Java's offspring like Scala). > In fact D and Ada are _exactly_ in the same space, designed to be > systems languages and general purpose. (Actually there are a number of > device drivers written in D at least 2 OSes, etc.) Ada unlike SPARK is > not a niche language, just being forced in to one. I guess in my world, any non-GC'd language is niche (it's used for either small embedded environments, high-assurance realtime, or maximizing performance like for numerics or big network servers). For the general purpose middle ground, current trends are toward GC'd languages that support functional-programming idioms, which Ada isn't so hot at. > I am not advocating D, nor asking the D people to consider improving > their type system, I'm advocating community efforts to improve Ada's > general purpose use and avoid it further sinking in to extreme niche > use that will make Ada in to SPARK or another niche language of little > use outside that niche. I think Ada is an attractive choice for lots of things that people (including me) are currently doing with C and C++, but I consider those to be niche languages today too (unlike 20 years ago). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 18:22 ` Paul Rubin @ 2015-07-10 19:10 ` David Botton 2015-07-10 19:43 ` Patrick Noffke 2015-07-11 2:31 ` Paul Rubin 2015-07-27 9:09 ` Assertions in SPARK (Was: If not Ada, what else...) Jacob Sparre Andersen 1 sibling, 2 replies; 168+ messages in thread From: David Botton @ 2015-07-10 19:10 UTC (permalink / raw) > I think Ada is somewhat rehabilitated now, partly because of Ada 2012. > I was aware of SPARK before that, when it was a separate expensive tool > from a specialty vendor. Without it, Ada was just a clumsy and > bureaucratic Pascal-like language. I got much more interested in using > it when it became part of the GNAT collection. So now an expensive vendor tool is still an expensive vendor tool and SPARK is thought to be an extension of a clumsy bureaucratic Pascal like language...... Sounds like things got worse. > There's nothing like that for D. Nope. Nor does Ada. SPARK does. > Are there tools like SPARK for statically verifying the D annotations? We are talking about Ada not SPARK. If you like SPARK and it fits your needs great. > I may be missing something here, but I don't see where Ada's type system > is that much better than C++'s, So in C++ you can create new incompatible types with various ranges, use them for array indexes, true enums? > and it's way behind Haskell's. Different, but also something to investigate for Ada. > Ranged > types are useful but you can implement them (with runtime checks) in > other languages. That is what you don't understand, Ada is about compile time checks and that comes with contacts. Contracts on the types, contracts on the interfaces. > They're interesting in Ada 2012 mostly because of the > possibility of checking them statically with Spark. And why mostly of little interest to me. > Another big advantage of Ada is much more precisely defined semantics > than C++'s. To quote another poster, the Ada community has put colossal > effort into certifying compilers and solidifying the standard. Well, once upon a time Ada compilers were certified. I don't believe AdaCore does that anymore. In the end of the day they are the only vendor and so they are the standard.... > I don't > know how D fares in this comparison. Actually I'd say today D and Ada are again in the same boat. > There are generally ways to program without a GC, but if your > application constraints allow you to use one, it can make your code > simpler and more maintainable, as well as speeding development. And if you use Ada long enough you learn to use the Stack most of the time to accomplish the same thing and you don't get sloppy which tends to happen to GC dependent programmers. > Are you > programming to solve puzzles or are you trying to get a task > accomplished? If you like puzzles, try Forth ;-). If you know your tools you use them, Ada is an excellent tool that helps mold your code as you go in to solving problems in reusable and reliable ways. It is why I use Ada for "hacking" I've actually written software in Forth. It had its place in the days of tight memory constraints. > Ada with a GC would be interesting and in a different category but it > would lose its suitability for constrained, realtime environments. At > that point it's competing with Java (and Java's offspring like Scala) Ada does have a GC in some implementations as I pointed out. You are having trouble separating language from runtime environment. A GC in Ada or D is something you can choose to use. BTW, I've never had the need but there are ways to use a GC even the current GNAT's on most platforms. A GC doesn't change the language unless the language requires its use. Neither Ada or D does so. > I guess in my world, any non-GC'd language is niche (it's used for > either small embedded environments, high-assurance realtime, or > maximizing performance like for numerics or big network servers). For > the general purpose middle ground, current trends are toward GC'd > languages that support functional-programming idioms, which Ada isn't so > hot at. You can use D in that environment, although Ada is better at it. Repl clauses, etc. are also pluses. > I think Ada is an attractive choice for lots of things that people > (including me) are currently doing with C and C++, but I consider those > to be niche languages today too (unlike 20 years ago). No still general purpose. You need to look at the language itself to make that determination not just how it is being used currently. C and C++ are still heavily used in general use cases, from embedded to UI and Game Dev, etc. If anything C#, Python, Java are more niche, just their niche is where the vast majority of programs and programmers are. You would be a fool to use any of the three in anything critical (safety, time, etc.) Even Haskell, OCAML, etc. are fairly niche. All he scripting languages are niche. Ada, D, C, C++ are all geared for full range dev across the entire spectrum. Ada due to external issues in tool and compiler availability is the more limited currently, but almost as broad. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 19:10 ` David Botton @ 2015-07-10 19:43 ` Patrick Noffke 2015-07-11 10:46 ` Brian Drummond 2015-07-11 2:31 ` Paul Rubin 1 sibling, 1 reply; 168+ messages in thread From: Patrick Noffke @ 2015-07-10 19:43 UTC (permalink / raw) On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote: > > I may be missing something here, but I don't see where Ada's type system > > is that much better than C++'s, > > So in C++ you can create new incompatible types with various ranges, use them for array indexes, true enums? > In C++11 you have enum class which makes an enum its own type. You can still cast it to the class type, but you can't willy-nilly use it as an int as with the old-style enum. This generates an error: enum class Junk : int { One, Two, Three }; int a = Junk::One; // error: cannot convert to int Where this is allowed: int a = (int) Junk::One; But there's nothing to prevent you from using the old style. Even -Wold-style-cast doesn't generate a warning for this: enum Junk { One, Two, Three }; int a = One; (I guess because it's not technically a C cast -- enum really is just an int.) I'm curious -- how would you create incompatible types with different ranges in C++? AFAIK the language itself or the standard library don't provide that. Pat ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 19:43 ` Patrick Noffke @ 2015-07-11 10:46 ` Brian Drummond 2015-07-11 10:59 ` Björn Lundin 2015-07-13 14:02 ` Patrick Noffke 0 siblings, 2 replies; 168+ messages in thread From: Brian Drummond @ 2015-07-11 10:46 UTC (permalink / raw) On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote: > On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote: >> > I may be missing something here, but I don't see where Ada's type >> > system is that much better than C++'s, >> >> So in C++ you can create new incompatible types with various ranges, >> use them for array indexes, true enums? >> >> > In C++11 you have enum class which makes an enum its own type. You can > still cast it to the class type, but you can't willy-nilly use it as an > int as with the old-style enum. > > This generates an error: > > enum class Junk : int { > One, Two, Three > }; > > int a = Junk::One; // error: cannot convert to int > > Where this is allowed: > > int a = (int) Junk::One; And you can loop over the enum range (without explicitly naming its first and last tokens), and index arrays with them, etc, right? -- Brian ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 10:46 ` Brian Drummond @ 2015-07-11 10:59 ` Björn Lundin 2015-07-11 13:41 ` Georg Bauhaus 2015-07-13 14:02 ` Patrick Noffke 1 sibling, 1 reply; 168+ messages in thread From: Björn Lundin @ 2015-07-11 10:59 UTC (permalink / raw) On 2015-07-11 12:46, Brian Drummond wrote: > On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote: > >> On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote: >>>> I may be missing something here, but I don't see where Ada's type >>>> system is that much better than C++'s, > And you can loop over the enum range (without explicitly naming its first > and last tokens), and index arrays with them, etc, right? > And also use them is case/switch statements where missing values generates compiler errors ? as in procedure junk1 is type Junk_Type is (One, Two, Three); Junk : Junk_Type := Junk_Type'Last; begin case Junk is when One => null; when Two => null; end case; end Junk1; gcc -c -x ada junk1.ada junk1.ada:10:03: missing case value: "three" gnatmake: "junk1.ada" compilation error -- Björn ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 10:59 ` Björn Lundin @ 2015-07-11 13:41 ` Georg Bauhaus 2015-07-11 14:11 ` Björn Lundin 0 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-11 13:41 UTC (permalink / raw) On 11.07.15 12:59, Björn Lundin wrote: > On 2015-07-11 12:46, Brian Drummond wrote: >> On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote: >> >>> On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote: >>>>> I may be missing something here, but I don't see where Ada's type >>>>> system is that much better than C++'s, > >> And you can loop over the enum range (without explicitly naming its first >> and last tokens), and index arrays with them, etc, right? >> > > And also use them is case/switch statements > where missing values generates compiler errors ? Yes. <tongue-in-cheeck>Albeit, without standards bureaucracy!</> int main() { enum junk_t { One, Two, Three }; enum junk_t junk; switch (junk) { case One: break; case Two: break; } return 0; } clang -Werror main.m main.m:6:11: error: enumeration value 'Three' not handled in switch [-Werror,-Wswitch] switch (junk) { ^ 1 error generated. The others have learned from our No-No language! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 13:41 ` Georg Bauhaus @ 2015-07-11 14:11 ` Björn Lundin 0 siblings, 0 replies; 168+ messages in thread From: Björn Lundin @ 2015-07-11 14:11 UTC (permalink / raw) On 2015-07-11 15:41, Georg Bauhaus wrote: > > Yes. <tongue-in-cheeck>Albeit, without standards bureaucracy!</> .. > clang -Werror main.m > main.m:6:11: error: enumeration value 'Three' not handled in switch > [-Werror,-Wswitch] > switch (junk) { > ^ > 1 error generated. > > The others have learned from our No-No language! So it seems. But does -Werror with clang mean 'turn warnings to errors'? if so, what if this switch is not used? Anyway, it is a fall in forward direction. -- Björn ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 10:46 ` Brian Drummond 2015-07-11 10:59 ` Björn Lundin @ 2015-07-13 14:02 ` Patrick Noffke 2015-07-13 14:16 ` David Botton 1 sibling, 1 reply; 168+ messages in thread From: Patrick Noffke @ 2015-07-13 14:02 UTC (permalink / raw) On Saturday, July 11, 2015 at 5:48:13 AM UTC-5, Brian Drummond wrote: > On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote: > > > On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote: > >> > I may be missing something here, but I don't see where Ada's type > >> > system is that much better than C++'s, > >> > >> So in C++ you can create new incompatible types with various ranges, > >> use them for array indexes, true enums? > >> > >> > > In C++11 you have enum class which makes an enum its own type. You can > > still cast it to the class type, but you can't willy-nilly use it as an > > int as with the old-style enum. > > > > This generates an error: > > > > enum class Junk : int { > > One, Two, Three > > }; > > > > int a = Junk::One; // error: cannot convert to int > > > > Where this is allowed: > > > > int a = (int) Junk::One; > > And you can loop over the enum range (without explicitly naming its first > and last tokens), and index arrays with them, etc, right? > Um, no. Adding enum class was a baby step in the right direction. I'm a bit surprised though that range-based for loops don't work over an enum class. Seems there's interest in doing so: http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes Pat ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-13 14:02 ` Patrick Noffke @ 2015-07-13 14:16 ` David Botton 2015-07-13 14:54 ` Maciej Sobczak 2015-07-16 20:19 ` Serge Robyns 0 siblings, 2 replies; 168+ messages in thread From: David Botton @ 2015-07-13 14:16 UTC (permalink / raw) > Um, no. Adding enum class was a baby step in the right direction. I'm a bit surprised though that range-based for loops don't work over an enum class. Seems there's interest in doing so: > http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish. While D is certainly not Ada it is for sure what C++ should be. In both cases C++ and D, neither "got it" in terms of the importance of types and how they improve the overall contracts in all software development and increase its robustness in ways the current cruches they add can not. There just is not imperative language outside Ada that has understood the types and compile type checks for types is the real magic for efficiently implemented robust software. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-13 14:16 ` David Botton @ 2015-07-13 14:54 ` Maciej Sobczak 2015-07-16 20:19 ` Serge Robyns 1 sibling, 0 replies; 168+ messages in thread From: Maciej Sobczak @ 2015-07-13 14:54 UTC (permalink / raw) > What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish. Becaue D is not different enough. For many programmers (me including), D is too similar to C++ to make the improvement credible. This is a typical problem with any new technology that claims to be "better" at the same time trying to remain as similar to the old stuff as possible. The small space for actual improvement that results from such compromises is too little to justify the effort. > While D is certainly not Ada it is for sure what C++ should be. There is a contradiction in this statement, since it both shows the goal and at the same time suggests that it should not be met. Considering the massive success that C++ achieved in its respective market niche, it is difficult to argue that C++ should be something else than it already is. And if you really need something else, just move to Ada. Half-assed solutions are only distractions. > In both cases C++ and D, neither "got it" in terms of the importance of types Considering the assumed constraint of backward compatibility with C, they got the importance of types very well. More complete support for OO and templates are strong features, making it difficult for Ada to compete in these areas. -- Maciej Sobczak * http://www.inspirel.com/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-13 14:16 ` David Botton 2015-07-13 14:54 ` Maciej Sobczak @ 2015-07-16 20:19 ` Serge Robyns 2015-07-17 1:50 ` David Botton 1 sibling, 1 reply; 168+ messages in thread From: Serge Robyns @ 2015-07-16 20:19 UTC (permalink / raw) On Monday, 13 July 2015 16:16:11 UTC+2, David Botton wrote: > > Um, no. Adding enum class was a baby step in the right direction. I'm a bit surprised though that range-based for loops don't work over an enum class. Seems there's interest in doing so: > > http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes > > > What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish. While D is certainly not Ada it is for sure what C++ should be. > > In both cases C++ and D, neither "got it" in terms of the importance of types and how they improve the overall contracts in all software development and increase its robustness in ways the current cruches they add can not. > > There just is not imperative language outside Ada that has understood the types and compile type checks for types is the real magic for efficiently implemented robust software. > > David Botton Dear David, I've been reading this thread with great attention, as I'm in the initial phase of a major project. My interest for Ada is as old my return from HP where I used to program there in a special version of Pascal that was used to write the MPE-XL OS. Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.) Now with this discussion regarding D and I even started looking at Go and I'm puzzled. I've read there that some people consider D dead. Moreover, I'm not sure I can use D on all the platform I'm aiming at. In a nutshell I need an environment that helps me writing code right from inception (the range type example is one of these things I like in Ada), supports reliable concurrent programming, can read XML (without needing DOM), interface to Oracle and other RDBMS, and compile native code for Linux, AIX, Solaris and others .... I'm not sure D fits the complete bill and believe Ada still exceeds. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-16 20:19 ` Serge Robyns @ 2015-07-17 1:50 ` David Botton 2015-07-17 17:07 ` Anh Vo ` (2 more replies) 0 siblings, 3 replies; 168+ messages in thread From: David Botton @ 2015-07-17 1:50 UTC (permalink / raw) > Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.) Agreed > Now with this discussion regarding D and I even started looking at Go and I'm puzzled. Go is Oberon with C syntax and some week concurrency features, not worthy of much time. Is also seriously broken for anything more than script size software. > I've read there that some people consider D dead. I was not advocating D, only pointing out the next best thing to Ada, but by wide margin. To be precise talking about D2, D is dead and was replaced by D2. > Moreover, I'm not sure I can use D on all the platform I'm aiming at. Then likely you can't use Ada on them either. D has 3 backend options, GCC, LLVM and its own. Ada only has GCC... In fact my complaint is that I can't use Ada on the most important mobile and desktop platforms because it is married to GCC. > In a nutshell I need an environment that helps me writing code right from inception (the range type example is one of these things I like in Ada), supports reliable concurrent programming, can read XML (without needing DOM), interface to Oracle and other RDBMS, and compile native code for Linux, AIX, Solaris and others .... > I'm not sure D fits the complete bill and believe Ada still exceeds. D actually does everything you listed just as well or better. Ada as a language is far stronger for sure (I am one of its biggest advocates), but Ada suffers from few bindings, foolish license games, much weaker standard runtime library, no package management system with automatic builds like dub (although Gnoga now has the start of one and will be in the next 1.2 release in the coming months), Ada has a much more limited set of targets, etc. I could probably go on, but I'm an Ada advocate and right now doing what I can to fix the holes in Ada from the shortsighted lack of almost all investment in real R&D for Ada's environment by the few vendors it has had/has, mostly because the niche market they cater(ed) to are mostly hardware oriented with little need for "environment". If you use Ada today it is mostly because of the language's strengths that were already in Ada 83 not because Ada (yet) offers a better or wider set of features to other languages and development environments (It simply does not, but could and should have especially given the age and amounts of money involved in the contracts of yesteryear). David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-17 1:50 ` David Botton @ 2015-07-17 17:07 ` Anh Vo 2015-07-17 21:28 ` Serge Robyns 2015-07-19 14:31 ` David Botton 2015-07-21 6:30 ` Gour [not found] ` <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com> 2 siblings, 2 replies; 168+ messages in thread From: Anh Vo @ 2015-07-17 17:07 UTC (permalink / raw) On Thursday, July 16, 2015 at 6:50:49 PM UTC-7, David Botton wrote: > > Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.) > > Agreed > > > Now with this discussion regarding D and I even started looking at Go and I'm puzzled. > > Go is Oberon with C syntax and some week concurrency features, not worthy of much time. Is also seriously broken for anything more than script size software. > > > I've read there that some people consider D dead. > > I was not advocating D, only pointing out the next best thing to Ada, but by wide margin. To be precise talking about D2, D is dead and was replaced by D2. > > > Moreover, I'm not sure I can use D on all the platform I'm aiming at. > > Then likely you can't use Ada on them either. D has 3 backend options, GCC, LLVM and its own. Ada only has GCC... In fact my complaint is that I can't use Ada on the most important mobile and desktop platforms because it is married to GCC. > I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying to GCC since GNAT is a tool, not a computer language. Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-17 17:07 ` Anh Vo @ 2015-07-17 21:28 ` Serge Robyns 2015-07-17 22:53 ` Anh Vo 2015-07-19 14:31 ` David Botton 1 sibling, 1 reply; 168+ messages in thread From: Serge Robyns @ 2015-07-17 21:28 UTC (permalink / raw) On Friday, 17 July 2015 19:07:30 UTC+2, Anh Vo wrote: > > I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying to GCC since GNAT is a tool, not a computer language. > What is a language without the tool to understand it. The tool becomes an obstacle if it restricts you on what you want to achieve. In my case, GNAT and GNATPRO could be the reason I'll stay with Ada from the "tool" perspective besides the language benefits. However, I do join David on some of his points with regards to the language backwards compatibility becoming a hurdle (and not only for Ada, but also for C++). I've also learned the painful way with the help of this group that Ada has failed at some places to be readable, such as a standalone tick mark (') and a few other particular idiosyncrasies. I must say this is one of my deepest disappointments. And this is why I've been reading this thread with great attention. I'll continue my prototype in Ada and re-evaluate my options before the code base has become to large to move. I could return to the 'C' family languages if this will be the best option. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-17 21:28 ` Serge Robyns @ 2015-07-17 22:53 ` Anh Vo 0 siblings, 0 replies; 168+ messages in thread From: Anh Vo @ 2015-07-17 22:53 UTC (permalink / raw) On Friday, July 17, 2015 at 2:29:00 PM UTC-7, Serge Robyns wrote: > On Friday, 17 July 2015 19:07:30 UTC+2, Anh Vo wrote: > > > > > I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying to GCC since GNAT is a tool, not a computer language. > > > > What is a language without the tool to understand it. >> Tool such as compilers used to implement among other things syntactic and semantic checks. Again, It has nothing to do with GCC specifically. Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-17 17:07 ` Anh Vo 2015-07-17 21:28 ` Serge Robyns @ 2015-07-19 14:31 ` David Botton 2015-07-19 16:20 ` Paul Rubin 1 sibling, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-19 14:31 UTC (permalink / raw) > I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying to GCC since GNAT is a tool, not a computer language. > > Anh Vo No, I meant Ada. GNAT = Ada since there is not likely to be another implementation of the language nor even an update of any compilers to the current or future standards. There is more than enough talent in this community to produce a new community front end (and I actually am working on one, but I am not the right guy at all and not sure I plan on implementing the Ada standard if I end up doing it alone fully, for sure will change toss "tagged" out the window). David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-19 14:31 ` David Botton @ 2015-07-19 16:20 ` Paul Rubin 2015-07-19 20:55 ` Jeffrey R. Carter 2015-07-19 22:38 ` David Botton 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-19 16:20 UTC (permalink / raw) David Botton <david@botton.com> writes: > No, I meant Ada. GNAT = Ada since there is not likely to be another > implementation of the language nor even an update of any compilers to > the current or future standards. Are you serious, is GNAT really the only implementation of Ada 2012? I see a huge list of Ada 95 implementations here: http://www.ada-auth.org/cpl/lists/CPLbase.html And I figured that the updates only stopped because (per J-P. Rosen's recent post) vendors aren't doing ACAA validations any more. I know some of those vendors are still selling product but I don't know that they've been updated for Ada 2012. I don't see what's so difficult about it if customers are asking for it--the changes are not that large. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-19 16:20 ` Paul Rubin @ 2015-07-19 20:55 ` Jeffrey R. Carter 2015-07-19 21:15 ` Paul Rubin 2015-07-19 22:38 ` David Botton 1 sibling, 1 reply; 168+ messages in thread From: Jeffrey R. Carter @ 2015-07-19 20:55 UTC (permalink / raw) On 07/19/2015 09:20 AM, Paul Rubin wrote: > > Are you serious, is GNAT really the only implementation of Ada 2012? Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have been no announcements here of any other implementations. If you want portability among compiler vendors, Ada 12 is not the way to go. > I see a huge list of Ada 95 implementations here: > > http://www.ada-auth.org/cpl/lists/CPLbase.html Not long after the publication of the 95 standard, all vendors had implementations. A similar amount of time after the publication of the 07 standard, about half of the vendors had implementations (and many who didn't still don't). Now, nearing 3 yrs after the publication of the 12 standard, only 1 vendor has an implementation. -- Jeff Carter "C's solution to this [variable-sized array parameters] has real problems, and people who are complaining about safety definitely have a point." Dennis Ritchie 25 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-19 20:55 ` Jeffrey R. Carter @ 2015-07-19 21:15 ` Paul Rubin 2015-07-20 16:08 ` Tero Koskinen 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-19 21:15 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have > been no announcements here of any other implementations. Thanks, that is interesting. How on earth did Ada 12 get through the standardization process if none of the other compiler vendors were on board? Usually those committees have representatives from all the involved companies, with everyone trying to get their feature in. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-19 21:15 ` Paul Rubin @ 2015-07-20 16:08 ` Tero Koskinen 2015-07-20 17:31 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Tero Koskinen @ 2015-07-20 16:08 UTC (permalink / raw) 20.7.2015, 0:15, Paul Rubin kirjoitti: > "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: >> Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have >> been no announcements here of any other implementations. > > Thanks, that is interesting. How on earth did Ada 12 get through the > standardization process if none of the other compiler vendors were on > board? Usually those committees have representatives from all the > involved companies, with everyone trying to get their feature in. > However, there are multiple Ada 2005 compilers. Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego) support Ada 2005, Janus/Ada supports one or two Ada 2005 features. Also, I think RRSoftware (Janus/Ada) got some of their features to Ada 2005&2012. (They just don't have enough manpower/time to implement all of Ada 2005/2012 as fast as others.) Yours, Tero ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-20 16:08 ` Tero Koskinen @ 2015-07-20 17:31 ` Paul Rubin 2015-07-21 1:16 ` Dennis Lee Bieber 2015-07-21 5:43 ` J-P. Rosen 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-20 17:31 UTC (permalink / raw) Tero Koskinen <tero.koskinen@iki.fi> writes: > However, there are multiple Ada 2005 compilers. > Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego) > support Ada 2005, Janus/Ada supports one or two Ada 2005 features. > Also, I think RRSoftware (Janus/Ada) got some of their features to Ada > 2005&2012. ... Thanks. I now wonder if Ada 2012 has gotten much uptake from the traditional big users. I would have thought so since it's a real improvement over older versions, but I understand how critical-systems users might be more technologically conservative than internet startups for example. Maybe they're all still using Ada 2005 or Ada 95 and plan to stay with it. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-20 17:31 ` Paul Rubin @ 2015-07-21 1:16 ` Dennis Lee Bieber 2015-07-21 3:09 ` Shark8 2015-07-21 5:43 ` J-P. Rosen 1 sibling, 1 reply; 168+ messages in thread From: Dennis Lee Bieber @ 2015-07-21 1:16 UTC (permalink / raw) On Mon, 20 Jul 2015 10:31:05 -0700, Paul Rubin <no.email@nospam.invalid> declaimed the following: >Tero Koskinen <tero.koskinen@iki.fi> writes: >> However, there are multiple Ada 2005 compilers. >> Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego) >> support Ada 2005, Janus/Ada supports one or two Ada 2005 features. >> Also, I think RRSoftware (Janus/Ada) got some of their features to Ada >> 2005&2012. ... > >Thanks. I now wonder if Ada 2012 has gotten much uptake from the >traditional big users. I would have thought so since it's a real >improvement over older versions, but I understand how critical-systems >users might be more technologically conservative than internet startups >for example. Maybe they're all still using Ada 2005 or Ada 95 and plan >to stay with it. Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on Windows boxes in order to run a cross-platform Ada-83 compiler (no longer in production, to my knowledge) to build the boot software for some aircraft flight systems. Do not expect that to be upgraded anytime soon -- bad enough it takes months for a sub-contractor to independently certify the boot software doesn't contain superfluous code, or unpredictable timings... Having to get a new build chain (OS, compiler, etc.) certified is not in the $$$. Heck -- we've had a study running just to certify a different toolchain where the only difference is WinXP vs Win7 -- when the toolchain doesn't even produce binaries for Intel architectures! IE: are the resultant binaries completely identical when the same source is built on each OS -- if there is ANY difference, it must be evaluated to be proven to have no effect. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 1:16 ` Dennis Lee Bieber @ 2015-07-21 3:09 ` Shark8 2015-07-21 12:46 ` Dennis Lee Bieber 0 siblings, 1 reply; 168+ messages in thread From: Shark8 @ 2015-07-21 3:09 UTC (permalink / raw) On Monday, July 20, 2015 at 7:16:56 PM UTC-6, Dennis Lee Bieber wrote: > > Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on > Windows boxes in order to run a cross-platform Ada-83 compiler (no longer > in production, to my knowledge) to build the boot software for some > aircraft flight systems. Hm, given that; are you excited about the project to port OpenVMS to x86_64? I heard from a friend that the Ada compiler (along w/ Fortran, C and C++) is going to be updated. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 3:09 ` Shark8 @ 2015-07-21 12:46 ` Dennis Lee Bieber 0 siblings, 0 replies; 168+ messages in thread From: Dennis Lee Bieber @ 2015-07-21 12:46 UTC (permalink / raw) On Mon, 20 Jul 2015 20:09:12 -0700 (PDT), Shark8 <onewingedshark@gmail.com> declaimed the following: >On Monday, July 20, 2015 at 7:16:56 PM UTC-6, Dennis Lee Bieber wrote: >> >> Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on >> Windows boxes in order to run a cross-platform Ada-83 compiler (no longer >> in production, to my knowledge) to build the boot software for some >> aircraft flight systems. > >Hm, given that; are you excited about the project to port OpenVMS to x86_64? I heard from a friend that the Ada compiler (along w/ Fortran, C and C++) is going to be updated. Well, it would put some meaningful dynamic process priorities on the hardware <G> I'm still have no idea how they handled the four-level hardware system of the VAX on two-level processors (user/super) even in emulation. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-20 17:31 ` Paul Rubin 2015-07-21 1:16 ` Dennis Lee Bieber @ 2015-07-21 5:43 ` J-P. Rosen 2015-07-21 12:47 ` Dennis Lee Bieber 1 sibling, 1 reply; 168+ messages in thread From: J-P. Rosen @ 2015-07-21 5:43 UTC (permalink / raw) Le 20/07/2015 19:31, Paul Rubin a écrit : > Thanks. I now wonder if Ada 2012 has gotten much uptake from the > traditional big users. I would have thought so since it's a real > improvement over older versions, but I understand how critical-systems > users might be more technologically conservative than internet startups > for example. Maybe they're all still using Ada 2005 or Ada 95 and plan > to stay with it. Airbus D&S (previously EADS) announced during the Ada-Europe conference in Madrid that the software for the Ariane 6 rocket would be developped in Ada 2012, with intensive use of contracts. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 5:43 ` J-P. Rosen @ 2015-07-21 12:47 ` Dennis Lee Bieber 2015-07-21 12:55 ` J-P. Rosen 0 siblings, 1 reply; 168+ messages in thread From: Dennis Lee Bieber @ 2015-07-21 12:47 UTC (permalink / raw) On Tue, 21 Jul 2015 07:43:11 +0200, "J-P. Rosen" <rosen@adalog.fr> declaimed the following: >Le 20/07/2015 19:31, Paul Rubin a écrit : >> Thanks. I now wonder if Ada 2012 has gotten much uptake from the >> traditional big users. I would have thought so since it's a real >> improvement over older versions, but I understand how critical-systems >> users might be more technologically conservative than internet startups >> for example. Maybe they're all still using Ada 2005 or Ada 95 and plan >> to stay with it. > >Airbus D&S (previously EADS) announced during the Ada-Europe conference >in Madrid that the software for the Ariane 6 rocket would be developped >in Ada 2012, with intensive use of contracts. Ah... wanting to avoid a repeat of the Ariane-5 fiasco? <G> -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 12:47 ` Dennis Lee Bieber @ 2015-07-21 12:55 ` J-P. Rosen 0 siblings, 0 replies; 168+ messages in thread From: J-P. Rosen @ 2015-07-21 12:55 UTC (permalink / raw) Le 21/07/2015 14:47, Dennis Lee Bieber a écrit : >> Airbus D&S (previously EADS) announced during the Ada-Europe conference >> >in Madrid that the software for the Ariane 6 rocket would be developped >> >in Ada 2012, with intensive use of contracts. > Ah... wanting to avoid a repeat of the Ariane-5 fiasco? <G> Fiasco? Ariane-5 has the highest rate of succesful flights of all rockets. Presumably you meant Ariane 501? Even though, 1) few (if any) rockets had a fully succesful maiden flight, and 2) the problem was fully a management issue, with a decision to skip appropriate testing due to political pressure. No language can help... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-19 16:20 ` Paul Rubin 2015-07-19 20:55 ` Jeffrey R. Carter @ 2015-07-19 22:38 ` David Botton 1 sibling, 0 replies; 168+ messages in thread From: David Botton @ 2015-07-19 22:38 UTC (permalink / raw) > Are you serious, is GNAT really the only implementation of Ada 2012? Yes > I see a huge list of Ada 95 implementations here: Correct there was still some "mandate" money around and hopes for the old style long term support contracts to keep coming so they updated to '95. Less than a handful had enough business to justify 2005 (not sure how many even completely updated) and AdaCore already managed to leverage most of the leftover Ada market post 95 so there was little reason for vendors to keep going other than finish off existing contracts. The way business is done has changed and none of the Ada vendors have managed to adapt, nor likely ever too. It takes a lot of humility to be nimble enough to make things work in any business especially today and takes even more humility to cultivate a language community without a "mandate" or google budget. The Ada world has never been known for that trait (but there are/have been a few good men)... (Oh my if I had a dollar for every snort...) > I know some of those vendors are still selling product but I don't know > that they've been updated for Ada 2012. I don't see what's so difficult > about it if customers are asking for it--the changes are not that large. Vendors are not aligned with the current markets and trends, so there is no incentive for updates as they can't make money using the old models. AdaCore still has some life in it by leveraging the continued work of the open source communities with their own additions (even if not fully appreciating the contributions of the open source community by publishing a GPL runtime virus version in the fake guise of an open source developer edition, but as I've said many times they do contribute back to the FSF, so while they are not heroes, but they are not villains by any means either). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-17 1:50 ` David Botton 2015-07-17 17:07 ` Anh Vo @ 2015-07-21 6:30 ` Gour 2015-07-21 16:24 ` David Botton [not found] ` <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com> 2 siblings, 1 reply; 168+ messages in thread From: Gour @ 2015-07-21 6:30 UTC (permalink / raw) David Botton <david@botton.com> writes: > D actually does everything you listed just as well or better. Ada as a > language is far stronger for sure (I am one of its biggest advocates), > but Ada suffers from few bindings, foolish license games, much weaker > standard runtime library, no package management system with automatic > builds like dub (although Gnoga now has the start of one and will be > in the next 1.2 release in the coming months), Ada has a much more > limited set of targets, etc. This is interesting observation about D…Considering that you’re even considering writing another front-end, I wonder if you checked the status of Modula-2 R10? (https://bitbucket.org/trijezdci/m2r10) It looks that the spec is done and the guy (trijezdci) is now (again) working on “bootstrap compiler”? Sincerely, Gour -- Abandoning all attachment to the results of his activities, ever satisfied and independent, he performs no fruitive action, although engaged in all kinds of undertakings. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 6:30 ` Gour @ 2015-07-21 16:24 ` David Botton 2015-07-21 17:29 ` Niklas Holsti 0 siblings, 1 reply; 168+ messages in thread From: David Botton @ 2015-07-21 16:24 UTC (permalink / raw) > if you checked the > status of Modula-2 R10? (https://bitbucket.org/trijezdci/m2r10) My hobby interest for the front end is about Ada (perhaps fixing the OO syntax, but still Ada). It is not a serious project as I am both the wrong person for the job and have other higher priorities even in my hobbies. However, I am enjoying the experimenting and paying around with writing a compiler. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 16:24 ` David Botton @ 2015-07-21 17:29 ` Niklas Holsti 2015-07-21 18:51 ` Simon Wright 2015-07-21 19:30 ` David Botton 0 siblings, 2 replies; 168+ messages in thread From: Niklas Holsti @ 2015-07-21 17:29 UTC (permalink / raw) On 15-07-21 19:24 , David Botton wrote: >> if you checked the status of Modula-2 R10? >> (https://bitbucket.org/trijezdci/m2r10) > > My hobby interest for the front end is about Ada (perhaps fixing the > OO syntax, but still Ada). If you remove "tagged", as you said in another post, in my opinion it is no longer Ada (post 95). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 17:29 ` Niklas Holsti @ 2015-07-21 18:51 ` Simon Wright 2015-07-21 19:36 ` David Botton ` (2 more replies) 2015-07-21 19:30 ` David Botton 1 sibling, 3 replies; 168+ messages in thread From: Simon Wright @ 2015-07-21 18:51 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > On 15-07-21 19:24 , David Botton wrote: >>> if you checked the status of Modula-2 R10? >>> (https://bitbucket.org/trijezdci/m2r10) >> >> My hobby interest for the front end is about Ada (perhaps fixing the >> OO syntax, but still Ada). > > If you remove "tagged", as you said in another post, in my opinion it > is no longer Ada (post 95). abstract class type A is procedure P1 (This : in out T) is abstract; end A; class type T is new A with overriding procedure P1 (This : in out A); not overriding function F1 (This : A) return Integer; private V : Integer; end T; etc etc; not a million miles from Ada as we know it. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 18:51 ` Simon Wright @ 2015-07-21 19:36 ` David Botton 2015-07-22 8:44 ` Pascal Obry 2015-07-22 12:00 ` Jean François Martinez 2015-07-21 19:51 ` Dmitry A. Kazakov 2015-07-21 20:05 ` J-P. Rosen 2 siblings, 2 replies; 168+ messages in thread From: David Botton @ 2015-07-21 19:36 UTC (permalink / raw) > abstract class type A is > procedure P1 (This : in out T) is abstract; > end A; > > class type T is new A with > overriding procedure P1 (This : in out A); > not overriding function F1 (This : A) return Integer; > private > V : Integer; > end T; > > etc etc; not a million miles from Ada as we know it. Things would have been so different had Ada not missed its window of opportunity with a syntax more familiar to developers and investments in bindings and interfaces been made. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 19:36 ` David Botton @ 2015-07-22 8:44 ` Pascal Obry 2015-07-22 12:00 ` Jean François Martinez 1 sibling, 0 replies; 168+ messages in thread From: Pascal Obry @ 2015-07-22 8:44 UTC (permalink / raw) Le mardi 21 juillet 2015 à 12:36 -0700, David Botton a écrit : > Things would have been so different had Ada not missed its window of > opportunity with a syntax more familiar to developers and investments > in bindings and interfaces been made. There is zero proof about this and I really don't think it would have changed anything. The current OO syntax for Ada is just good to me and I do not see why developers should have a problem with just this syntax! It is just too easy to blame a language for this where developers are just leaning toward languages that are more permissive because of the hacker beast living in them :) My 2 cents! -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 19:36 ` David Botton 2015-07-22 8:44 ` Pascal Obry @ 2015-07-22 12:00 ` Jean François Martinez 2015-07-27 22:59 ` Randy Brukardt 2015-08-19 22:19 ` rriehle 1 sibling, 2 replies; 168+ messages in thread From: Jean François Martinez @ 2015-07-22 12:00 UTC (permalink / raw) On Tuesday, July 21, 2015 at 9:36:47 PM UTC+2, David Botton wrote: . > > Things would have been so different had Ada not missed its window of opportunity with a syntax more familiar to developers and investments in bindings and interfaces been made. > > David Botton The problem was not syntax. The problems were: 1) Being produced by the eeeeeeeeeevil DOD. That meant politically correct people shunned and disparaged it 2) Missing the PC revolution. When everyone was learning C/C++ with 100$ Turbo C either there was no Ada compiler or it was completley unaffordable for someone paying from his own pocket. Thus the loads of Windows software were written in C/C++ 3) To miss the object train. In the crucial 1985-1995 years when you had to be a object-oriented or die Ada wasn't. That and number two meant employers found it was far easier to recruit C/C++ programmers than Ada ones. 4) Last but not least being a disaster at marketing. Look at the K&R book. It is a delight to read with plenty of attractive little examples and exercises who make the reader feel smart (today I would call many of them demagogic like the infamous one: "while (*dst++=*src++); -- No longer sure about the syntax) the Ada books were booooooooooooring. Look at the the Barnes one. If you skip the introduction you will have to read a gazillion pages about types before there is some action (instructions). That meant many potential users leafed through it and discarded the book and the language, then they leafed through the K&R and went for it. Out of competition: Perhaps because Ada is a language for senior programmers. When you are a junior programmer you don't underntand the benefits of readability, maintanability and non error-prone syntax (In those years I was a fan of... APL!). When you get older you understand but you move into management or system administration. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 12:00 ` Jean François Martinez @ 2015-07-27 22:59 ` Randy Brukardt 2015-07-28 7:00 ` Georg Bauhaus ` (2 more replies) 2015-08-19 22:19 ` rriehle 1 sibling, 3 replies; 168+ messages in thread From: Randy Brukardt @ 2015-07-27 22:59 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3845 bytes --] "Jean François Martinez" <darkquark99@gmail.com> wrote in message news:e8521a43-2bbf-4970-a17b-b585d021f235@googlegroups.com... >On Tuesday, July 21, 2015 at 9:36:47 PM UTC+2, David Botton wrote: > >. >> >> Things would have been so different had Ada not missed its window of >> opportunity with a syntax more familiar to >>developers and investments >> in bindings and interfaces been made. >> >> David Botton > >The problem was not syntax. The problems were: > >1) Being produced by the eeeeeeeeeevil DOD. That meant politically >correct people shunned and disparaged it Certainly true for some. >2) Missing the PC revolution. When everyone was learning C/C++ with 100$ >Turbo C either >there was no Ada compiler or it was completley unaffordable for someone >paying from his >own pocket. Thus the loads of Windows software were written in C/C++ Janus/Ada cost $99 for MS-DOS during this period. By the time Windows came out, Ada was already far behind and it really didn't matter (although both ObjectAda and Janus/Ada were available for under $500 for Windows). (The Meridian compiler and other competitors of ours also had Ada compilers with similar pricing during the MS-DOS days.) Ada didn't quite compete with $29 JRT and $49 Turbo Pascal, but those are not C either. So your premise here is very flawed. >3) To miss the object train. Yup. > In the crucial 1985-1995 years when you had to be a object-oriented or > die Ada > wasn't. That and number two meant employers found it was far easier to > recruit C/C++ > programmers than Ada ones. Of course, this was mainly because people using C++ first got useful modules that way, and they confused modularity (of critical use) with object-orientedness (less useful). But that was a hill that Ada could not climb, even if we were right. >4) Last but not least being a disaster at marketing. Couldn't argue with this, although the example makes no sense. > Look at the K&R book. It is a delight to read with plenty of attractive > little examples and exercises who make the reader feel smart (today I > would call many of them demagogic like the infamous one: "while > (*dst++=*src++); -- No longer sure about the syntax) the Ada books were > booooooooooooring. Look at the the Barnes one. If you skip the > introduction you will have to read a gazillion pages about types before > there is some action (instructions). That meant many potential users > leafed through it and discarded the book and the language, then they > leafed through the K&R and went for it. I never, ever recommended the Barnes book to anyone in those days for that very reason. (Sorry John. ;-). But there were dozens of Ada 83 books and no one had any reason to depend on a dry one. Indeed, we (RR Software) even had our own Ada 83 book, and it's nothing like the Barnes book. For Ada 95, the best book was Cohen's "Ada as a Second Language". It's too bad that he never updated it (he'd left the Ada world by then). Even today, you surely don't have to use John's book (it made my legs get numb when I tried to leaf through the copy he gave me last year - at least it didn't cause me to go over my baggage allowance when returning home!). I recommend "Ada Distilled" (which has the advantage of being free, too). >Out of competition: Perhaps because Ada is a language for senior >programmers. I'm not sure why you consider this "out of competition". I think this is the main reason: Ada is for people who want to write correct, working programs. It's not for hacking (although some of use can be pretty effective hacking in Ada), it's certainly not for prototyping, and so on. So it never was "sexy", and it's not really intended to be fun (unless you have a very weird sense of fun like mine!!). Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-27 22:59 ` Randy Brukardt @ 2015-07-28 7:00 ` Georg Bauhaus 2015-07-28 7:22 ` Paul Rubin 2015-07-28 10:40 ` darkestkhan 2015-07-29 12:38 ` EGarrulo 2 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-28 7:00 UTC (permalink / raw) On 28.07.15 00:59, Randy Brukardt wrote: > Ada is (...) certainly not for prototyping For Ada to be useful here, the specifics of the prototype might play a role, I think: If the prototype depends on libraries inaccessible from Ada, o.K. But otherwise, since prototyping seems more about shams, facades, hollow building blocks, reduced feature set, speed, fake data, limited I/O support, etc., why would C, say, be better for prototyping than Ada? When would SETL, or Python, or BigEEMathSimPack be better suited? If, for example, a LAMP style prototype of some Web based service is to be made, then using either Ada, or Java, or C# doesn't look so forbidding, although it might not be socially acceptable. (I'm currently porting a collection of Python programs from one Python environment to another. The code has evolved from a prototype. I wish Python had Ada like types and parameter profiles if only because of the added value of documenting What This Thing Is™. How is a prototype useful when the language used for prototyping tends to vaporize the Why-and-How of its choices and structure?) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 7:00 ` Georg Bauhaus @ 2015-07-28 7:22 ` Paul Rubin 2015-07-28 10:36 ` darkestkhan ` (2 more replies) 0 siblings, 3 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-28 7:22 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.invalid> writes: > why would C, say, be better for prototyping than Ada? When would SETL, > or Python, or BigEEMathSimPack be better suited? See: Haskell vs. Ada vs. C++ vs. Awk vs. ...: An Experiment in Software Prototyping Productivity by Paul Hudak and Mark P. Jones http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf > How is a prototype useful when the language used for prototyping > tends to vaporize the Why-and-How of its choices and structure?) It lets you test out the intended program features and solidify the specification. In fact you often don't start with much of a specification at all, but rather just a general idea of what you're trying to do. Then you try things out, squeeze things in, get feedback from users and iterate the design, etc. At the end you've got something you can use as a reference when figuring out what a more permanent version should do. It's like making a pencil sketch before starting an oil painting. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 7:22 ` Paul Rubin @ 2015-07-28 10:36 ` darkestkhan 2015-07-28 10:58 ` G.B. 2015-07-28 20:33 ` Randy Brukardt 2 siblings, 0 replies; 168+ messages in thread From: darkestkhan @ 2015-07-28 10:36 UTC (permalink / raw) On Tuesday, July 28, 2015 at 7:22:17 AM UTC, Paul Rubin wrote: > Georg Bauhaus writes: > > why would C, say, be better for prototyping than Ada? When would SETL, > > or Python, or BigEEMathSimPack be better suited? > > See: > > Haskell vs. Ada vs. C++ vs. Awk vs. ...: An Experiment in Software > Prototyping Productivity > > by Paul Hudak and Mark P. Jones > > http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf > 1994, still not Ada 95, C++ w/o stl etc. I wonder how this would look today. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 7:22 ` Paul Rubin 2015-07-28 10:36 ` darkestkhan @ 2015-07-28 10:58 ` G.B. 2015-07-28 20:33 ` Randy Brukardt 2 siblings, 0 replies; 168+ messages in thread From: G.B. @ 2015-07-28 10:58 UTC (permalink / raw) On 28.07.15 09:22, Paul Rubin wrote: > Georg Bauhaus <bauhaus@futureapps.invalid> writes: >> why would C, say, be better for prototyping than Ada? When would SETL, >> or Python, or BigEEMathSimPack be better suited? > > See: > > Haskell vs. Ada vs. C++ vs. Awk vs. ...: An Experiment in Software > Prototyping Productivity > > by Paul Hudak and Mark P. Jones > > http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf O.K., so when the problem lends itself so well to equations of relation, as in this real world example of geometrical constraints, then Haskell is an inescapably natural choice, in particular for the programmer suitably skilled in mathematics. (I mean it.) Views seem to differ when the same approach (higher order function types) is used in drafting GUIs: following flows becomes as easy as interpreting the diagnostic output of C++'s functional template computation hitting an error. I find it a little unfortunate that much emphasis is put on notions such as "elegance" or "conciseness" and "almost like writing a paper" (and not a prototype? :), but that some features are just barely mentioned, like "prototyping support", which I thought would be rather interesting to know. There are mentions of the Prelude, though. Granted, when exploring a model of an algorithm in the abstract, what could be better than a concise, formal abstraction? (And not something for controlling a computer more directly, like Ada or C++?) Which could mean that SPARK is a surprisingly good prototyping language! Specifically, to the extent that provers will handle primitive recursive functions, to match Ada operations later. (Is that practical?) >> How is a prototype useful when the language used for prototyping >> tends to vaporize the Why-and-How of its choices and structure?) > > (...) It's like making a pencil sketch before starting an > oil painting. I do hope this process of producing a (executable) specification isn't as frequently doomed to become a production item by managerial decision to reuse as I have witnessed! The suggestion of Hudak & Jones (NB: WG members FP) may even support this view in spite of Bird's Chapter 7 (Efficiency, Fusions), or considering much use of "strict". (Line count up, complexity of code up, doubled effort through understanding and controlling evaluation, ...) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 7:22 ` Paul Rubin 2015-07-28 10:36 ` darkestkhan 2015-07-28 10:58 ` G.B. @ 2015-07-28 20:33 ` Randy Brukardt 2 siblings, 0 replies; 168+ messages in thread From: Randy Brukardt @ 2015-07-28 20:33 UTC (permalink / raw) "Paul Rubin" <no.email@nospam.invalid> wrote in message news:87lhe0px07.fsf@jester.gateway.sonic.net... ... > It's like making a pencil sketch before starting an oil painting. And much like those pencil sketches (many of which seem to end up in art museums if the painter is famous enough -- the Prada in Madrid was full of them), in many cases those prototypes become the product. And that's the problem with that sort of prototyping -- a language that focuses on ease of writing has to sacrifice ease of maintenance (simply because a lot less is written down), and if the product stays in that language there is going to be a big cost down the road. I always do my prototyping in Ada for that very reason -- if the prototype works well enough (like the Web server and search engines did), it doesn't have to be rewritten just to add the robustness needed for something that will be used decades. But I doubt that I'd ever convince the masses of that value of that approach. Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-27 22:59 ` Randy Brukardt 2015-07-28 7:00 ` Georg Bauhaus @ 2015-07-28 10:40 ` darkestkhan 2015-07-29 7:30 ` Jacob Sparre Andersen 2015-07-29 12:38 ` EGarrulo 2 siblings, 1 reply; 168+ messages in thread From: darkestkhan @ 2015-07-28 10:40 UTC (permalink / raw) On Monday, July 27, 2015 at 10:59:23 PM UTC, Randy Brukardt wrote: > I'm not sure why you consider this "out of competition". I think this is the > main reason: Ada is for people who want to write correct, working programs. > It's not for hacking (although some of use can be pretty effective hacking > in Ada), it's certainly not for prototyping, and so on. So it never was > "sexy", and it's not really intended to be fun (unless you have a very weird > sense of fun like mine!!). Interesting considering that I don't see any problem when it comes to prototyping in Ada... in fact I would say that Ada is very good at it. [I even ended up writing prototypes of things that later on had to be implemented in C/C++] ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 10:40 ` darkestkhan @ 2015-07-29 7:30 ` Jacob Sparre Andersen 2015-07-29 8:55 ` Simon Wright 0 siblings, 1 reply; 168+ messages in thread From: Jacob Sparre Andersen @ 2015-07-29 7:30 UTC (permalink / raw) darkestkhan <darkestkhan@gmail.com> writes: > Interesting considering that I don't see any problem when it comes to > prototyping in Ada... in fact I would say that Ada is very good at it. > [I even ended up writing prototypes of things that later on had to be > implemented in C/C++] I must agree here. You may even see me writing prototypes in Ada, where the final product has to be written in Basic, C or Java - or even implemented in a spreadsheet. I still do some prototyping in Bash, but this is mostly because I haven't found/written a suitable library for connecting non-Ada tools to my Ada programs in a (writing) efficient way. At the moment I'm working on a prototype where the production version most likely will be written in assembly or some highly processor specific language by the customer. But Ada is very practical for writing algorithms in a readable form. Greetings, Jacob -- "... but it was, on the other hand, very good at being a slow and dim-witted pupil." "I had no idea they were supposed to be in short supply" ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 7:30 ` Jacob Sparre Andersen @ 2015-07-29 8:55 ` Simon Wright 0 siblings, 0 replies; 168+ messages in thread From: Simon Wright @ 2015-07-29 8:55 UTC (permalink / raw) Jacob Sparre Andersen <sparre@nbi.dk> writes: > At the moment I'm working on a prototype where the production version > most likely will be written in assembly or some highly processor > specific language by the customer. But Ada is very practical for > writing algorithms in a readable form. I designed a Mascot[1] kernel for a dual-processor F2420 machine[2] in Ada in about 1985. There was a small part (context switching) where "at this point, a miracle occurs". The implementation (in assembler) had one error on delivery and was in service (I believe) up to 2011. This led to unfounded rumours that we had an Ada compiler for the machine! Interestingly, Ravenscar has some commonality with Mascot's approach. [1] http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Manual-June-1987.pdf [2] http://www.cbronline.com/news/ferranti_offers_f2420_at_five_times_power_of_fm1600e ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-27 22:59 ` Randy Brukardt 2015-07-28 7:00 ` Georg Bauhaus 2015-07-28 10:40 ` darkestkhan @ 2015-07-29 12:38 ` EGarrulo 2015-07-29 13:06 ` EGarrulo ` (2 more replies) 2 siblings, 3 replies; 168+ messages in thread From: EGarrulo @ 2015-07-29 12:38 UTC (permalink / raw) On Tuesday, July 28, 2015 at 12:59:23 AM UTC+2, Randy Brukardt wrote: > I'm not sure why you consider this "out of competition". I think this is the > main reason: Ada is for people who want to write correct, working programs. > It's not for hacking (although some of use can be pretty effective hacking > in Ada), it's certainly not for prototyping, and so on. So it never was > "sexy", and it's not really intended to be fun (unless you have a very weird > sense of fun like mine!!). Why wouldn't Ada be good for hacking? The only drawback I can see does not relate to the language itself, but to the lack of flexible standard libraries. For example, in an experiment comparing the productivity of some programming languages[1], and where Haskell comes way ahead of the pack, authors note that "[...] the Haskell prototype was most concise for three reasons: [...] (2) the use of higher-order functions, and (3) the use of standard list-manipulating primitives in the standard [library] Prelude." Ada supports higher- order functions, but it has nothing like the standard library Prelude in Haskell, or the STL in C++. And I find it ironic that Stepanov wrote the original version of the C++ STL in Ada, but then it never found its way into the Ada standard. Why wouldn't Ada be good for prototyping? I would say that the opposite is true, because many recurring abstractions can be conveniently expressed; and the compiler lets you code mindlessly, with the certainty that any stupid mistake will be fixed before the program runs. I have prototyped software in Python and I have found it draining: the program runs until the interpreter finds a stupid mistake and -- boom! -- you have to fix it and restart again. I am sure that had I used Ada instead, I would have completed my prototypes much earlier. If anything, I would say that Ada lacks a clear explanation of how to "think in Ada". Bluntly, it seems that even long-time Ada programmers don't understand Ada deeply. -- [1] http://haskell.cs.yale.edu/?post_type=publication&p=366 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 12:38 ` EGarrulo @ 2015-07-29 13:06 ` EGarrulo 2015-07-29 15:41 ` Paul Rubin 2015-07-30 10:59 ` darkestkhan 2 siblings, 0 replies; 168+ messages in thread From: EGarrulo @ 2015-07-29 13:06 UTC (permalink / raw) On Wednesday, July 29, 2015 at 2:38:43 PM UTC+2, EGarrulo wrote: > Bluntly, it seems that even long-time > Ada programmers don't understand Ada deeply. Or -- more likely -- some long-time Ada programmers can't explain Ada clearly. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 12:38 ` EGarrulo 2015-07-29 13:06 ` EGarrulo @ 2015-07-29 15:41 ` Paul Rubin 2015-07-29 17:01 ` Björn Lundin ` (2 more replies) 2015-07-30 10:59 ` darkestkhan 2 siblings, 3 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-29 15:41 UTC (permalink / raw) EGarrulo <egarrulo@gmail.com> writes: > Why wouldn't Ada be good for hacking? The only drawback I can see > does not relate to the language itself, but to the lack of flexible > standard libraries. Lack of garbage collection (at least in most implementations) is the first thing that comes to mind. > Ada supports higher- order functions, but it has nothing like the > standard library Prelude in Haskell, or the STL in C++. Ada doesn't have meaningful HOF's in the sense of Haskell, afaik. But I thought Ada generics were like the C++ STL? > Why wouldn't Ada be good for prototyping? I would say that the > opposite is true, because many recurring abstractions can be > conveniently expressed; and the compiler lets you code mindlessly, > with the certainty that any stupid mistake will be fixed before the > program runs. 1) no garbage collection, 2) recurring abstractions like dynamically growable lists, strings, dictionaries, etc. might be doable in Ada but are built into Haskell, Python, etc. > I have prototyped software in Python and I have found it draining: the > program runs until the interpreter finds a stupid mistake and -- boom! > -- you have to fix it and restart again. Right, you have to code in a style where you expect that to happen, but it's fairly easy to develop that. > I am sure that had I used Ada instead, I would have completed my > prototypes much earlier. I'd be interested in seeing Ada solutions to a few of the earlier Euler problems, let's say selected from the first 25. You could either look at the problems and pick a few. Or alternatively, pick a number N between 1 and 25 before looking at the problems, and then do problem number N. Or even simpler: print a list of the first 100 primes. This is 3 lines of code in Haskell, see the illustration at the top of www.haskell.org . Here is an exercise that is easy in Haskell but surprisingly tedious in languages like Ada: a number is "5-smooth" or "Hamming" if it has no prime factors greater than 5. So 10, 12, and 15 are 5-smooth but 11, 13, and 14 are not. The first 20 Hamming numbers are: [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36] I was going to ask for the millionth such number, but you need arbitrary precision arithmetic for it. So, what is the 10000th such number? That one fits in 64 bits, but is not really feasible to reach by counting. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 15:41 ` Paul Rubin @ 2015-07-29 17:01 ` Björn Lundin 2015-07-29 18:27 ` Paul Rubin 2015-07-29 17:07 ` Stefan.Lucks 2015-07-29 19:32 ` Georg Bauhaus 2 siblings, 1 reply; 168+ messages in thread From: Björn Lundin @ 2015-07-29 17:01 UTC (permalink / raw) On 2015-07-29 17:41, Paul Rubin wrote: > > 2) recurring abstractions like dynamically > growable lists, strings, dictionaries, etc. might be doable in Ada but > are built into Haskell, Python, etc. See Ada.Containers.* > Or even simpler: print a list of the first 100 primes. This is 3 lines > of code in Haskell, see the illustration at the top of www.haskell.org . > > Here is an exercise that is easy in Haskell but surprisingly tedious in > languages like Ada: a number is "5-smooth" or "Hamming" if it has no > prime factors greater than 5. So 10, 12, and 15 are 5-smooth but 11, > 13, and 14 are not. The first 20 Hamming numbers are: > > [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36] > > I was going to ask for the millionth such number, but you need arbitrary > precision arithmetic for it. So, what is the 10000th such number? That > one fits in 64 bits, but is not really feasible to reach by counting. > They look really mathematical. Haskell territory ? How is Haskell doing in Ada territory, like concurrency etc ? -- Björn ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 17:01 ` Björn Lundin @ 2015-07-29 18:27 ` Paul Rubin 2015-07-29 18:52 ` Björn Lundin 2015-07-29 19:18 ` Georg Bauhaus 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-29 18:27 UTC (permalink / raw) Björn Lundin <b.f.lundin@gmail.com> writes: > See Ada.Containers.* Will look there, but those kinds of containers are more useful with GC. > How is Haskell doing in Ada territory, like concurrency etc ? It's partly on the implementation, but GHC's concurrency is far superior to GNAT's in my opinion. GNAT uses Posix threads while GHC supports lightweight threads with parallel garbage collection. It can handle millions of concurrent threads on a large server: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf GHC also supports software transactional memory (STM), that let threads composably share mutable data without the traditional hazards of lock inversion etc. Haskell's type system statically verifies that STM operations aren't improperly mixed with I/O that could wedge the runtime: http://book.realworldhaskell.org/read/software-transactional-memory.html GHC also supports various kinds of deterministic parallelism, like the "par" operator that lets you very simply annotate that two operations can be done in parallel (on separate cpu cores): https://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/ The cool thing about this is it doesn't affect the datatypes in the program, and if you use it improperly, your program might run slower instead of faster, but it will still find the right answers. There are also data parallelism libraries that will let you spin array computations off to SIMD units or GPU's, but Ada probably has similar libraries. There is an online book about parallel and concurrent programming in Haskell (scroll down for the TOC): http://chimera.labs.oreilly.com/books/1230000000929/index.html ================ Where Ada beats Haskell is in deterministic timing and memory footprint. SPARK has ways to verify that an Ada function can't possibly throw an exception. That's difficult in Haskell, because programs constantly use the memory allocator, and there can also be unpredictable GC pauses at any time in the program. Ada can also compile to small cpu targets because of its small or nonexistent runtime system. So I'd see the archetypal Ada application as a critical embedded system like a jet engine controller, while the archetypal Haskell application is something like a compiler or internet server that must not give wrong answers, but where a pause in execution (or even an OOM crash followed by a failover or workaround) is annoying but not disastrous. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 18:27 ` Paul Rubin @ 2015-07-29 18:52 ` Björn Lundin 2015-07-29 22:18 ` Paul Rubin 2015-07-29 19:18 ` Georg Bauhaus 1 sibling, 1 reply; 168+ messages in thread From: Björn Lundin @ 2015-07-29 18:52 UTC (permalink / raw) On 2015-07-29 20:27, Paul Rubin wrote: > Björn Lundin <b.f.lundin@gmail.com> writes: >> See Ada.Containers.* > > Will look there, but those kinds of containers are more useful with GC. I think you are missing the point. Many things in Ada is done without allocating with 'new' And things that are, if OO, may inherit from Ada.Finalized, which gives a call to the objects' 'Finalize' method where deallcation - if necessary - can be done. So, the user does not fiddle with new/free. declare package Stuff_Pkg is new Ada.Containers.Doubly_Linked_Lists(Stuff_Type); Stuff_data : Stuff_type; Stuff_List : Stuff_Pkg.List begin for i in 1 ..100 loop Stuff_list.Append(Stuff_data): end loop; -- use stuff_list here end; --no mem leak here > >> How is Haskell doing in Ada territory, like concurrency etc ? > > It's partly on the implementation, but GHC's concurrency is far superior > to GNAT's in my opinion. GNAT uses Posix threads while GHC supports > lightweight threads with parallel garbage collection. It can handle > millions of concurrent threads on a large server: > > http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf > > GHC also supports software transactional memory (STM), that let threads > composably share mutable data without the traditional hazards of lock > inversion etc. Haskell's type system statically verifies that STM > operations aren't improperly mixed with I/O that could wedge the runtime: > > http://book.realworldhaskell.org/read/software-transactional-memory.html > > GHC also supports various kinds of deterministic parallelism, like the > "par" operator that lets you very simply annotate that two operations > can be done in parallel (on separate cpu cores): > > https://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/ > > The cool thing about this is it doesn't affect the datatypes in the > program, and if you use it improperly, your program might run slower > instead of faster, but it will still find the right answers. > > There are also data parallelism libraries that will let you spin array > computations off to SIMD units or GPU's, but Ada probably has similar > libraries. > > There is an online book about parallel and concurrent programming in > Haskell (scroll down for the TOC): > > http://chimera.labs.oreilly.com/books/1230000000929/index.html > > ================ > > Where Ada beats Haskell is in deterministic timing and memory footprint. > SPARK has ways to verify that an Ada function can't possibly throw an > exception. That's difficult in Haskell, because programs constantly use > the memory allocator, and there can also be unpredictable GC pauses at > any time in the program. Ada can also compile to small cpu targets > because of its small or nonexistent runtime system. > > So I'd see the archetypal Ada application as a critical embedded system > like a jet engine controller, while the archetypal Haskell application > is something like a compiler or internet server that must not give wrong > answers, but where a pause in execution (or even an OOM crash followed > by a failover or workaround) is annoying but not disastrous. > Interesting reading -- -- Björn ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 18:52 ` Björn Lundin @ 2015-07-29 22:18 ` Paul Rubin 2015-07-30 6:23 ` Dmitry A. Kazakov 2015-07-30 18:10 ` Randy Brukardt 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-29 22:18 UTC (permalink / raw) Björn Lundin <b.f.lundin@gmail.com> writes: >> Will look there, but those kinds of containers are more useful with GC. > I think you are missing the point. Many things in Ada is done without > allocating with 'new' And things that are, if OO, may inherit from > Ada.Finalized, which gives a call to the objects' 'Finalize' method > where deallcation - if necessary - can be done. So, the user does not > fiddle with new/free. Right, that's sort of like C++ RAII. But GC gives you much more flexibility. For example, maybe you want to allocate a container and then pass it to another thread to work on it. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 22:18 ` Paul Rubin @ 2015-07-30 6:23 ` Dmitry A. Kazakov 2015-07-30 16:48 ` David Botton 2015-07-30 18:10 ` Randy Brukardt 1 sibling, 1 reply; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-30 6:23 UTC (permalink / raw) On Wed, 29 Jul 2015 15:18:11 -0700, Paul Rubin wrote: > But GC gives you much more > flexibility. For example, maybe you want to allocate a container and > then pass it to another thread to work on it. As if you could not do this without GC. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 6:23 ` Dmitry A. Kazakov @ 2015-07-30 16:48 ` David Botton 0 siblings, 0 replies; 168+ messages in thread From: David Botton @ 2015-07-30 16:48 UTC (permalink / raw) > > But GC gives you much more > > flexibility. For example, maybe you want to allocate a container and > > then pass it to another thread to work on it. > > As if you could not do this without GC. Actually most GC implementations don't handle cross thread allocations well. Ada was created with facility to support GC and possible to use the Boehm GC with it and some have in the past. However, a well designed Ada program rarely has much use for GC and it tends to sloppy dev most of the time. David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 22:18 ` Paul Rubin 2015-07-30 6:23 ` Dmitry A. Kazakov @ 2015-07-30 18:10 ` Randy Brukardt 1 sibling, 0 replies; 168+ messages in thread From: Randy Brukardt @ 2015-07-30 18:10 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1495 bytes --] "Paul Rubin" <no.email@nospam.invalid> wrote in message news:87wpximwv0.fsf@jester.gateway.sonic.net... > Björn Lundin <b.f.lundin@gmail.com> writes: >>> Will look there, but those kinds of containers are more useful with GC. >> I think you are missing the point. Many things in Ada is done without >> allocating with 'new' And things that are, if OO, may inherit from >> Ada.Finalized, which gives a call to the objects' 'Finalize' method >> where deallcation - if necessary - can be done. So, the user does not >> fiddle with new/free. > > Right, that's sort of like C++ RAII. But GC gives you much more > flexibility. For example, maybe you want to allocate a container and > then pass it to another thread to work on it. What does this have to do with GC? When you pass a container to another task, it gets passed like any other parameter (by-reference in this case). There's no need to create an explicit access type. You need explicit access types in Ada only when you need to have a dynamically organized structure. And even some of those can be replaced by a container (lots of structures are really multi-way trees, so the tree container ought to work well for managing them). (There's also a few cases involving function returns where one might need them for efficiency reasons -- but worrying about that is premature optimization -- only introduce access types if you've demonstrated that the performance is insufficient.) Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 18:27 ` Paul Rubin 2015-07-29 18:52 ` Björn Lundin @ 2015-07-29 19:18 ` Georg Bauhaus 2015-07-29 19:42 ` Randy Brukardt 1 sibling, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-29 19:18 UTC (permalink / raw) On 29.07.15 20:27, Paul Rubin wrote: > Björn Lundin<b.f.lundin@gmail.com> writes: >> >See Ada.Containers.* > Will look there, but those kinds of containers are more useful with GC. See Randy Brukardt's repeated admonishment to use Ada.Containers precisely because they handle storage. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 19:18 ` Georg Bauhaus @ 2015-07-29 19:42 ` Randy Brukardt 2015-07-30 4:54 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Randy Brukardt @ 2015-07-29 19:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1478 bytes --] "Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message news:mpb8r3$a2i$1@dont-email.me... > On 29.07.15 20:27, Paul Rubin wrote: >> Björn Lundin<b.f.lundin@gmail.com> writes: >>> >See Ada.Containers.* >> Will look there, but those kinds of containers are more useful with GC. > > See Randy Brukardt's repeated admonishment to use Ada.Containers > precisely because they handle storage. I'll repeat it so he doesn't have to look it up: the whole point of using such containers is that they handle all of the storage management for you. When using the containers, you don't have to (and shouldn't, IMHO) use any access types at all. The container element can be any non-limited type, which of course includes other containers. Ada 2012 added tree and queue containers, as well as adding syntactic sugar for iterators and indexing, such that containers usage can look pretty much like using a built-in array type. (It's more complex under the covers, of course, but the whole idea is to hide complexity.) And the bounded forms of the containers gives memory certainty for applications that need that. It would be completely unnecessary to use any GC with the Ada containers. You (arguably) need it when you use raw access types, and can't use subpools or a custom storage pool to manage the storage sensibly. That comes up rather rarely in Ada 2012 (unless, of course, you are writing a container implementation). Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 19:42 ` Randy Brukardt @ 2015-07-30 4:54 ` Paul Rubin 2015-07-30 6:15 ` Niklas Holsti 2015-07-30 6:34 ` Dmitry A. Kazakov 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-30 4:54 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > It would be completely unnecessary to use any GC with the Ada containers. It just depends on what the program is doing--if the absence of GC constrains how you organize your program, then you are missing out on something by not having it. Consider a multi-threaded program whose threads communicate through async queues. So a work request comes into one thread, it gets decoded into a dictionary (container instance), and then the dictionary is dropped onto a queue. Another thread later picks it up and processes it, sending the results through yet another queue. This is a very common way to write a Python or Erlang program. But it means you can't rely on syntactic scoping to know when a container is no longer in use. You either have to carefully track where every reference might be, or else use an automatic reclamation scheme (refcounts, GC, or whatever). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 4:54 ` Paul Rubin @ 2015-07-30 6:15 ` Niklas Holsti 2015-07-30 6:34 ` Dmitry A. Kazakov 1 sibling, 0 replies; 168+ messages in thread From: Niklas Holsti @ 2015-07-30 6:15 UTC (permalink / raw) On 15-07-30 07:54 , Paul Rubin wrote: > "Randy Brukardt" <randy@rrsoftware.com> writes: >> It would be completely unnecessary to use any GC with the Ada containers. > > It just depends on what the program is doing--if the absence of GC > constrains how you organize your program, then you are missing out on > something by not having it. > > Consider a multi-threaded program whose threads communicate through > async queues. So a work request comes into one thread, it gets decoded > into a dictionary (container instance), and then the dictionary is > dropped onto a queue. Another thread later picks it up and processes > it, sending the results through yet another queue. This is a very > common way to write a Python or Erlang program. But it means you can't > rely on syntactic scoping to know when a container is no longer in use. > You either have to carefully track where every reference might be, or > else use an automatic reclamation scheme (refcounts, GC, or whatever). No problem doing that with Ada containers. The first thread creates the dictionary in its own container variable, then uses the container's Move operation to move the data into the queue. This erases the first thread's container variable, so its finalization has essentially nothing to do. The second thread uses Move to extract the data from the queue into its own container variable; when that variable is finalized, the dictionary data are deallocated. Reference counting or whatever is done within the container libraries. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 4:54 ` Paul Rubin 2015-07-30 6:15 ` Niklas Holsti @ 2015-07-30 6:34 ` Dmitry A. Kazakov 2015-07-30 6:47 ` Paul Rubin 1 sibling, 1 reply; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-30 6:34 UTC (permalink / raw) On Wed, 29 Jul 2015 21:54:58 -0700, Paul Rubin wrote: > Consider a multi-threaded program whose threads communicate through > async queues. So a work request comes into one thread, it gets decoded > into a dictionary (container instance), and then the dictionary is > dropped onto a queue. Another thread later picks it up and processes > it, sending the results through yet another queue. Since queues marshal data there is no place for GC here. You put a *copy* into the queue on one side and get another *copy* on the other. Queues, messages, mailboxes etc are all by-value. One of the advantages of Ada's tasking was the rendezvous allowing by-reference passing, since rendezvous is a synchronous call. Queueing references (I do it all the time implementing drivers and protocols) is a great pain and GC is no help, because of canceling requests and other sorts of stuff requiring deterministic time and order of execution such actions. GC (at least a built-in one) has no place in systems programming. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 6:34 ` Dmitry A. Kazakov @ 2015-07-30 6:47 ` Paul Rubin 2015-07-30 7:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-30 6:47 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > Since queues marshal data there is no place for GC here. You put a *copy* Oh I see, I didn't realize that. In Python you'd only be passing references. > Queueing references (I do it all the time implementing drivers and > protocols) is a great pain and GC is no help, because of canceling > requests and other sorts of stuff requiring deterministic time and > order of execution such actions. GC (at least a built-in one) has no > place in systems programming. GC makes it simple, at the cost of deterministic timing. I can understand why you might not want that in an Ada program. I don't see how it affects ordering. GC works perfectly fine in systems programming except for some low level operations or if you're doing something timing sensitive. Think of the Lisp machine. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 6:47 ` Paul Rubin @ 2015-07-30 7:20 ` Dmitry A. Kazakov 2015-07-30 23:13 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-30 7:20 UTC (permalink / raw) On Wed, 29 Jul 2015 23:47:41 -0700, Paul Rubin wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> Since queues marshal data there is no place for GC here. You put a *copy* > > Oh I see, I didn't realize that. In Python you'd only be passing references. > >> Queueing references (I do it all the time implementing drivers and >> protocols) is a great pain and GC is no help, because of canceling >> requests and other sorts of stuff requiring deterministic time and >> order of execution such actions. GC (at least a built-in one) has no >> place in systems programming. > > GC makes it simple, at the cost of deterministic timing. I can > understand why you might not want that in an Ada program. I don't see > how it affects ordering. Because a reference does not enforce any specific order it only throws some constraints in. If you wanted to use GC you would have to stuff things with "hard" and "soft" references to ensure, for example, a proper order of finalization (of interdependent things like driver, connection, I/O request, variable). "Soft" and "hard" references quickly become an utter mess without any decent means to test it, e.g. that the mandated order is indeed enforced in all cases. How do you test that? How could you prove anything about it? How do you maintain software changes when you know nothing about the effects of adding/removing a reference? Furthermore, maintaining these references requires memory and other containers to stuff them into. It is frequently 1-n relationships, thus you have to keep a whole list of "soft" and/or "hard" references in an object. Soft references require a lot of cycles to keep them updated, these cycles are all synchronous walking-through lists and doing callbacks. Imagine that in an interrupt routine! Worse, it is not a bounded time, there is no limit on the number of "soft" references. Even worse it is not task-safe, you will need interlocking on top of that huge pile of mess. You will get nice deadlocks if not more complicated interlocking is used, an interlocking that would require even more CPU cycles and even more context switches. And priority inversions would be your least concern. It is great to have things non-deterministic when dealing with system resources, which are all singletons! When will the GC free a resource bound to a to-be-collected object (e.g. a communication port)? How do you wait for this, where do you wait for this? And why all that? Because somebody was too lazy to think the design through? > Think of the Lisp machine. Better not, I want to sleep at night... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 7:20 ` Dmitry A. Kazakov @ 2015-07-30 23:13 ` Paul Rubin 0 siblings, 0 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-30 23:13 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > If you wanted to use GC you would have to stuff things with > "hard" and "soft" references to ensure, for example, a proper order of > finalization (of interdependent things like driver, connection, I/O... Oh I see, you mean order of finalizations. Yeah that's an antipattern in Java and basically not supported in Haskell, other than weakrefs. GC works best for memory and stuff like file handles should be managed by other means. > And why all that? Because somebody was too lazy to think the design > through? http://c2.com/cgi/wiki?LazinessImpatienceHubris ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 15:41 ` Paul Rubin 2015-07-29 17:01 ` Björn Lundin @ 2015-07-29 17:07 ` Stefan.Lucks 2015-07-29 17:47 ` Paul Rubin 2015-07-29 19:32 ` Georg Bauhaus 2 siblings, 1 reply; 168+ messages in thread From: Stefan.Lucks @ 2015-07-29 17:07 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 900 bytes --] On Wed, 29 Jul 2015, Paul Rubin wrote: > Here is an exercise that is easy in Haskell but surprisingly tedious in > languages like Ada: a number is "5-smooth" or "Hamming" if it has no > prime factors greater than 5. So 10, 12, and 15 are 5-smooth but 11, > 13, and 14 are not. The first 20 Hamming numbers are: > > [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36] > > I was going to ask for the millionth such number, but you need arbitrary > precision arithmetic for it. So, what is the 10000th such number? That > one fits in 64 bits, but is not really feasible to reach by counting. > http://rosettacode.org/wiki/Hamming_numbers#Ada -------- I love the taste of Cryptanalysis in the morning! -------- www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks ----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany---- ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 17:07 ` Stefan.Lucks @ 2015-07-29 17:47 ` Paul Rubin 2015-08-21 23:03 ` Waldek Hebisch 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-29 17:47 UTC (permalink / raw) Stefan.Lucks@uni-weimar.de writes: > http://rosettacode.org/wiki/Hamming_numbers#Ada That is not a reasonable solution IMHO. It counts upwards 1,2,3... testing each number for the testing property. Computers now are fast enough that this can run through a 32-bit count without taking all day, so it is able to find the 1691th number which is around 2e9. But the 10000th number is around 3e17 and the Haskell program finds it basically instantly. The documentation for the Ada program mentions it would have to use a bignum library to find the millionth Hamming number, which overlooks the issue that the number is around 5e83 and counting that far would take essentially forever. The Haskell program gets it in a few seconds. You could implement the Haskell algorithm in Ada with a page or two of code but it would be rather tedious. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 17:47 ` Paul Rubin @ 2015-08-21 23:03 ` Waldek Hebisch 2015-08-22 3:24 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Waldek Hebisch @ 2015-08-21 23:03 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: > Stefan.Lucks@uni-weimar.de writes: > > http://rosettacode.org/wiki/Hamming_numbers#Ada > That is not a reasonable solution IMHO. It counts upwards > 1,2,3... testing each number for the testing property. Computers now > are fast enough that this can run through a 32-bit count without taking > all day, so it is able to find the 1691th number which is around 2e9. > But the 10000th number is around 3e17 and the Haskell program finds it > basically instantly. The documentation for the Ada program mentions it > would have to use a bignum library to find the millionth Hamming number, > which overlooks the issue that the number is around 5e83 and counting > that far would take essentially forever. The Haskell program gets it in > a few seconds. You could implement the Haskell algorithm in Ada with > a page or two of code but it would be rather tedious. AFAICS iterative version which uses array as a stream buffer is about 20 lines long and quite easy to write. In fact, version which takes allowed prime divisors as paramenter seem to be shorter than versions specialized to 2, 3 and 5. So, Haskell version is smaller but other can be quite small too. -- Waldek Hebisch hebisch@antispam.uni.wroc.pl ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-21 23:03 ` Waldek Hebisch @ 2015-08-22 3:24 ` Paul Rubin 2015-08-23 16:26 ` Waldek Hebisch 2015-08-23 23:01 ` Waldek Hebisch 0 siblings, 2 replies; 168+ messages in thread From: Paul Rubin @ 2015-08-22 3:24 UTC (permalink / raw) Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes: >> > http://rosettacode.org/wiki/Hamming_numbers#Ada > AFAICS iterative version which uses array as a stream buffer > is about 20 lines long and quite easy to write. I'd be interested in seeing what that looks like. There's a Java version on rosettacode that uses priority queues and is somewhat messy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-22 3:24 ` Paul Rubin @ 2015-08-23 16:26 ` Waldek Hebisch 2015-08-23 17:18 ` Jeffrey R. Carter 2015-08-23 23:01 ` Waldek Hebisch 1 sibling, 1 reply; 168+ messages in thread From: Waldek Hebisch @ 2015-08-23 16:26 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: > Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes: > >> > http://rosettacode.org/wiki/Hamming_numbers#Ada > > AFAICS iterative version which uses array as a stream buffer > > is about 20 lines long and quite easy to write. > > I'd be interested in seeing what that looks like. There's a Java > version on rosettacode that uses priority queues and is somewhat messy. See below: computational part has 19 lines, the rest is driver to print result and a boilerplate. This version is limited to Integer size, need different type to get bigger size. Number of artitmetic operations is linear with n0, so with appripriate numeric type could go to quite large n0. with Ada.Integer_Text_IO; -- 1 10.1.2, A.10 Context clause procedure hamming is n0 : constant integer := 1_691; buff : array(1..n0) of Integer; procedure hamn(n : Integer) is cand : array(1..3) of Integer; ind : array(1..3) of Integer := (1, 1, 1); p : array(1..3) of Integer := (2, 3, 5); cmin : Integer; begin buff(1) := 1; for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop; cmin := cand(1); for j in 2..3 loop if cand(j) < cmin then cmin := cand(j); end if; end loop; buff(i) := cmin; for j in 1..3 loop if cand(j) = cmin then ind(j) := ind(j) + 1; end if; end loop; end loop; end hamn; begin hamn(n0); for i in 1..10 loop Ada.Integer_Text_IO.put(buff(i)); end loop; Ada.Integer_Text_IO.put(buff(n0)); end hamming; -- Waldek Hebisch hebisch@math.uni.wroc.pl ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-23 16:26 ` Waldek Hebisch @ 2015-08-23 17:18 ` Jeffrey R. Carter 2015-08-23 17:31 ` Waldek Hebisch 0 siblings, 1 reply; 168+ messages in thread From: Jeffrey R. Carter @ 2015-08-23 17:18 UTC (permalink / raw) On 08/23/2015 09:26 AM, Waldek Hebisch wrote: > > with Ada.Integer_Text_IO; -- 1 10.1.2, A.10 Context clause > procedure hamming is > n0 : constant integer := 1_691; > buff : array(1..n0) of Integer; > procedure hamn(n : Integer) is N is unreferenced. > cand : array(1..3) of Integer; > ind : array(1..3) of Integer := (1, 1, 1); > p : array(1..3) of Integer := (2, 3, 5); > cmin : Integer; > begin > buff(1) := 1; > for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop; > cmin := cand(1); > for j in 2..3 loop > if cand(j) < cmin then cmin := cand(j); end if; > end loop; > buff(i) := cmin; I is not defined. > for j in 1..3 loop > if cand(j) = cmin then ind(j) := ind(j) + 1; end if; > end loop; > end loop; No matching "loop" for this "end loop;" > end hamn; > > begin > hamn(n0); > for i in 1..10 loop > Ada.Integer_Text_IO.put(buff(i)); > end loop; > Ada.Integer_Text_IO.put(buff(n0)); > end hamming; -- Jeff Carter "I blow my nose on you." Monty Python & the Holy Grail 03 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-23 17:18 ` Jeffrey R. Carter @ 2015-08-23 17:31 ` Waldek Hebisch 2015-08-23 19:32 ` Jeffrey R. Carter 0 siblings, 1 reply; 168+ messages in thread From: Waldek Hebisch @ 2015-08-23 17:31 UTC (permalink / raw) Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote: > On 08/23/2015 09:26 AM, Waldek Hebisch wrote: > > > > with Ada.Integer_Text_IO; -- 1 10.1.2, A.10 Context clause > > procedure hamming is > > n0 : constant integer := 1_691; > > buff : array(1..n0) of Integer; > > procedure hamn(n : Integer) is > > N is unreferenced. Oops, my editor messed formatting. Fixing formatting I lost a line (of course now formatting needs to be fixed again...). > > cand : array(1..3) of Integer; > > ind : array(1..3) of Integer := (1, 1, 1); > > p : array(1..3) of Integer := (2, 3, 5); > > cmin : Integer; > > begin > > buff(1) := 1; for i in 2..n loop > > for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop; > > cmin := cand(1); > > for j in 2..3 loop > > if cand(j) < cmin then cmin := cand(j); end if; > > end loop; > > buff(i) := cmin; > > I is not defined. > > > for j in 1..3 loop > > if cand(j) = cmin then ind(j) := ind(j) + 1; end if; > > end loop; > > end loop; > > No matching "loop" for this "end loop;" > > > end hamn; > > > > begin > > hamn(n0); > > for i in 1..10 loop > > Ada.Integer_Text_IO.put(buff(i)); > > end loop; > > Ada.Integer_Text_IO.put(buff(n0)); > > end hamming; > -- Waldek Hebisch hebisch@math.uni.wroc.pl ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-23 17:31 ` Waldek Hebisch @ 2015-08-23 19:32 ` Jeffrey R. Carter 0 siblings, 0 replies; 168+ messages in thread From: Jeffrey R. Carter @ 2015-08-23 19:32 UTC (permalink / raw) Making it look a bit more like Ada, and using an unbounded-integer pkg: with Ada.Text_IO; with PragmARC.Unbounded_Integers; procedure Hamming is use PragmARC.Unbounded_Integers; Max : constant := 1_000_000; One : constant Unbounded_Integer := To_Unbounded_Integer (1); Two : constant Unbounded_Integer := To_Unbounded_Integer (2); Three : constant Unbounded_Integer := To_Unbounded_Integer (3); Five : constant Unbounded_Integer := To_Unbounded_Integer (5); type Buffer is array (1 .. Max) of Unbounded_Integer; procedure Hamming (Buff : out Buffer) is type Work_List is array (1 .. 3) of Unbounded_Integer; type Index_List is array (Work_List'Range) of Positive; P : constant Work_List := (Two, Three, Five); Cand : Work_List; Ind : Index_List := (1, 1, 1); Min : Unbounded_Integer; begin -- Hamming Buff (Buff'First) := One; All_Results : for I in Buff'First + 1 .. Buff'Last loop Candidates : for J in Work_List'Range loop Cand (J) := P (J) * Buff (Ind (J) ); end loop Candidates; Min := Cand (Cand'First); Find_Min : for J in Cand'First + 1 .. Cand'Last loop if Cand (J) < Min then Min := Cand (J); end if; end loop Find_Min; Buff (I) := Min; Increment_Mins : for J in Work_List'Range loop if Cand (J) = Min then Ind (J) := Ind (J) + 1; end if; end loop Increment_Mins; end loop All_Results; end Hamming; type Buffer_Ptr is access Buffer; Buff : constant Buffer_Ptr := new Buffer; begin -- Hamming Hamming (Buff => Buff.all); First_20 : for I in 1 .. 20 loop Ada.Text_IO.Put_Line (Item => Integer'Image (I) & ' ' & Image (Buff (I) ) ); end loop First_20; Ada.Text_IO.Put_Line (Item => " 1691" & ' ' & Image (Buff (1691) ) ); Ada.Text_IO.Put_Line (Item => Integer'Image (Max) & ' ' & Image (Buff (Max) ) ); end Hamming; Which gives $ time ./hamming 1 1 2 2 3 3 4 4 5 5 6 6 7 8 8 9 9 10 10 12 11 15 12 16 13 18 14 20 15 24 16 25 17 27 18 30 19 32 20 36 1691 2125764000 1000000 519312780448388736089589843750000000000000000000000000000000000000000000000000000000 real 0m6.534s user 0m6.432s sys 0m0.092s on a 2-GHz Core 2 Duo. More modern processors will no doubt be faster. The PragmAda Reusable Components are available at https://pragmada.x10hosting.com/pragmarc.htm PragmARC.Unbounded_Integers is only available in the beta version for ISO/IEC 8652:2007 since it uses Ada.Containers. -- Jeff Carter "I blow my nose on you." Monty Python & the Holy Grail 03 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-22 3:24 ` Paul Rubin 2015-08-23 16:26 ` Waldek Hebisch @ 2015-08-23 23:01 ` Waldek Hebisch 1 sibling, 0 replies; 168+ messages in thread From: Waldek Hebisch @ 2015-08-23 23:01 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: > Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes: > >> > http://rosettacode.org/wiki/Hamming_numbers#Ada > > AFAICS iterative version which uses array as a stream buffer > > is about 20 lines long and quite easy to write. > > I'd be interested in seeing what that looks like. There's a Java > version on rosettacode that uses priority queues and is somewhat messy. I provided Ada version in another post. However, several entries in Rosetta Code use essentially the same method. In particular: ALGOL 68, AWK, BBC BASIC, C# (first and second), D (first version), ERRE, Fortran, Go, Liberty BASIC, Nim, PARI/GP. -- Waldek Hebisch hebisch@math.uni.wroc.pl ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 15:41 ` Paul Rubin 2015-07-29 17:01 ` Björn Lundin 2015-07-29 17:07 ` Stefan.Lucks @ 2015-07-29 19:32 ` Georg Bauhaus 2015-07-30 5:17 ` Paul Rubin 2 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-29 19:32 UTC (permalink / raw) On 29.07.15 17:41, Paul Rubin wrote: > Here is an exercise that is easy in Haskell but surprisingly tedious in > languages like Ada OTOH, it keeps being surprisingly tedious to turn clear and simple Haskell algorithms into something that respects time and storage. GHC seems to have become just a little better over the years. Naively computing a sum picking by picking every mth element from a list, picksum :: [Int] -> Int -> Int picksum [] m = 0 picksum xs m | m <= 0 = 0 | m > 0 = mth xs where mth l@(y:ys) = y + mth (drop m l) mth [] = 0 Then, try this with the justly famed easy list notation, passing [1 .. 12345678], or larger. (I have GHC 7.8.3, maybe that's too old?) Of course, the language war soldier of Haskell will argue that the enemy writer of the above algorithm was stupid, and that the same thing happens if you do use lists in Ada, from Ada.Containers, instead of what any competent programmer would be writing in either language. Whatever that might be. But it's definitely good for prototyping, that much seems obvious, I think. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 19:32 ` Georg Bauhaus @ 2015-07-30 5:17 ` Paul Rubin 2015-07-30 7:38 ` Georg Bauhaus 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-30 5:17 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.invalid> writes: > picksum :: [Int] -> Int -> Int > picksum [] m = 0 > picksum xs m > | m <= 0 = 0 > | m > 0 = mth xs > where mth l@(y:ys) = y + mth (drop m l) > mth [] = 0 > > Then, try this with the justly famed easy list notation, passing > [1 .. 12345678], or larger. (I have GHC 7.8.3, maybe that's too old?) > Of course, the language war soldier of Haskell will argue that the > enemy writer of the above algorithm was stupid, Nah, there's a trick that's not obvious to beginners but it's one of the first things you learn in functional programming, and it's not a big deal once you know it. Basically the recursive call to "mth" has to return a value that gets added to y, which means the stack frame can't get released til the addition has happened. You instead want to write it tail recursively with an accumulator, something like: > ... | m > 0 = mth xs 0 > where mth l@(y:ys) !a = mth (drop m l) (y+a) > mth [] a = a Note the !a in the pattern-- that's a strictness marker to stop unevaluated sums from piling up on the stack. Again it takes some getting used to but you learn to spot these things. I might have written the function like this: p2 :: [Int] -> Int -> Int p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs but the sum might have to be replaced with "foldl1' (+)" for strictness. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 5:17 ` Paul Rubin @ 2015-07-30 7:38 ` Georg Bauhaus 2015-07-30 18:26 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-30 7:38 UTC (permalink / raw) On 30.07.15 07:17, Paul Rubin wrote: > Basically the recursive call to "mth" has to > return a value that gets added to y, which means the stack frame can't > get released til the addition has happened. Aren't these features (tail recursion, strict, ...) among the reasons why Haskell got lazy strategies in the first place? And still, whenever time and storage do matter, we need to know how to control another, rather sophisticated machine. We still change our algorithms! I guess I'm repeating old commentary. > p2 :: [Int] -> Int -> Int > p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs (Nitpick: This loops when m<=0, try "p2 [1] 0". (*)). While *Main> picksum [1 .. 123456789] 6 was done after some 28 seconds (19 seconds with your !a-ccumulator and pragma {-# LANGUAGE BangPatterns #-}, news to me, thanks!), I waited minutes after intense disk swapping for *Main> p2 [1 .. 123456789] 6 ^C Seems another feature of prototyping is apparent: can't use larger data sets. I guess I have also missed some way or other of controlling the prototyping interpreter (GHCi) that would make it produce more efficient code, ways that would be "obvious" to ... of course ;-) __ (*) The effect is somewhat like that of asking the Heart of Gold for tea. So, careful! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 7:38 ` Georg Bauhaus @ 2015-07-30 18:26 ` Paul Rubin 2015-07-30 18:37 ` Paul Rubin 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-30 18:26 UTC (permalink / raw) Georg Bauhaus <bauhaus@futureapps.invalid> writes: > Aren't these features (tail recursion, strict, ...) among the reasons > why Haskell got lazy strategies in the first place? Tail recursion is a standard FP thing and you have to do it in Scheme and ML as well. Haskell's lazy evaluation was an interesting experiment that has its good and bad points. The interesting next-generation FP languages like Idris seem to have gone back to strict evaluation, though there's stuff happening in the theory community that might show up in languages further down the road, that might allow strict/lazy combinations whose behavior is tracked by type systems better than has been done in the past. >> p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs > (Nitpick: This loops when m<=0, try "p2 [1] 0". (*)). Yeah, it was supposed to only be illustrative of how to compute the sum without all that explicit recursion. To handle the non-positve case, add p2 _ m | m <= 0 = 0 > {-# LANGUAGE BangPatterns #-}, news to me, thanks!), I waited minutes after > intense disk swapping for > *Main> p2 [1 .. 123456789] 6 OK, yeah, as predicted, the problem is that ghci isn't noticing it can optimize sum as strict. ghc -O would probably do it. Try writing: import Data.List (foldl1') p2 :: [Int] -> Int -> Int p2 _ m | m <= 0 = 0 p2 xs m = foldl1' (+) . map head . takeWhile (not . null) . iterate (drop m) $ xs (Mostly the same thing, except for the formatting). > Seems another feature of prototyping is apparent: can't use larger data sets. > I guess I have also missed some way or other of controlling the prototyping > interpreter (GHCi) that would make it produce more efficient code, ways that > would be "obvious" to ... of course ;-) I usually run ghci in an emacs window so I can kill the window (which also kills the ghci process) if it goes berserk. Also run "w" in another window so you can see the memory consumption climbing in the case of a space leak. You can usually ctrl-c out of it if you do it before the system is pushed into swapping. Or you could use ulimit to bound the memory footprint, or run in a VM, or whatever. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 18:26 ` Paul Rubin @ 2015-07-30 18:37 ` Paul Rubin 2015-07-31 7:14 ` Georg Bauhaus 0 siblings, 1 reply; 168+ messages in thread From: Paul Rubin @ 2015-07-30 18:37 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> writes: > import Data.List (foldl1') ... > p2 xs m = foldl1' (+) Actually this will fail on an empty list. Better would be foldl' (+) 0 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-30 18:37 ` Paul Rubin @ 2015-07-31 7:14 ` Georg Bauhaus 0 siblings, 0 replies; 168+ messages in thread From: Georg Bauhaus @ 2015-07-31 7:14 UTC (permalink / raw) On 30.07.15 20:37, Paul Rubin wrote: > Paul Rubin <no.email@nospam.invalid> writes: >> import Data.List (foldl1') ... >> p2 xs m = foldl1' (+) > > Actually this will fail on an empty list. Better would be foldl' (+) 0 > Down to 7 seconds. Given the component functions of p2, they made me think about ways of arranging the parallel loops of Ada 2X. Maybe around Cursor objects and generators. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 12:38 ` EGarrulo 2015-07-29 13:06 ` EGarrulo 2015-07-29 15:41 ` Paul Rubin @ 2015-07-30 10:59 ` darkestkhan 2 siblings, 0 replies; 168+ messages in thread From: darkestkhan @ 2015-07-30 10:59 UTC (permalink / raw) On Wednesday, July 29, 2015 at 12:38:43 PM UTC, EGarrulo wrote: > Why wouldn't Ada be good for hacking? The only drawback I can see > does not relate to the language itself, but to the lack of flexible > standard libraries. For example, in an experiment comparing the > productivity of some programming languages[1], and where Haskell > comes way ahead of the pack, authors note that "[...] the Haskell > prototype was most concise for three reasons: [...] (2) the use of > higher-order functions, and (3) the use of standard list-manipulating > primitives in the standard [library] Prelude." Ada supports higher- > order functions, but it has nothing like the standard library Prelude > in Haskell, or the STL in C++. And I find it ironic that Stepanov > wrote the original version of the C++ STL in Ada, but then it never > found its way into the Ada standard. Check Annex A in Ada Reference Manual. You got Ada.Containers.* for standard containers, Ada.Strings.* for string handling (also Unbounded_Strings), Ada.Numerics.*, etc. There are also Annexes C, D, F and G... (E is far too specific for distributed systems and usually not that much needed in day-to-day basis) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 12:00 ` Jean François Martinez 2015-07-27 22:59 ` Randy Brukardt @ 2015-08-19 22:19 ` rriehle 2015-08-19 22:58 ` Anh Vo 1 sibling, 1 reply; 168+ messages in thread From: rriehle @ 2015-08-19 22:19 UTC (permalink / raw) As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments. Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started. You are correct about other things. Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada. Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price. Janus was a really good compiler, but did not have easy support for Windows programming. Alsys was huge, cumbersome, too expensive, and not suitable for any small organization. The Alsys complier did generate some pretty good code, but no one was comcerned about that. There weren't many other options. So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time. I talked with Phillipe Kahn about Ada. He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost. The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT. Once he left AJPO, he began to publicly disparage Ada, and that did not help at all. The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD. Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada. The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success. Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice. We have lots of talented programmers, but few of them have any engineering background or understanding of engineering. An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering. We, the past and present devotees of Ada, have made a lot of mistakes. It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada. However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more. We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities. That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use. I am now old, soon to enjoy my 80th birthday. My time as an advocate will soon have passed. Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada. It is, in my view, still Ada. It is cerainly not C++. Never has been. Why would anyone choose a language that is inherently error-prone and expect a result that is error-free? Richard Riehle, PhD ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-19 22:19 ` rriehle @ 2015-08-19 22:58 ` Anh Vo 2015-08-19 23:32 ` rriehle 0 siblings, 1 reply; 168+ messages in thread From: Anh Vo @ 2015-08-19 22:58 UTC (permalink / raw) On Wednesday, August 19, 2015 at 3:19:45 PM UTC-7, rri...@itu.edu wrote: > As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments. Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started. > > You are correct about other things. Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada. Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price. Janus was a really good compiler, but did not have easy support for Windows programming. Alsys was huge, cumbersome, too expensive, and not suitable for any small organization. The Alsys complier did generate some pretty good code, but no one was comcerned about that. There weren't many other options. > > So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time. I talked with Phillipe Kahn about Ada. He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost. The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT. Once he left AJPO, he began to publicly disparage Ada, and that did not help at all. > > The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD. Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada. The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success. > > > Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice. We have lots of talented programmers, but few of them have any engineering background or understanding of engineering. An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering. > > We, the past and present devotees of Ada, have made a lot of mistakes. It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada. However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more. > > We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities. That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use. > > I am now old, soon to enjoy my 80th birthday. My time as an advocate will soon have passed. Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada. It is, in my view, still Ada. It is cerainly not C++. Never has been. Why would anyone choose a language that is inherently error-prone and expect a result that is error-free? > Happy birthday Richard. I am not sure if how many people have read this article. I have enjoyed it very much. As the result, I am proud to say that Ada and Spark doing better than the rest when compared 11 other university projects. This success story will brighten your birthday even more. http://www.adacore.com/press/spark-going-to-the-moon/ Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-19 22:58 ` Anh Vo @ 2015-08-19 23:32 ` rriehle 2015-08-20 1:08 ` Peter Chapin 2015-08-21 15:14 ` Anh Vo 0 siblings, 2 replies; 168+ messages in thread From: rriehle @ 2015-08-19 23:32 UTC (permalink / raw) On Wednesday, August 19, 2015 at 3:58:04 PM UTC-7, Anh Vo wrote: > On Wednesday, August 19, 2015 at 3:19:45 PM UTC-7, rri...@itu.edu wrote: > > As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments. Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started. > > > > You are correct about other things. Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada. Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price. Janus was a really good compiler, but did not have easy support for Windows programming. Alsys was huge, cumbersome, too expensive, and not suitable for any small organization. The Alsys complier did generate some pretty good code, but no one was comcerned about that. There weren't many other options. > > > > So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time. I talked with Phillipe Kahn about Ada. He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost. The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT. Once he left AJPO, he began to publicly disparage Ada, and that did not help at all. > > > > The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD. Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada. The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success. > > > > > > Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice. We have lots of talented programmers, but few of them have any engineering background or understanding of engineering. An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering. > > > > We, the past and present devotees of Ada, have made a lot of mistakes. It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada. However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more. > > > > We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities. That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use. > > > > I am now old, soon to enjoy my 80th birthday. My time as an advocate will soon have passed. Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada. It is, in my view, still Ada. It is cerainly not C++. Never has been. Why would anyone choose a language that is inherently error-prone and expect a result that is error-free? > > > > Happy birthday Richard. > > I am not sure if how many people have read this article. I have enjoyed it very much. As the result, I am proud to say that Ada and Spark doing better than the rest when compared 11 other university projects. This success story will brighten your birthday even more. > > http://www.adacore.com/press/spark-going-to-the-moon/ > > Anh Vo Thanks, Anh. I am pleased to see that some good projects are being developed in Ada. We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada. My 80th is a few months away, but thanks for the congratulatory note. Send me your email address, please. Mine, my personal email is laoxiaohai@juno.com. I may have something to send you. Richard ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-19 23:32 ` rriehle @ 2015-08-20 1:08 ` Peter Chapin 2015-08-21 15:14 ` Anh Vo 1 sibling, 0 replies; 168+ messages in thread From: Peter Chapin @ 2015-08-20 1:08 UTC (permalink / raw) On Wed, 19 Aug 2015, rriehle@itu.edu wrote: > On Wednesday, August 19, 2015 at 3:58:04 PM UTC-7, Anh Vo wrote: >> >> Happy birthday Richard. >> >> I am not sure if how many people have read this article. I have enjoyed >> it very much. As the result, I am proud to say that Ada and Spark doing >> better than the rest when compared 11 other university projects. This >> success story will brighten your birthday even more. >> >> http://www.adacore.com/press/spark-going-to-the-moon/ >> >> Anh Vo > > Thanks, Anh. I am pleased to see that some good projects are being > developed in Ada. We need to publicize this one, and any others that > demonstrate the unique properties of software created with Ada. I am involved with this project at Vermont Technical College where I am working with a small group of students on the flight control software. We have a web page here: http://www.cubesatlab.org/ and a blog here: http://cubesatlab.blogspot.com/ Both are a bit sketchy at this time but we hope to enhance them in the coming months. The project is looking at a 2018 launch on SLS with spacecraft delivery in the second half of 2017. We are in the early stages of development... in fact we are still gathering basic requirements. It should be fun! Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-19 23:32 ` rriehle 2015-08-20 1:08 ` Peter Chapin @ 2015-08-21 15:14 ` Anh Vo 2015-08-21 16:07 ` Anh Vo 1 sibling, 1 reply; 168+ messages in thread From: Anh Vo @ 2015-08-21 15:14 UTC (permalink / raw) > Thanks, Anh. I am pleased to see that some good projects are being developed in Ada. We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada. > > My 80th is a few months away, but thanks for the congratulatory note. > > Send me your email address, please. Mine, my personal email is laoxiaohai@juno.com. I may have something to send you. > Richard, I sent to your private email as you indicated couple days ago. Please check it if it was filtered out. Thanks. Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-21 15:14 ` Anh Vo @ 2015-08-21 16:07 ` Anh Vo 2015-08-21 17:17 ` Patrick Noffke 0 siblings, 1 reply; 168+ messages in thread From: Anh Vo @ 2015-08-21 16:07 UTC (permalink / raw) On Friday, August 21, 2015 at 8:14:24 AM UTC-7, Anh Vo wrote: > > Thanks, Anh. I am pleased to see that some good projects are being developed in Ada. We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada. > > > > My 80th is a few months away, but thanks for the congratulatory note. > > > > Send me your email address, please. Mine, my personal email is laoxiaohai@juno.com. I may have something to send you. > > > > Richard, I sent to your private email as you indicated couple days ago. Please check it if it was filtered out. Thanks. > Here is another gift for your soon 08th birthday Richard. I got it from The McHale Report <eletter@opensystemsmedia.com>. http://mil-embedded.com/articles/what-language-ada-its-competition/ Anh Vo ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-08-21 16:07 ` Anh Vo @ 2015-08-21 17:17 ` Patrick Noffke 0 siblings, 0 replies; 168+ messages in thread From: Patrick Noffke @ 2015-08-21 17:17 UTC (permalink / raw) On Friday, August 21, 2015 at 11:07:53 AM UTC-5, Anh Vo wrote: > > http://mil-embedded.com/articles/what-language-ada-its-competition/ > What a horrible article. There is no substance to how Ada is gaining popularity in universities (all they say is that AdaCore is providing them with tools). There is not even information, much less substantiation, on how Ada is "undergoing a revival of sorts" or actually gaining in popularity, despite very prominent text claiming so. Patrick ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 18:51 ` Simon Wright 2015-07-21 19:36 ` David Botton @ 2015-07-21 19:51 ` Dmitry A. Kazakov 2015-07-21 21:06 ` Simon Wright 2015-07-22 12:53 ` Vincent 2015-07-21 20:05 ` J-P. Rosen 2 siblings, 2 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-21 19:51 UTC (permalink / raw) On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> On 15-07-21 19:24 , David Botton wrote: >>>> if you checked the status of Modula-2 R10? >>>> (https://bitbucket.org/trijezdci/m2r10) >>> >>> My hobby interest for the front end is about Ada (perhaps fixing the >>> OO syntax, but still Ada). >> >> If you remove "tagged", as you said in another post, in my opinion it >> is no longer Ada (post 95). > > abstract class type A is > procedure P1 (This : in out T) is abstract; > end A; > > class type T is new A with > overriding procedure P1 (This : in out A); > not overriding function F1 (This : A) return Integer; > private > V : Integer; > end T; > > etc etc; not a million miles from Ada as we know it. Conceptually it is. Operations do not belong to types. Then everybody agreed that the syntax of protected objects was a mistake. Why repeating this flawed syntax for classes? It is again about fundamentals, privacy is not a type property. It is of a module. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 19:51 ` Dmitry A. Kazakov @ 2015-07-21 21:06 ` Simon Wright 2015-07-21 21:51 ` Dmitry A. Kazakov 2015-07-27 22:44 ` Randy Brukardt 2015-07-22 12:53 ` Vincent 1 sibling, 2 replies; 168+ messages in thread From: Simon Wright @ 2015-07-21 21:06 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote: >> abstract class type A is >> procedure P1 (This : in out T) is abstract; >> end A; >> >> class type T is new A with >> overriding procedure P1 (This : in out A); >> not overriding function F1 (This : A) return Integer; >> private >> V : Integer; >> end T; >> >> etc etc; not a million miles from Ada as we know it. > > Conceptually it is. Operations do not belong to types. Huh? > Then everybody agreed that the syntax of protected objects was a > mistake. I don't remember agreeing > Why repeating this flawed syntax for classes? It is again about > fundamentals, privacy is not a type property. It is of a module. Well, as far as I can see protected types, tasks and (in this not-to-be-taken-seriously proposal) classes are modules, in a way. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 21:06 ` Simon Wright @ 2015-07-21 21:51 ` Dmitry A. Kazakov 2015-07-21 22:55 ` Jeffrey R. Carter 2015-07-22 7:01 ` Simon Wright 2015-07-27 22:44 ` Randy Brukardt 1 sibling, 2 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-21 21:51 UTC (permalink / raw) On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote: > >>> abstract class type A is >>> procedure P1 (This : in out T) is abstract; >>> end A; >>> >>> class type T is new A with >>> overriding procedure P1 (This : in out A); >>> not overriding function F1 (This : A) return Integer; >>> private >>> V : Integer; >>> end T; >>> >>> etc etc; not a million miles from Ada as we know it. >> >> Conceptually it is. Operations do not belong to types. > > Huh? function "*" (X : Matrix; Y : Vector) return Vector; To which type does "*" belong? >> Then everybody agreed that the syntax of protected objects was a >> mistake. > > I don't remember agreeing The object's private part should not appear in the package's public part. It is a privacy breach. >> Why repeating this flawed syntax for classes? It is again about >> fundamentals, privacy is not a type property. It is of a module. > > Well, as far as I can see protected types, tasks and (in this > not-to-be-taken-seriously proposal) classes are modules, in a way. Then they should be compilation units, which would make them unusable. Though they are already unusable when more than one type should be declared. The most typical declaration order is types first: type X1 is ... type X2 is ... procedure Op1 (A : X1); procedure Op2 (B : X2; C : X1'Class); procedure Op3 (D : X1; E : X2'Class); ... private type X1 is ... type X2 is ... It cannot be reordered without a complicated system of forward incomplete declarations which in the end would dilute the very idea of having type and operations declared in one place, with brackets put around the place. (Because the idea is based on a wrong concept) And of course, there would be no way to derive privately from a more specific type: type Q is new T with private; private type Q is new S with ...; -- S <: T -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 21:51 ` Dmitry A. Kazakov @ 2015-07-21 22:55 ` Jeffrey R. Carter 2015-07-22 7:26 ` Dmitry A. Kazakov 2015-07-22 7:01 ` Simon Wright 1 sibling, 1 reply; 168+ messages in thread From: Jeffrey R. Carter @ 2015-07-21 22:55 UTC (permalink / raw) On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote: > On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>> Operations do not belong to types. >> >> Huh? > > function "*" (X : Matrix; Y : Vector) return Vector; > > To which type does "*" belong? A concept of programming by extension is that operations on extensible types do belong to a type. In Ada terms, the operation belongs to the type of the "controlling parameter". In many languages, the operation is contained in the type declaration as in the suggested syntax, and the controlling parameter is implicit. Since you seem to think that every type should be extensible and all programming should be by extension, I'd think this concept would be ingrained with you. -- Jeff Carter "I didn't squawk about the steak, dear. I merely said I didn't see that old horse that used to be tethered outside here." Never Give a Sucker an Even Break 103 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 22:55 ` Jeffrey R. Carter @ 2015-07-22 7:26 ` Dmitry A. Kazakov 2015-07-22 9:05 ` Mart van de Wege 0 siblings, 1 reply; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-22 7:26 UTC (permalink / raw) On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote: > On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote: >> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>>> >>>> Operations do not belong to types. >>> >>> Huh? >> >> function "*" (X : Matrix; Y : Vector) return Vector; >> >> To which type does "*" belong? > > A concept of programming by extension is that operations on extensible types do > belong to a type. Why? Anyway, that does not answer the question. To which type belongs multiplication? > Since you seem to think that every type should be extensible Yes, or shrinkable, or exchangeable. The representation of the type values is an implementation detail. And, from the strong typing POV the value of another type is of another type no matter how you obtained that value. > and all programming should be by extension, Not at all. Programming shall not be focused on the representation of values. > I'd think this concept would be ingrained with you. On the contrary. I don't share this traditional flawed concept that the only classes are ones obtained per extension. That indeed leads to the idea of "true" types/classes and not-so-types, with operations of "true" types belonging to them, and other operations not deserving much attention, well, anything that does not fit the concept, does not exist, right? Ada 83 already had classes of constrained subtypes, like String and String (n..m), like Integer and Positive, like array and its slice etc. They share operations. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 7:26 ` Dmitry A. Kazakov @ 2015-07-22 9:05 ` Mart van de Wege 2015-07-22 10:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 168+ messages in thread From: Mart van de Wege @ 2015-07-22 9:05 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote: > >> On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote: >>> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote: >>> >>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>>>> >>>>> Operations do not belong to types. >>>> >>>> Huh? >>> >>> function "*" (X : Matrix; Y : Vector) return Vector; >>> >>> To which type does "*" belong? >> >> A concept of programming by extension is that operations on extensible types do >> belong to a type. > > Why? > > Anyway, that does not answer the question. To which type belongs > multiplication? > I'd say it's a multimethod, being dispatched on all its parameters, not a member of a type. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 9:05 ` Mart van de Wege @ 2015-07-22 10:27 ` Dmitry A. Kazakov 0 siblings, 0 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-22 10:27 UTC (permalink / raw) On Wed, 22 Jul 2015 11:05:23 +0200, Mart van de Wege wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote: >> >>> On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote: >>>> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote: >>>> >>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>>>>> >>>>>> Operations do not belong to types. >>>>> >>>>> Huh? >>>> >>>> function "*" (X : Matrix; Y : Vector) return Vector; >>>> >>>> To which type does "*" belong? >>> >>> A concept of programming by extension is that operations on extensible types do >>> belong to a type. >> >> Why? >> >> Anyway, that does not answer the question. To which type belongs >> multiplication? > > I'd say it's a multimethod, being dispatched on all its parameters, not > a member of a type. A full dispatch, assuming Matrix and Vector unrelated. Multimethod is a full dispatch with all arguments and the result restricted to the same types hierarchy, e.g. function "*" (Left, Right : Matrix) return Matrix; E.g. X : Sparse_Matrix; Y : Band_Matrix; Z : Dense_Matrix; Z := X * Y; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 21:51 ` Dmitry A. Kazakov 2015-07-21 22:55 ` Jeffrey R. Carter @ 2015-07-22 7:01 ` Simon Wright 2015-07-22 7:35 ` Dmitry A. Kazakov 1 sibling, 1 reply; 168+ messages in thread From: Simon Wright @ 2015-07-22 7:01 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > The object's private part should not appear in the package's public > part. It is a privacy breach. To the eye, yes, but not to using software. If I can look at the overall spec, I can see the private part anyway. More to the point, devolving the private part of a protected type to the private part of the enclosing package spec would resolve a lot of declaration ordering problems; types that could otherwise go in the private part of the package have to be in the public part. That's somewhat related to the need for the Implementation package in the Synchronized_Queues. There'd have been no need if we could have said something like protected type Queue ... is new Queue_Interfaces.Queue with ... end Queue with private; (rather a lot of 'with's there!) ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 7:01 ` Simon Wright @ 2015-07-22 7:35 ` Dmitry A. Kazakov 2015-07-27 23:02 ` Randy Brukardt 0 siblings, 1 reply; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-22 7:35 UTC (permalink / raw) On Wed, 22 Jul 2015 08:01:03 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> The object's private part should not appear in the package's public >> part. It is a privacy breach. > > To the eye, yes, but not to using software. If I can look at the overall > spec, I can see the private part anyway. You can see bodies as well. What not to eliminate bodies and pack all the code right at the declaration point? > More to the point, devolving the private part of a protected type to the > private part of the enclosing package spec would resolve a lot of > declaration ordering problems; Is it an argument for or against it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 7:35 ` Dmitry A. Kazakov @ 2015-07-27 23:02 ` Randy Brukardt 0 siblings, 0 replies; 168+ messages in thread From: Randy Brukardt @ 2015-07-27 23:02 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:wubr7sju24uf.1emgiu7iypp5l.dlg@40tude.net... > On Wed, 22 Jul 2015 08:01:03 +0100, Simon Wright wrote: ... >> To the eye, yes, but not to using software. If I can look at the overall >> spec, I can see the private part anyway. > > You can see bodies as well. What not to eliminate bodies and pack all the > code right at the declaration point? <sarcasm>Why not? That's what Java does, and obviously it's better than Ada because it uses curly brackets. </sarcasm> Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 21:06 ` Simon Wright 2015-07-21 21:51 ` Dmitry A. Kazakov @ 2015-07-27 22:44 ` Randy Brukardt 2015-07-28 7:30 ` Simon Wright 1 sibling, 1 reply; 168+ messages in thread From: Randy Brukardt @ 2015-07-27 22:44 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:lyegk1jk41.fsf@pushface.org... ... >> Why repeating this flawed syntax for classes? It is again about >> fundamentals, privacy is not a type property. It is of a module. > > Well, as far as I can see protected types, tasks and (in this > not-to-be-taken-seriously proposal) classes are modules, in a way. Why use "sort-of modules" when Ada already has strong, well-designed modules? That's the main argument given by the Ada 9x team, and I for one have a hard time arguing that. Languages with the "class = module" property never had any modules in the first place. They confused the benefits of modules with the (smaller) benefits of O-O. And so on. (If all you have is a hammer, everything looks like a nail...) Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-27 22:44 ` Randy Brukardt @ 2015-07-28 7:30 ` Simon Wright 2015-07-28 20:39 ` Randy Brukardt 0 siblings, 1 reply; 168+ messages in thread From: Simon Wright @ 2015-07-28 7:30 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Simon Wright" <simon@pushface.org> wrote in message > news:lyegk1jk41.fsf@pushface.org... > ... >>> Why repeating this flawed syntax for classes? It is again about >>> fundamentals, privacy is not a type property. It is of a module. >> >> Well, as far as I can see protected types, tasks and (in this >> not-to-be-taken-seriously proposal) classes are modules, in a way. > > Why use "sort-of modules" when Ada already has strong, well-designed > modules? That's the main argument given by the Ada 9x team, and I for > one have a hard time arguing that. What I meant was that protected types, in particular, already have private parts which are textually, but not programmatically, visible in the public part of packages. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 7:30 ` Simon Wright @ 2015-07-28 20:39 ` Randy Brukardt 2015-07-29 7:12 ` Simon Wright 0 siblings, 1 reply; 168+ messages in thread From: Randy Brukardt @ 2015-07-28 20:39 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:ly1tfszqlf.fsf@pushface.org... > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> "Simon Wright" <simon@pushface.org> wrote in message >> news:lyegk1jk41.fsf@pushface.org... >> ... >>>> Why repeating this flawed syntax for classes? It is again about >>>> fundamentals, privacy is not a type property. It is of a module. >>> >>> Well, as far as I can see protected types, tasks and (in this >>> not-to-be-taken-seriously proposal) classes are modules, in a way. >> >> Why use "sort-of modules" when Ada already has strong, well-designed >> modules? That's the main argument given by the Ada 9x team, and I for >> one have a hard time arguing that. > > What I meant was that protected types, in particular, already have > private parts which are textually, but not programmatically, visible in > the public part of packages. Protected types were intended to look like tasks, and they're clearly a bad design in the sense that they don't mesh well with the existing powerful modularity features. (The subpackage Implementation in the queue containers is exhibit A of that.) Adding a "class type" with similar syntax would have caused the same disaster, only worse. (Ada does *not* allow nested types, thus it would be impossible to encapsulate related types like enumerations and to a lesser extent access types [lesser only because of anonymous access, but that's another mistake -- sometimes two wrongs do make a right - ;-)]. It would be very hard to allow nested types in general [I looked extensively at allowing some kinds of types in the private part of a protected type, and it would work so long as it was quite limited and none of the types was ever visible - still a lot weaker solution than an Ada package]. Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-28 20:39 ` Randy Brukardt @ 2015-07-29 7:12 ` Simon Wright 2015-07-29 11:11 ` vincent.diemunsch 2015-07-29 19:31 ` Randy Brukardt 0 siblings, 2 replies; 168+ messages in thread From: Simon Wright @ 2015-07-29 7:12 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > (The subpackage Implementation in the queue containers is exhibit A of > that.) I seem to remember that Martin Dowie and I had some input into this practical but warty solution! (or "hack", I suppose) Was there some reason why we don't have - for example - protected type P is -- publicly visible subprograms end P with private; and the private part of P declared in the private part of the package? protected type P is -- publicly visible subprograms private -- etc, as now end P; ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 7:12 ` Simon Wright @ 2015-07-29 11:11 ` vincent.diemunsch 2015-07-29 19:31 ` Randy Brukardt 1 sibling, 0 replies; 168+ messages in thread From: vincent.diemunsch @ 2015-07-29 11:11 UTC (permalink / raw) Le mercredi 29 juillet 2015 09:11:47 UTC+2, Simon Wright a écrit : > Was there some reason why we don't have - for example - > > protected type P is > -- publicly visible subprograms > end P with private; > > and the private part of P declared in the private part of the package? > > protected type P is > -- publicly visible subprograms > private > -- etc, as now > end P; or in the private part : for protected type P use record -- etc, as now end record; then in the body exactly the same as what we have. Vincent ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-29 7:12 ` Simon Wright 2015-07-29 11:11 ` vincent.diemunsch @ 2015-07-29 19:31 ` Randy Brukardt 1 sibling, 0 replies; 168+ messages in thread From: Randy Brukardt @ 2015-07-29 19:31 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:lyoaivxwr8.fsf@pushface.org... > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> (The subpackage Implementation in the queue containers is exhibit A of >> that.) > > I seem to remember that Martin Dowie and I had some input into this > practical but warty solution! (or "hack", I suppose) > > Was there some reason why we don't have - for example - > > protected type P is > -- publicly visible subprograms > end P with private; > > and the private part of P declared in the private part of the package? > > protected type P is > -- publicly visible subprograms > private > -- etc, as now > end P; I don't think it was ever considered. One of the advantages of the current scheme (from a language definition perspective, obviously not from a usage perspective) is that everything is available in one place, so the nasty problems of when is something available don't come up. Getting that right for a separated private part would be tricky. There have been occassional proposals to let the private part of a package be compiled separately; that's relatively easy to accomplish within the GNAT compilation model (which doesn't generate anything for package specification anyway) but would be an earthquake for a library-based model where code is generated for every unit. This idea would seem to suffer from similar issues unless it was limited only to package specifications (which seems clunky). Anyway, it might make sense to propose something -- the problem of hiding types to be used in the implementation of a protected type is not going to go away. Randy. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 19:51 ` Dmitry A. Kazakov 2015-07-21 21:06 ` Simon Wright @ 2015-07-22 12:53 ` Vincent 2015-07-22 13:59 ` Dmitry A. Kazakov 1 sibling, 1 reply; 168+ messages in thread From: Vincent @ 2015-07-22 12:53 UTC (permalink / raw) Le mardi 21 juillet 2015 21:51:39 UTC+2, Dmitry A. Kazakov a écrit : > On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote: > > > Niklas Holsti writes: > > > >> On 15-07-21 19:24 , David Botton wrote: > >>>> if you checked the status of Modula-2 R10? > >>>> (https://bitbucket.org/trijezdci/m2r10) > >>> > >>> My hobby interest for the front end is about Ada (perhaps fixing the > >>> OO syntax, but still Ada). > >> > >> If you remove "tagged", as you said in another post, in my opinion it > >> is no longer Ada (post 95). > > > > abstract class type A is > > procedure P1 (This : in out T) is abstract; > > end A; > > > > class type T is new A with > > overriding procedure P1 (This : in out A); > > not overriding function F1 (This : A) return Integer; > > private > > V : Integer; > > end T; > > > > etc etc; not a million miles from Ada as we know it. > > Conceptually it is. Operations do not belong to types. But ARM, says : --- 3.2 Types and Subtypes Static Semantics 1 A type is characterized by a set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. An object of a given type is a run-time entity that contains (has) a value of the type. ---- So for me a type has both a set of values and a set of primitive operations. A class type is simply a handler, an access or an interface, whatever one calls it, to a class of types where each actual type has at least all of the primitive operations of the class. Therefore, I find the above syntax of Simon not completely irrelevant, to say the least :-). > > Then everybody agreed that the syntax of protected objects was a mistake. > Why repeating this flawed syntax for classes? It is again about > fundamentals, privacy is not a type property. It is of a module. Who said that ? Regards, Vincent ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 12:53 ` Vincent @ 2015-07-22 13:59 ` Dmitry A. Kazakov 0 siblings, 0 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-22 13:59 UTC (permalink / raw) On Wed, 22 Jul 2015 05:53:05 -0700 (PDT), Vincent wrote: > So for me a type has both a set of values and a set of primitive operations. Set of *all* operations defined on. That still does not make operations belong to any type. An operation may take number of types. > A class type is simply a handler, an access or an interface, whatever one > calls it, Class type T'Class is the type representing values of all types derived from T. It is not a handler, not an access, not an interface, just a type. >> Then everybody agreed that the syntax of protected objects was a mistake. >> Why repeating this flawed syntax for classes? It is again about >> fundamentals, privacy is not a type property. It is of a module. > > Who said that ? I explained in other subthread. It breaks privacy and its syntax is irregular. It should have been kind of: type T is protected private; type T is protected record ... and surely one should be able to derive from it or add the "protected" aspect later to a non-protected type. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 18:51 ` Simon Wright 2015-07-21 19:36 ` David Botton 2015-07-21 19:51 ` Dmitry A. Kazakov @ 2015-07-21 20:05 ` J-P. Rosen 2015-07-21 21:02 ` Simon Wright ` (2 more replies) 2 siblings, 3 replies; 168+ messages in thread From: J-P. Rosen @ 2015-07-21 20:05 UTC (permalink / raw) Le 21/07/2015 20:51, Simon Wright a écrit : > abstract class type A is > procedure P1 (This : in out T) is abstract; > end A; > > class type T is new A with > overriding procedure P1 (This : in out A); > not overriding function F1 (This : A) return Integer; > private > V : Integer; > end T; > > etc etc; not a million miles from Ada as we know it. And how would you make the difference between specific and class-wide types? (A huge advantage of Ada over other OO models, IMHO) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 20:05 ` J-P. Rosen @ 2015-07-21 21:02 ` Simon Wright 2015-07-21 23:40 ` Shark8 2015-07-22 12:58 ` vincent.diemunsch 2 siblings, 0 replies; 168+ messages in thread From: Simon Wright @ 2015-07-21 21:02 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > Le 21/07/2015 20:51, Simon Wright a écrit : >> abstract class type A is >> procedure P1 (This : in out T) is abstract; >> end A; >> >> class type T is new A with >> overriding procedure P1 (This : in out A); >> not overriding function F1 (This : A) return Integer; >> private >> V : Integer; >> end T; >> >> etc etc; not a million miles from Ada as we know it. > And how would you make the difference between specific and class-wide > types? (A huge advantage of Ada over other OO models, IMHO) I have no idea, and I don't want to; just that someone said that dropping the word 'tagged' would make the language not Ada. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 20:05 ` J-P. Rosen 2015-07-21 21:02 ` Simon Wright @ 2015-07-21 23:40 ` Shark8 2015-07-22 12:58 ` vincent.diemunsch 2 siblings, 0 replies; 168+ messages in thread From: Shark8 @ 2015-07-21 23:40 UTC (permalink / raw) On Tuesday, July 21, 2015 at 2:05:53 PM UTC-6, J-P. Rosen wrote: > > And how would you make the difference between specific and class-wide > types? (A huge advantage of Ada over other OO models, IMHO) Good question. One of the things that other OO-models get wrong is to shove everything into 'class' thus ignoring the fact the type is NOT the hierarchy-of-types rooted at that type. (ie. implicit conversion down that hierarchy.) Though I don't see why the proposal couldn't use the 'Class attribute to do that, the bigger problem [IMO] is that by calling this a "class type" you are blurring the lines between that hierarchy and the actual type. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 20:05 ` J-P. Rosen 2015-07-21 21:02 ` Simon Wright 2015-07-21 23:40 ` Shark8 @ 2015-07-22 12:58 ` vincent.diemunsch 2015-07-22 13:40 ` J-P. Rosen 2 siblings, 1 reply; 168+ messages in thread From: vincent.diemunsch @ 2015-07-22 12:58 UTC (permalink / raw) Le mardi 21 juillet 2015 22:05:53 UTC+2, J-P. Rosen a écrit : > Le 21/07/2015 20:51, Simon Wright a écrit : > > abstract class type A is > > procedure P1 (This : in out T) is abstract; > > end A; > > > > class type T is new A with > > overriding procedure P1 (This : in out A); > > not overriding function F1 (This : A) return Integer; > > private > > V : Integer; > > end T; > > > > etc etc; not a million miles from Ada as we know it. > And how would you make the difference between specific and class-wide > types? (A huge advantage of Ada over other OO models, IMHO) > > -- > J-P. Rosen > Adalog > 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX > Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 > http://www.adalog.fr Hello Jean-Pierre, Simply by declaring an operation OUTSIDE the class type declaration as : Procedure Class_Wide_Operation (Object : in out T, X : integer); Only primitive operations are in the class type declaration. This is very intuitive since you can in a way "see" the dispatch table associated to the record. Regards, Vincent ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 12:58 ` vincent.diemunsch @ 2015-07-22 13:40 ` J-P. Rosen 2015-07-22 14:29 ` Vincent 0 siblings, 1 reply; 168+ messages in thread From: J-P. Rosen @ 2015-07-22 13:40 UTC (permalink / raw) Le 22/07/2015 14:58, vincent.diemunsch@gmail.com a écrit : > Simply by declaring an operation OUTSIDE the class type declaration > as : > > Procedure Class_Wide_Operation (Object : in out T, X : integer); > > Only primitive operations are in the class type declaration. This is > very intuitive since you can in a way "see" the dispatch table > associated to the record. No, that won't do it. You may want to define operations (that are not methods) for a specific type, or for the class-wide type rooted at the specific type. I don't think you can avoit the 'Class, which basically brings us to the current solution (where you write "package ... is" instead of "class ... is") -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-22 13:40 ` J-P. Rosen @ 2015-07-22 14:29 ` Vincent 0 siblings, 0 replies; 168+ messages in thread From: Vincent @ 2015-07-22 14:29 UTC (permalink / raw) Le mercredi 22 juillet 2015 15:40:08 UTC+2, J-P. Rosen a écrit : > You may want to define operations (that are not methods) for a specific > type, or for the class-wide type rooted at the specific type. > I don't think you can avoit the 'Class, which basically > brings us to the current solution (where you write "package ... is" > instead of "class ... is") It simply takes the opposite view : instead of having a tagged type in Ada and the need to add the 'Class to speak of the whole class derived from it, you have the class type that represents any member of the class (as T'Class) and you need to have something like CT'Root_Type. Regards, Vincent > -- > J-P. Rosen > Adalog > 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX > Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 > http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-21 17:29 ` Niklas Holsti 2015-07-21 18:51 ` Simon Wright @ 2015-07-21 19:30 ` David Botton 1 sibling, 0 replies; 168+ messages in thread From: David Botton @ 2015-07-21 19:30 UTC (permalink / raw) > If you remove "tagged", as you said in another post, in my opinion it is > no longer Ada (post 95). It certainly would not be backward compatible at least with that feature to Ada '95. As for the name Ada, even that is a question of worth, the name (in particular in the US) has been burned (mandate, licenses, etc.) and is a marketing fiasco for the most part. If I ever did go through with all the work to complete a new compiler, I'd really have to think about how closely I'd want to associate with the name Ada anyways. (Although obviously the base language is good stuff). David Botton ^ permalink raw reply [flat|nested] 168+ messages in thread
[parent not found: <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com>]
* Re: If not Ada, what else... [not found] ` <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com> @ 2015-08-21 5:21 ` Shark8 2015-08-21 17:39 ` David Botton 1 sibling, 0 replies; 168+ messages in thread From: Shark8 @ 2015-08-21 5:21 UTC (permalink / raw) On Thursday, August 20, 2015 at 10:40:50 PM UTC-6, polymorph self wrote: > > CAn ada hang with lisp and haskell as far as abstraction and programming in the large? For programming in the large, Ada is *REALLY* good -- as an example the YF-22 software consisted of 12 major avionics subsystems, across 650 modules, and 8 geographically separated contractors... and the integration took only 3 days. There was a video on youtube of a Symbolics Ada [Ada implemented in Lisp] which. I think, would be really interesting for you. Unfortunately the video has been made private,, though Ada is mentioned on wikipeda here: https://en.wikipedia.org/wiki/Genera_%28operating_system%29#Other_languages_from_Symbolics YouTube link, in case it ever becomes non-private: https://www.youtube.com/watch?v=r7hD_Ro75zo&feature=youtu.be ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... [not found] ` <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com> 2015-08-21 5:21 ` Shark8 @ 2015-08-21 17:39 ` David Botton 1 sibling, 0 replies; 168+ messages in thread From: David Botton @ 2015-08-21 17:39 UTC (permalink / raw) > CAn ada hang with lisp and haskell as far as abstraction and programming in the large? You are joking right. I wouldn't consider anything but Ada for programming in the large, certainly not lisp or haskell which have their place in the system at times. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 19:10 ` David Botton 2015-07-10 19:43 ` Patrick Noffke @ 2015-07-11 2:31 ` Paul Rubin 2015-07-11 6:00 ` J-P. Rosen ` (2 more replies) 1 sibling, 3 replies; 168+ messages in thread From: Paul Rubin @ 2015-07-11 2:31 UTC (permalink / raw) David Botton <david@botton.com> writes: >> I was aware of SPARK before that, when it was a separate expensive tool > So now an expensive vendor tool is still an expensive vendor tool But now there's a free version of SPARK, a big change. > We are talking about Ada not SPARK. If you like SPARK and it fits your > needs great. Well, I'm thinking of SPARK as a component of Ada-2012. Maybe that's not exactly right but there's some conceptual sense to it. > So in C++ you can create new incompatible types with various ranges, > use them for array indexes, true enums? I'm no C++ expert but I believe it has real enums (i.e. typed), unlike C enums. And since you can overload the [] operator and use whatever you want as indexes, making incompatible range types and using them as indexes is straightforward though a bit cumbersome. It wouldn't surprise me if there's a package for it (using templates) already. > That is what you don't understand, Ada is about compile time checks > and that comes with contacts. Contracts on the types, contracts on the > interfaces. Historically AFAIK range types in Ada were not statically checked. Checking them is very complicated and can be partly automated these days with SMT solvers, but in general you'd need proof assistants and lots of manual effort. Are we talking about the same thing? > Well, once upon a time Ada compilers were certified. I don't believe > AdaCore does that anymore. There was some federal agency that did it, I thought. It was eventually shut down after it had served its purpose, which was getting standardization to really mean something. > And if you use Ada long enough you learn to use the Stack most of the > time to accomplish the same thing and you don't get sloppy which tends > to happen to GC dependent programmers. This is no different from C++. The usefulness of GC depends on what kinds of programs you're writing, so it's true, lots of code doesn't need it, but for some, it's great. C++ programs these days use reference counted smart pointers, which are a poor man's GC. > Ada does have a GC in some implementations as I pointed out. You are > having trouble separating language from runtime environment. A GC in > Ada or D is something you can choose to use. Yes, I'm just not sure why to use a GC in Ada. If you can afford a GC's overhead and accept the non-determinism it creates, why use Ada in the first place, instead of something like Haskell? I guess there might be some situations. But I mostly find Ada attractive for exactly the problems in which GC is unattractive or unfeasible. > BTW, I've never had the need but there are ways to use a GC even the > current GNAT's on most platforms. That's interesting and I'll look into it. >> GC'd languages that support functional-programming idioms > You can use D in that environment, although Ada is better at it. Repl > clauses, etc. are also pluses. Not sure what a repl clause is. Ada doesn't support FP style very well, which is fine because that was never its goal. >> I consider [C and C++] ... to be niche languages > No still general purpose. You need to look at the language itself to > make that determination not just how it is being used currently. I'd say you have to look at the problems people are trying to solve, and the technology available for solving them. These days most programming is done on very powerful, underutilized cpus with tons of memory compared to the problem, so GC'd languages are generally the most productive approach for those applications. > C and C++ are still heavily used in general use cases, from embedded > to UI and Game Dev, etc. Embedded is a niche, UI should be done in other languages these days, and game dev is somewhat special because it's often realtime. One of the most successful games (Minecraft) was written in Java though, lots of games use a combination of C++ and Lua, and there's this: https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf > If anything C#, Python, Java are more niche, just their niche is where > the vast majority of programs and programmers are. You would be a fool > to use any of the three in anything critical (safety, time, etc.) If the vast majority of programs and programmers are in a particular place, then that place is by definition mainstream and not a niche ;-). Only a few programmers are doing safety or time critical things, so THAT is a niche. But, an awful lot of mainstream programs and programmers now are doing internet applications, which brings security concerns that make unsafe languages like C problematic. Ada might be ok if you leave all the runtime checks enabled, though there's still a productivity issue. There's also no implementation that I know of with lightweight multitasking like Go, so that cramps you if you want to run high-concurrency servers. > Even Haskell, OCAML, etc. are fairly niche. All the scripting > languages are niche. Scripting is mainstream in that it's how most stuff is being written. Haskell and Ocaml are niche because while they have fairly broad applicability, there's not much of a userbase and it's not clear that Haskell has significant advantages for the typical CRUD app (Ocaml might make more sense). Or if you want something really "out there", http://www.impredicative.com/ur/ might be of interest. > Ada, D, C, C++ are all geared for full range dev across the entire > spectrum. Ada due to external issues in tool and compiler availability > is the more limited currently, but almost as broad. Just because you CAN write something in Ada, D, C, C++, Forth, Assembler etc. (those languages can all do pretty much anything) doesn't mean that there's not a more effective alternative in a particular area. What I'd say is those languages are most effective in areas that are (as of 2015) somewhat specialized in the way I see things. Full range devs should be able to use them when the task calls for it, but most tasks these days probably don't. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 2:31 ` Paul Rubin @ 2015-07-11 6:00 ` J-P. Rosen 2015-07-11 7:51 ` Georg Bauhaus 2015-07-21 1:34 ` Luke A. Guest 2 siblings, 0 replies; 168+ messages in thread From: J-P. Rosen @ 2015-07-11 6:00 UTC (permalink / raw) Le 11/07/2015 04:31, Paul Rubin a écrit : >> Well, once upon a time Ada compilers were certified. I don't believe >> > AdaCore does that anymore. > There was some federal agency that did it, I thought. It was eventually > shut down after it had served its purpose, which was getting > standardization to really mean something. > You are confusing two different things here. The AJPO (Ada Joint Program Office) was a government agency established to start and develop the language. It was closed when the language was considered grown up. It was not in charge of validation. There is a an organization, the ACAA (Ada Conformity Assesment Authority) in charge of validation, whose "technical agent" is Randy Bruckardt, and an ACAL (Ada Compiler Assesment Laboratory), currently Adalog, in charge of doing the validations. So the whole structure is in place if a vendor asks to validate its compiler. What happens is that since the major customers don't require validated compilers any more, and since validation is quite expensive, nobody does it anymore. But if a big customer of AdaCore said they would sign the contract only if the compiler is officially validated, I'm sure AdaCore would do it. There is also a kind of side effect of validation: it is so much connected to the Ada spirit that every compiler keeps passing the validation internally, and all the users know that the compiler is passing the validation internally - therefore reducing the need for official validation. AdaCore even provides a certificate of "internal validation" without official value, but good enough for most customers. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 2:31 ` Paul Rubin 2015-07-11 6:00 ` J-P. Rosen @ 2015-07-11 7:51 ` Georg Bauhaus 2015-07-11 8:47 ` Dmitry A. Kazakov 2015-07-21 1:34 ` Luke A. Guest 2 siblings, 1 reply; 168+ messages in thread From: Georg Bauhaus @ 2015-07-11 7:51 UTC (permalink / raw) On 11.07.15 04:31, Paul Rubin wrote: > Historically AFAIK range types in Ada were not statically checked. > Checking them is very complicated and can be partly automated these days > with SMT solvers, but in general you'd need proof assistants and lots of > manual effort. The expressly bounded, named types of Ada to me are fundamental to sorting things out. In many ways, for example: how could one find a function from integers into integers to be from N -> {0, 1, ..., 10}, actually, if there was no better way to specify the set of values in a type than by saying "int"? Knowing more about the sets continues transitively, and this knowledge is reflected in the definitions of user defined fundamental types (with ranges etc.). They also match the problem description. In C, when a function returns negative, this typically means one of the known errors, or about |0 - INT_MIN| possible cases of overflow or worse. How do we learn about the image that the function was supposed to compute? Read comments? Studying the full source? The existence, and perhaps proliferation of fusion into Haskell programs OTOH turns them into mathematical riddles. I wonder if that's just what fans of Haskell might like doing? Turning some simple Haskell equations into fusioned somethings for reasons of *controlling* performance in time vs space, which, IIUC, were not part of Haskell's design. They are not an integral part of its expressive apparatus. (Sadly.) So we get to see efficient manipulations of data in Haskell using all kinds of primitives and strict so that code looks just like some kind of new, operation- oriented assembly language, using a fancy equational machine. > Embedded is a niche, I understand that embedded covers about half of the market of all things that have computers in them. I don't know whether that's money-wise or installation-wise. Perhaps awareness isn't half, too. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 7:51 ` Georg Bauhaus @ 2015-07-11 8:47 ` Dmitry A. Kazakov 0 siblings, 0 replies; 168+ messages in thread From: Dmitry A. Kazakov @ 2015-07-11 8:47 UTC (permalink / raw) On Sat, 11 Jul 2015 09:51:07 +0200, Georg Bauhaus wrote: > On 11.07.15 04:31, Paul Rubin wrote: > >> Historically AFAIK range types in Ada were not statically checked. >> Checking them is very complicated and can be partly automated these days >> with SMT solvers, but in general you'd need proof assistants and lots of >> manual effort. > > The expressly bounded, named types of Ada to me are fundamental to sorting > things out. In many ways, for example: how could one find a function > from integers into integers to be from N -> {0, 1, ..., 10}, actually, > if there was no better way to specify the set of values in a type than > by saying "int"? Knowing more about the sets continues transitively, and > this knowledge is reflected in the definitions of user defined fundamental > types (with ranges etc.). Partially. Ada 83 didn't make it fully static, because it disregarded operations. It is not enough to declare a range or, more generally, the set of values to define a type. Because type includes operations. E.g. the numbers 1..10 may not have unary minus, as they don't have inverses. What Ada 83 did to resolve the problem was less typing. It relaxed contracts to uphold them. Constraint_Error was added to the contracts of all operations. Ada simplified issues with intermediate results by making them of the base type (C used type promotion for this). This was a compromise, but compromises never win. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-11 2:31 ` Paul Rubin 2015-07-11 6:00 ` J-P. Rosen 2015-07-11 7:51 ` Georg Bauhaus @ 2015-07-21 1:34 ` Luke A. Guest 2 siblings, 0 replies; 168+ messages in thread From: Luke A. Guest @ 2015-07-21 1:34 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: >> C and C++ are still heavily used in general use cases, from embedded >> to UI and Game Dev, etc. > > Embedded is a niche, UI should be done in other languages these days, > and game dev is somewhat special because it's often realtime. One of > the most successful games (Minecraft) was written in Java though, lots > of games use a combination of C++ and Lua, and there's this: > https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf I happen to believe that Ada is perfect for games. I'm producing the current SDL2 bindings. I have a GL generator that just needs to generate the GL bindings now. I will be binding Vulkan once it's out and I have a project in mind to prove my ideas. Luke ^ permalink raw reply [flat|nested] 168+ messages in thread
* Assertions in SPARK (Was: If not Ada, what else...) 2015-07-10 18:22 ` Paul Rubin 2015-07-10 19:10 ` David Botton @ 2015-07-27 9:09 ` Jacob Sparre Andersen 2015-07-27 10:56 ` G.B. 1 sibling, 1 reply; 168+ messages in thread From: Jacob Sparre Andersen @ 2015-07-27 9:09 UTC (permalink / raw) Paul Rubin wrote: > I remember being disappointed that (unless I missed something) there > doesn't seem to be a way to put assertions in the middle of a function > body and have Spark check them statically. Am I mistaken about that? You are. I don't have a SPARK book right here, but IIRC it is simply: --# assert <expression> Greetings, Jacob -- »Great minds discuss ideas, Average minds discuss events, Small minds discuss people.« ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Assertions in SPARK (Was: If not Ada, what else...) 2015-07-27 9:09 ` Assertions in SPARK (Was: If not Ada, what else...) Jacob Sparre Andersen @ 2015-07-27 10:56 ` G.B. 2015-07-27 21:59 ` Peter Chapin 0 siblings, 1 reply; 168+ messages in thread From: G.B. @ 2015-07-27 10:56 UTC (permalink / raw) On 27.07.15 11:09, Jacob Sparre Andersen wrote: > Paul Rubin wrote: > >> I remember being disappointed that (unless I missed something) there >> doesn't seem to be a way to put assertions in the middle of a function >> body and have Spark check them statically. Am I mistaken about that? > > You are. I don't have a SPARK book right here, but IIRC it is simply: > > --# assert <expression> Also worth considering is --# check <expression> which is different from assert in that is doesn't change SPARK's mind about where the interesting points in the paths are. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Assertions in SPARK (Was: If not Ada, what else...) 2015-07-27 10:56 ` G.B. @ 2015-07-27 21:59 ` Peter Chapin 0 siblings, 0 replies; 168+ messages in thread From: Peter Chapin @ 2015-07-27 21:59 UTC (permalink / raw) On Mon, 27 Jul 2015, G.B. wrote: >>> I remember being disappointed that (unless I missed something) there >>> doesn't seem to be a way to put assertions in the middle of a function >>> body and have Spark check them statically. Am I mistaken about that? >> >> You are. I don't have a SPARK book right here, but IIRC it is simply: >> >> --# assert <expression> > > Also worth considering is > > --# check <expression> > > which is different from assert in that is doesn't change SPARK's mind > about where the interesting points in the paths are. The SPARK2014 version of these constructions are pragma Assert (similar to the check annotation) and pragma Assert_And_Cut (similar to the assert annotation). They are checked statically by the SPARK proof tools. Peter ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: If not Ada, what else... 2015-07-10 4:26 ` Paul Rubin 2015-07-10 15:01 ` David Botton @ 2015-07-11 11:10 ` Pascal Obry 1 sibling, 0 replies; 168+ messages in thread From: Pascal Obry @ 2015-07-11 11:10 UTC (permalink / raw) Le jeudi 09 juillet 2015 à 21:26 -0700, Paul Rubin a écrit : > David Botton <david@botton.com> writes: > > You could say that about every version even the first. > > Well, the big win of Ada 2012 is SPARK integration, it seems to me. Agreed. In some applications I have been able to replace comments by pre/post condition. Far better to me and then checked at runtime. For example relationship between 2 routines parameters (if A is True then B cannot be zero) can be expressed by a pre condition. This is really going in the right direction to me. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 168+ messages in thread
end of thread, other threads:[~2015-08-23 23:01 UTC | newest] Thread overview: 168+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-04-20 10:39 If not Ada, what else Alex R. Mosteo 2011-04-20 10:51 ` Ludovic Brenta 2011-04-21 8:47 ` Alex R. Mosteo 2011-04-20 11:53 ` Maciej Sobczak 2011-04-21 8:46 ` Alex R. Mosteo 2011-04-23 2:08 ` Peter C. Chapin 2011-04-21 17:19 ` Robert Matthews 2011-04-21 19:02 ` Georg Bauhaus 2011-04-21 19:25 ` Florian Weimer 2011-04-22 15:50 ` Robert Matthews 2011-04-22 17:49 ` Brad Cantrell 2011-04-23 2:20 ` Peter C. Chapin 2011-04-23 9:55 ` Georg Bauhaus 2011-04-23 11:17 ` Peter C. Chapin 2011-04-22 21:39 ` Florian Weimer 2011-04-23 2:26 ` Peter C. Chapin 2011-04-23 9:52 ` björn lundin 2011-04-23 11:50 ` Piotr Trojanek 2011-04-23 12:23 ` Dmitry A. Kazakov 2011-04-23 14:30 ` Georg Bauhaus 2011-04-23 15:04 ` Dmitry A. Kazakov 2011-04-23 16:16 ` Piotr Trojanek 2011-04-28 12:55 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Alex R. Mosteo 2011-04-28 16:34 ` C++/cmake project, injecting Ada Ludovic Brenta 2011-04-29 8:17 ` Alex R. Mosteo 2011-04-29 12:45 ` stefan-lucks 2015-07-02 10:44 ` Alejandro R. Mosteo 2011-05-28 17:33 ` C++/cmake project, injecting Ada... (was Re: If not Ada, what else...) Dirk Heinrichs 2015-07-03 19:21 ` If not Ada, what else luvhed 2015-07-03 20:50 ` Paul Rubin 2015-07-04 8:19 ` Rod Kay 2015-07-08 18:11 ` jm.tarrasa 2015-07-08 20:33 ` Anh Vo 2015-07-09 6:36 ` jm.tarrasa 2015-07-08 22:15 ` David Botton 2015-07-09 7:28 ` jm.tarrasa 2015-07-09 9:54 ` G.B. 2015-07-09 12:57 ` Dennis Lee Bieber 2015-07-09 18:25 ` David Botton 2015-07-09 21:15 ` Bob Duff 2015-07-09 22:23 ` David Botton 2015-07-09 22:39 ` Paul Rubin 2015-07-10 0:20 ` David Botton 2015-07-10 4:26 ` Paul Rubin 2015-07-10 15:01 ` David Botton 2015-07-10 16:07 ` David Botton 2015-07-10 17:39 ` Bob Duff 2015-07-10 18:22 ` Paul Rubin 2015-07-10 19:10 ` David Botton 2015-07-10 19:43 ` Patrick Noffke 2015-07-11 10:46 ` Brian Drummond 2015-07-11 10:59 ` Björn Lundin 2015-07-11 13:41 ` Georg Bauhaus 2015-07-11 14:11 ` Björn Lundin 2015-07-13 14:02 ` Patrick Noffke 2015-07-13 14:16 ` David Botton 2015-07-13 14:54 ` Maciej Sobczak 2015-07-16 20:19 ` Serge Robyns 2015-07-17 1:50 ` David Botton 2015-07-17 17:07 ` Anh Vo 2015-07-17 21:28 ` Serge Robyns 2015-07-17 22:53 ` Anh Vo 2015-07-19 14:31 ` David Botton 2015-07-19 16:20 ` Paul Rubin 2015-07-19 20:55 ` Jeffrey R. Carter 2015-07-19 21:15 ` Paul Rubin 2015-07-20 16:08 ` Tero Koskinen 2015-07-20 17:31 ` Paul Rubin 2015-07-21 1:16 ` Dennis Lee Bieber 2015-07-21 3:09 ` Shark8 2015-07-21 12:46 ` Dennis Lee Bieber 2015-07-21 5:43 ` J-P. Rosen 2015-07-21 12:47 ` Dennis Lee Bieber 2015-07-21 12:55 ` J-P. Rosen 2015-07-19 22:38 ` David Botton 2015-07-21 6:30 ` Gour 2015-07-21 16:24 ` David Botton 2015-07-21 17:29 ` Niklas Holsti 2015-07-21 18:51 ` Simon Wright 2015-07-21 19:36 ` David Botton 2015-07-22 8:44 ` Pascal Obry 2015-07-22 12:00 ` Jean François Martinez 2015-07-27 22:59 ` Randy Brukardt 2015-07-28 7:00 ` Georg Bauhaus 2015-07-28 7:22 ` Paul Rubin 2015-07-28 10:36 ` darkestkhan 2015-07-28 10:58 ` G.B. 2015-07-28 20:33 ` Randy Brukardt 2015-07-28 10:40 ` darkestkhan 2015-07-29 7:30 ` Jacob Sparre Andersen 2015-07-29 8:55 ` Simon Wright 2015-07-29 12:38 ` EGarrulo 2015-07-29 13:06 ` EGarrulo 2015-07-29 15:41 ` Paul Rubin 2015-07-29 17:01 ` Björn Lundin 2015-07-29 18:27 ` Paul Rubin 2015-07-29 18:52 ` Björn Lundin 2015-07-29 22:18 ` Paul Rubin 2015-07-30 6:23 ` Dmitry A. Kazakov 2015-07-30 16:48 ` David Botton 2015-07-30 18:10 ` Randy Brukardt 2015-07-29 19:18 ` Georg Bauhaus 2015-07-29 19:42 ` Randy Brukardt 2015-07-30 4:54 ` Paul Rubin 2015-07-30 6:15 ` Niklas Holsti 2015-07-30 6:34 ` Dmitry A. Kazakov 2015-07-30 6:47 ` Paul Rubin 2015-07-30 7:20 ` Dmitry A. Kazakov 2015-07-30 23:13 ` Paul Rubin 2015-07-29 17:07 ` Stefan.Lucks 2015-07-29 17:47 ` Paul Rubin 2015-08-21 23:03 ` Waldek Hebisch 2015-08-22 3:24 ` Paul Rubin 2015-08-23 16:26 ` Waldek Hebisch 2015-08-23 17:18 ` Jeffrey R. Carter 2015-08-23 17:31 ` Waldek Hebisch 2015-08-23 19:32 ` Jeffrey R. Carter 2015-08-23 23:01 ` Waldek Hebisch 2015-07-29 19:32 ` Georg Bauhaus 2015-07-30 5:17 ` Paul Rubin 2015-07-30 7:38 ` Georg Bauhaus 2015-07-30 18:26 ` Paul Rubin 2015-07-30 18:37 ` Paul Rubin 2015-07-31 7:14 ` Georg Bauhaus 2015-07-30 10:59 ` darkestkhan 2015-08-19 22:19 ` rriehle 2015-08-19 22:58 ` Anh Vo 2015-08-19 23:32 ` rriehle 2015-08-20 1:08 ` Peter Chapin 2015-08-21 15:14 ` Anh Vo 2015-08-21 16:07 ` Anh Vo 2015-08-21 17:17 ` Patrick Noffke 2015-07-21 19:51 ` Dmitry A. Kazakov 2015-07-21 21:06 ` Simon Wright 2015-07-21 21:51 ` Dmitry A. Kazakov 2015-07-21 22:55 ` Jeffrey R. Carter 2015-07-22 7:26 ` Dmitry A. Kazakov 2015-07-22 9:05 ` Mart van de Wege 2015-07-22 10:27 ` Dmitry A. Kazakov 2015-07-22 7:01 ` Simon Wright 2015-07-22 7:35 ` Dmitry A. Kazakov 2015-07-27 23:02 ` Randy Brukardt 2015-07-27 22:44 ` Randy Brukardt 2015-07-28 7:30 ` Simon Wright 2015-07-28 20:39 ` Randy Brukardt 2015-07-29 7:12 ` Simon Wright 2015-07-29 11:11 ` vincent.diemunsch 2015-07-29 19:31 ` Randy Brukardt 2015-07-22 12:53 ` Vincent 2015-07-22 13:59 ` Dmitry A. Kazakov 2015-07-21 20:05 ` J-P. Rosen 2015-07-21 21:02 ` Simon Wright 2015-07-21 23:40 ` Shark8 2015-07-22 12:58 ` vincent.diemunsch 2015-07-22 13:40 ` J-P. Rosen 2015-07-22 14:29 ` Vincent 2015-07-21 19:30 ` David Botton [not found] ` <30336c64-ceaa-4887-adee-18cc58aef012@googlegroups.com> 2015-08-21 5:21 ` Shark8 2015-08-21 17:39 ` David Botton 2015-07-11 2:31 ` Paul Rubin 2015-07-11 6:00 ` J-P. Rosen 2015-07-11 7:51 ` Georg Bauhaus 2015-07-11 8:47 ` Dmitry A. Kazakov 2015-07-21 1:34 ` Luke A. Guest 2015-07-27 9:09 ` Assertions in SPARK (Was: If not Ada, what else...) Jacob Sparre Andersen 2015-07-27 10:56 ` G.B. 2015-07-27 21:59 ` Peter Chapin 2015-07-11 11:10 ` If not Ada, what else Pascal Obry
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox