Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[christoph.grein]

> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)

Where do you get this nonsense from? Who is "they". They say a lot of nonsense 
out there, not only about languages, about everything :-(

Ask Robert Dewar (the "father" of Gnat). He'll tell you that Ada and C will 
produce the same target code when you take care to switch off all (Ada) 
compiler-generated checks (and the source code is "comparable" of course).

The part in parentheses is to make sure you do not compare apples and oranges.

How could it be otherwise, because Ada is used for hard real-time (I've been 
using it in this realm for nearly two decades now).

From: "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de>
> >3. performance is highly important
> 
> GNAT is a front end of GNU C...

That's not true. GCC means Gnu Compiler Collection and Gnat directly compiles to 
intermediate format as does C, and not to C.

Gnat stands for Gnu Ada Translator, and Translator stands for Compiler, because 
they felt Gnac does not sound nice.

So Translator does _not_ mean: Translate first to C.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

christoph.grein@eurocopter.com wrote:
>>
>>GNAT is a front end of GNU C...
> 
> 
> That's not true. GCC means Gnu Compiler Collection and Gnat directly compiles to 
> intermediate format as does C, and not to C.
> 
O.K. but this could be semantics. "Front End" in compiler-speak can mean 
the portion of the compiler that parses the source language into some 
intermediate form. I didn't get the impression that anyone was implying 
that Gnat translated Ada into C then invoked the gcc compiler on it. If 
that was the claim - its probably a troll. ("Hey, let's go see if we can 
get those Ada guys screaming about how Gnat doesn't translate into C 
again!" :-)

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

No call for it

[Carroll-Tech]

----- Original Message -----
> Message: 10
> Date: Fri, 06 Feb 2004 16:23:38 GMT
> From: Les Cargill <lcargill@worldnet.att.net>
> Subject: Re: Announcing new scripting/prototyping language
> To: comp.lang.ada@ada-france.org
> Message-ID: <4023C090.152C7E08@worldnet.att.net>
> Content-Type: text/plain; charset=us-ascii
>
[snip]
> I've seen some fair sized 'C' and C++ projects. They are readable -
> to 'C'/C++ programmers.
>
> I'd have loved to have used Ada, but there never was much call for
> it.

I've been reading posts to this newsgroup for some time now, as well as
reading other information and I don't get the "never was much call for it"
ideal about Ada.
I'm not saying that anyone is wrong or right for saying or feeling that
there "never was much call for it"; maybe there wasn't.  I'm leaning more
toward saying "it's a conscious choice".

I tell the students that I tutor that learning some Pascal or Ada would help
them and they get scared.  I mention doing a project in Ada and everyone
looks at me like I'm out to punish myself.  To me it isn't any easier to use
C/C++, Java, Perl, Lisp or Prolog than it is to use Ada.  How is it that Ada
has this "super powerful", "super difficult", "there's not much call for it
because it's too advanced and powerful" air about it when it's just another
language?  It's like saying that the machine code spit out of an Ada
compiler has some mystical, magical properties that makes the Ada language
more difficult to use.

To me, with Ada0Y coming out, the "not much call for it" attitude is the
clich� to dismiss.  Or at least one of the things to overcome.

Just my opinion as a reader of comp.lang.ada.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

"Carroll-Tech" <andrew@carroll-tech.net> writes:

> I tell the students that I tutor that learning some Pascal or Ada
> would help them and they get scared.  I mention doing a project in
> Ada and everyone looks at me like I'm out to punish myself.  To me
> it isn't any easier to use C/C++, Java, Perl, Lisp or Prolog than it
> is to use Ada.  How is it that Ada has this "super powerful", "super
> difficult", "there's not much call for it because it's too advanced
> and powerful" air about it when it's just another language?  It's
> like saying that the machine code spit out of an Ada compiler has
> some mystical, magical properties that makes the Ada language more
> difficult to use.

I was thinking along the same lines last evening, and I came up with a
small theory that explains why so few pople can be bothered to learn
Ada.  It goes like this: There are 3 types of languages.

The first type of language says "we're going to make programming
easy".  Of course, this is a lie, because programming is inherently
difficult and no language can make it easy.  These languages fake it
by being simplistic.  Java is the most prominent member of this family
of languages; most scripting languages also fall in this category.
Beginners tend to flock to these "easy" languages and never learn
proper programming skills (like e.g. memory management.  If some Java
"guru" reads this, ask yourself this one question: how many threads
does your program have, and please justify the existence of each
thread).

The second type says "we will let you do anything, absolutely anything
you want, and the power is in the hands of the True Programmers".
Languages in this category include, among others, C and C++.  Many
people take a foolish pride in being called a True Programmer, and
therefore like these languages.  I myself once was in this category: I
would show off my skills by writing a single-line program that nobody
else could read.  But humans write bugs, and these languages don't
lend a hand finding these.  Hence the famous buffer overflows.

The third type is what I would call the "zen master" type of
languages.  They treat you like an apprentice, slapping you on the
hand each time you make a small mistake, and they scorn at you for
choosing the quick and easy path -- which leads to the Dark Side.  If
you accept their teachings, you quickly become a Master yourself.  If
you rebel against them, you will never achieve Enlightenment and will
always produce bugs.  The "zen master" languages are Pascal, Modula,
Oberon, and, master of masters, Ada.  The beauty of these languages is
that, once you are Enlightened, you can apply your wisdom to other
languages as well -- but often would prefer not to.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Rasmussen]

Ludovic Brenta wrote:
> "Carroll-Tech" <andrew@carroll-tech.net> writes:
> 
> 
>>I tell the students that I tutor that learning some Pascal or Ada
>>would help them and they get scared.  I mention doing a project in
>>Ada and everyone looks at me like I'm out to punish myself.  To me
>>it isn't any easier to use C/C++, Java, Perl, Lisp or Prolog than it
>>is to use Ada.  How is it that Ada has this "super powerful", "super
>>difficult", "there's not much call for it because it's too advanced
>>and powerful" air about it when it's just another language?  It's
>>like saying that the machine code spit out of an Ada compiler has
>>some mystical, magical properties that makes the Ada language more
>>difficult to use.
> 

I don't know. Ada rocks.

/David

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Harmon]

On 07 Feb 2004 14:00:35 +0100 in comp.lang.c++, Ludovic Brenta
<ludovic.brenta@insalien.org> was alleged to have written:
>Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java

You damned crossposting troll, there is _no_ subject on-topic in all
those newsgroups.

See the welcome message posted twice per week in comp.lang.c++ or
available at http://www.slack.net/~shiva/welcome.txt

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Ludovic Brenta wrote:

> The third type is what I would call the "zen master" type of
> languages.  They treat you like an apprentice, slapping you on the
> hand each time you make a small mistake, and they scorn at you for
> choosing the quick and easy path -- which leads to the Dark Side.  If
> you accept their teachings, you quickly become a Master yourself.  If
> you rebel against them, you will never achieve Enlightenment and will
> always produce bugs.  The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.  The beauty of these languages is
> that, once you are Enlightened, you can apply your wisdom to other
> languages as well -- but often would prefer not to.

I think you are on the right track.  When I am programming in Ada, I 
often spend most of a day coding.  If I am exhausted at the end of it, I 
will put off compiling until the next day.  Otherwise, I hand all the 
code to the compiler, and I am not surprised to be handed back dozens of 
error messages.  Fix the syntax bugs, and now I get twices as many 
semantic errors.  Kill all those and I am surprised if the test 
programs--often written between the package interface and the package 
bodies--don't run correctly.

For example, I recently finished writing a library of matrix operations 
which works with "views" that may be a submatrix of an existing matrix, 
and supports operations like Add(A,B) where the result is written in A. 
  That's a bit tricky, but the real complex one is Mult(A,B) where the 
amount of temporary storage space for two N by N matricies is N. (A 
buffer that stores one row.)

Why am I mentioning this?  After all the coding I had a bug in the Mult 
routine that the compiler didn't catch.  A wrong subscript inside a 
loop.  (Why am I doing this?  To submit as a new benchmark for SPECfp. 
All that stuff is just scaffolding for implementing Strassen's algorithm 
efficiently.)

Since I don't take what the compiler tells me personally, I love the 
ratio of a hundred to one or so between compile errors and run-time 
bugs.  Some people though look at a list of compiler error messages as 
if each one was a major failing on their part.  Me? I could proofread 
the code carefully, but it is easier to let the compiler find out where 
I typed a comma for a period, and so on. And IMHO it would be nice if 
the compiler found all the typos, not just most of them. ;-)

Could I write the same code in C, C++, or Java?  Sure.  It is just much 
easier to let the Ada compiler do the heavy lifting part of the 
debugging, so I would still write in Ada, then modify the code to match 
the C, C++, or Java syntax.  So to me, all that frequent hand-slapping 
is a major benefit.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Simon Wright]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> I think you are on the right track.  When I am programming in Ada, I
> often spend most of a day coding.  If I am exhausted at the end of it,
> I will put off compiling until the next day.  Otherwise, I hand all
> the code to the compiler, and I am not surprised to be handed back
> dozens of error messages.  Fix the syntax bugs, and now I get twices
> as many semantic errors.

I don't know if I'm just too impatient, but I much prefer to implement
each subprogram body and then compile it (they are usually separates,
so GNAT is quite happy do do this from within Glide).

If nothing else, it means that any problems with specs or
inter-package relationships appear earlier.

>                           Kill all those and I am surprised if the
> test programs--often written between the package interface and the
> package bodies--don't run correctly.

-- 
Simon Wright                               100% Ada, no bugs.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Simon Wright wrote:

> I don't know if I'm just too impatient, but I much prefer to implement
> each subprogram body and then compile it (they are usually separates,
> so GNAT is quite happy do do this from within Glide).
> 
> If nothing else, it means that any problems with specs or
> inter-package relationships appear earlier.

We all have our different styles.  I find when I have a design worked 
out I am better off "slinging" code while it is all in my head, then 
starting fresh when debugging.  However, I usually do the specs in a 
batch, compile them cleanly, then do the bodies.  Even though there are 
much fewer lines of code in the specs, they take about as much time to 
write as the package bodies.

(Incidently, I cut the distribution on this to comp.lang.ada only.)
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[MSG]

Ludovic Brenta <ludovic.brenta@insalien.org> wrote in message news:<m3isij11u4.fsf_-_@insalien.org>...

[...]

> The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.  The beauty of these languages is
> that, once you are Enlightened, you can apply your wisdom to other
> languages as well -- but often would prefer not to.


Can you do the following in Ada:

1. Write *one* bubble-sort function that will work on different 
   types given an appropriate comparison function

2. If B is a subtype of A, can you pass it to any function that 
   takes A as an argument? (covariance)

3. If B is a subtype of A, and FA and FB are functions accepting A 
   and B as arguments, can you use FA wherever FB could be used?
   (contravariance)

4. If B is a subtype of A, is list/array/vector/set/etc. of Bs a
   subtype of list/array/vector/set/etc of As? (covariance)

Unless you can show us how to do this in a way that will keep Ada a 
"safe" (third category) language you say it is, I will not believe
that it's a "master of of the masters", I'm afraid.

If you answer "yes" to any of the questions, post *compilable*
snippets: we don't want to learn Ada just to verify your claims,
we simply won't believe you.

BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't 
letting on about why Ada isn't used much at NASA any more. 
Perhaps *you* have an explanation?

MSG

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Rasmussen]

MSG wrote:
> 
> Unless you can show us how to do this in a way that will keep Ada a 
> "safe" (third category) language you say it is, I will not believe
> that it's a "master of of the masters", I'm afraid.
> 
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.
> 
> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't 
> letting on about why Ada isn't used much at NASA any more. 
> Perhaps *you* have an explanation?
> 

So you have theories about Ada, but you don't really know it? That's 
credible...

Just for the record: I am posting from comp.lang.c++.

/David

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Keith Thompson]

msg1825@yahoo.com (MSG) writes:
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.

Feel free to post compilable Ada snippets in comp.lang.ada, but please
don't cross-post to comp.lang.c, comp.lang.c++, or comp.lang.java.
The last thing any of these newsgroups needs is yet another language
flame war.  (I'm posting from comp.lang.c.)

I've redirected followups to comp.lang.ada.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[tmoran]

>4. If B is a subtype of A, is list/array/vector/set/etc. of Bs a
>   subtype of list/array/vector/set/etc of As? (covariance)
  What do you mean by a "set" being a "subtype" of another "set"?

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

Dear "MSG", I do not normally respond to people who won't tell me
their name.  Nevertheless, I found your questions interesting, so here
goes.

msg1825@yahoo.com (MSG) writes:

> Ludovic Brenta <ludovic.brenta@insalien.org> wrote...
> 
> [...]
> 
> > The "zen master" languages are Pascal, Modula,
> > Oberon, and, master of masters, Ada.  The beauty of these languages is
> > that, once you are Enlightened, you can apply your wisdom to other
> > languages as well -- but often would prefer not to.
> 
> 
> Can you do the following in Ada:
> 
> 1. Write *one* bubble-sort function that will work on different 
>    types given an appropriate comparison function

Yes you can, using generics.  This is actually part of the library
that comes with the GNAT compiler.

See the spec for the package at http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/ada/g-busorg.ads?rev=HEAD&content-type=text/vnd.viewcvs-markup

And the body at http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/ada/g-busorg.adb?rev=HEAD&content-type=text/vnd.viewcvs-markup.
 
> 2. If B is a subtype of A, can you pass it to any function that 
>    takes A as an argument? (covariance)

Yes, as illustrated below.  Covariance, as far as I understand, is the
capability to override the function using B as a type for both the
parameter and the return type.  Ada has this capability.  Note that
Ada has no hidden "this" parameter; everything is explicit.

with Ada.Text_IO; use Ada.Text_IO;
procedure Covariance is
   package P is
      type A is tagged null record;
      function Operation (This : A) return A;
      procedure Some_Primitive_Operation (Parameter : in out A);

      type B is new A with null record;
      function Operation (This : B) return B;
      --  is a covariant function: the types of the parameter and the return
      --  type vary together
   end P;

   package body P is
      function Operation (This : A) return A is
      begin
         Put_Line ("Operation on A");
         return This;
      end Operation;

      procedure Some_Primitive_Operation (Parameter : in out A) is
      begin
         Put_Line ("This accepts A or any derived type thereof");
      end Some_Primitive_Operation;

      function Operation (This : B) return B is
      begin
         Put_Line ("Operation on B");
         return This;
      end Operation;
   end P;

   use P;

   My_First_A, My_Second_A : A;
   My_First_B, My_Second_B : B;

begin
   My_Second_A := Operation (This => My_First_A);
   My_Second_B := Operation (This => My_First_B);
   Some_Primitive_Operation (Parameter => My_Second_B);
end Covariance;

> 3. If B is a subtype of A, and FA and FB are functions accepting A 
>    and B as arguments, can you use FA wherever FB could be used?
>    (contravariance)

I'm not sure I understand what you mean.  Does the following code
answer your question?  If it doesn't, please post a compilable code
snippet in your preferred language.

with Ada.Text_IO; use Ada.Text_IO;
procedure Contravariance is
   package P is
      type A is tagged null record;
      function Func (This : in A) return A'Class; -- this would be FA

      type B is new A with null record;
      function Func (This : in B) return A'Class; -- this would be FB
   end P;

   package body P is
      function Func (This : in A) return A'Class is
      begin
         Put_Line ("Func on A");
         return This;
      end Func;

      function Func (This : in B) return A'Class is
      begin
         Put_Line ("Func on B");
         return This;
      end Func;
   end P;

   use P;

   My_First_A, My_Second_A : A;
   My_First_B, My_Second_B : B;

begin
   My_First_A := A (Func (My_First_A));  -- explicit conversion to type A
   My_Second_A := A (Func (My_First_B));  -- explicit conversion to type A
end Contravariance;

> 4. If B is a subtype of A, is list/array/vector/set/etc. of Bs a
>    subtype of list/array/vector/set/etc of As? (covariance)

Not automatically.  You would define new containers explicitly for A
and B, using generics; see for example the Booch components[1] or the
Charles library[2], which is modelled after the C++ STL.  If you want
polymorphic containers, you store pointers in them.

[1] http://www.pogner.demon.co.uk/components/bc/case-study.html
[2] http://home.earthlink.net/~matthewjheaney/charles/

> Unless you can show us how to do this in a way that will keep Ada a 
> "safe" (third category) language you say it is, I will not believe
> that it's a "master of of the masters", I'm afraid.

I cannot show you something you refuse to see (you say you won't learn
Ada).  But if you are curious and intellectually honest, you will see
that Ada is indeed safer almost all other languages.

If Ada is not safe enough for you (even though it is for Boeing and
Airbus and the French TGV), then look into SPARK[3].  SPARK is a
subset of Ada where dynamic memory allocation and several other
potentially dangerous constructs are forbidden.  When I say "subset",
I mean that any Ada compiler can compile any SPARK program.  It also
adds design by contract à la Eiffel, using a tool called the
"Examiner" that complements the compiler.

[3] http://www.sparkada.com

> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.

You would be well advised to learn Ada.  If you don't do it just to
verify my claims, do it to better your understanding of safety,
maintainability and large-scale programming in general.  As I said, if
you accept to be given lessons, you can then reapply this insight to
your language of choice.

> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't 
> letting on about why Ada isn't used much at NASA any more. 
> Perhaps *you* have an explanation?

My earlier post was an attempt at an explanation.  To rephrase it
shortly, few people are willing to be slapped on the hand by the
compiler every time they make a mistake; they'd rather ship buggy
software to customers ("True Programmers"), or use a language that
makes critical decisions unbeknownst to them ("Programming made
easy").  This explanation, of course, is just a theory of mine and is
a caricature more than an accurate description of reality.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

Ludovic Brenta wrote:

> Not automatically.  You would define new containers explicitly for A
> and B, using generics; see for example the Booch components[1] or the
> Charles library[2], which is modelled after the C++ STL.  If you want
> polymorphic containers, you store pointers in them.

> [1] http://www.pogner.demon.co.uk/components/bc/case-study.html
> [2] http://home.earthlink.net/~matthewjheaney/charles/

AdaCL (adacl.sf.net) has polymorphic  containers whichout (exposed) pointers
- that is somthing C++ can't do ;-) because C++'s RTTI is only a cheap
excuse compared with Ada's tags. 

For the C++ programmes: If you copy contruct a class in Ada then Ada will
use the tag of the class to determine the actual child class and copy that
instead of the currently visible prarent view of the class.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Beth Bruzan]

I recently[read today] ,after approximately 7 years of not reading, have
started reading this newsgroup again.....   I should mention that I am a
senior Java Architect, as well as an Ada zealot.  I recommend Ada to anyone
that is trying to get into OO-based software engineering.  Most of them
ignore this recommendation.  Some (I will call them the enlightened ones),
actually take it to heart, and sit down with GNAT, and the Ada95 RM.  And
start asking me questions.   I put it to this group (and anyone else that is
interested), that THESE apprentices quickly progress in abilities.  I would
gladly compare one of these pupils to an "experienced" Java (and possibly
C++) developer, because they actually understand what, and why things need
to be done, and designed well.

After reading the original posting, I was about to sit down and do what
Ludovic has done so nicely.  (luckily, I read more because I just don't have
the time at the moment)

Indeed, Java does have some niceties ( such as the automatic garbage
collection, run-time optimization, etc).  However, with proper design and
implementation, Ada does not need garbage collection, and optimizations can
be done (and for most compilers do) at compile-time.  Admittedly, Ada does
have to be recompiled for each platform, but then it runs without the need
for a virtual machine, and is inherently more efficient.  On top of this,
you can develop Ada that compiles to bytecode, and runs well on virtual
machines.

What is comes down to, for me, is the ease of finding a job in any specific
location.  This allows me to live where I want, when I want.  The current
call for Java is quite large, so I tend to work in Java.

In short, I would say that if it cannot be done in Ada, there is a good
chance that it SHOULDN'T be done at all.




BTW  Thank you again Ludovic.

-- 
Thomas W. Smith
Email: thomas.smith@cox.net


"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message
news:m3smhmz2fo.fsf@insalien.org...
>
> Dear "MSG", I do not normally respond to people who won't tell me
> their name.  Nevertheless, I found your questions interesting, so here
> goes.
>
> msg1825@yahoo.com (MSG) writes:
>
> > Ludovic Brenta <ludovic.brenta@insalien.org> wrote...
> >
> > [...]
> >
> > > The "zen master" languages are Pascal, Modula,
> > > Oberon, and, master of masters, Ada.  The beauty of these languages is
> > > that, once you are Enlightened, you can apply your wisdom to other
> > > languages as well -- but often would prefer not to.
> >
> >
> > Can you do the following in Ada:
<<<<<<<<<<---------SNIP--------->>>>>>>>>>

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Fri, 02 Apr 2004 18:18:42 -0500, Beth Bruzan wrote:

> In short, I would say that if it cannot be done in Ada, there is a good
> chance that it SHOULDN'T be done at all. 

Ah, just what the world needs, another advocate. Ran into a Haskell
webpage that told me programs with strong typing can't crash. Some
language advocates make me feel like I'm trying to buy a used car.

Of course it can be done in Ada; Ada is Turing-complete and is a fairly
low-level language with machine-code insertions. 

Back in the real world, however, Ada isn't always the right solution. ACT
processes some of GNAT's docs with a program written in SNOBOL, and it's
not because they lack experience in Ada. Ada is a fairly low level
language; stepping further away from the machine level can make code more
reliable and easy to read. 

> However, with proper design
> and implementation, Ada does not need garbage collection, 

And with proper design and implementation, C does not need bounds
checking. If your allocation and deallocation is trivial, you don't
need garbage collection; but if you look at something like GCC, they
implemented garbage collection in C because it was too much work to
keep track of the allocations. I have no doubt they would have done the
same thing in Ada. 

> optimizations can be done (and for most compilers do) at compile-time. 

It's frequently hard to predict which way a branch will go at
compile-time, and even if you do profile driven optimization, you can't
handle per session data changes. Those types of optimizations can only be
done at run-time.

> Admittedly, Ada does have to be recompiled for each platform, but then
> it runs without the need for a virtual machine, and is inherently more
> efficient.  On top of this, you can develop Ada that compiles to
> bytecode, and runs well on virtual machines.

I might quibble about "inherently more efficient"; optimizations as above
mean there's probably a program in some research lab that runs faster
under their virtual machine than it could directly compiled for the
system. More importantly, Java is the same as Ada here; it can be natively
compiled or compiled for the JVM and in theory other virtual machines.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ed Falis]

On Sat, 03 Apr 2004 00:08:55 GMT, David Starner <dvdeug@email.ro> wrote:

> I might quibble about "inherently more efficient"; optimizations as above
> mean there's probably a program in some research lab that runs faster
> under their virtual machine than it could directly compiled for the
> system. More importantly, Java is the same as Ada here; it can be 
> natively
> compiled or compiled for the JVM and in theory other virtual machines.

Sure, but it's mainly in theory, like GC in Ada implementations.  Java 
implementations that compile to machine code instead of a JVM 
implementation have not exactly turned the world on fire, just like 
getting ObjectAda to work with Great Circle, or AppletMagic or JGNAT 
didn't.

"Inherently" is probably not the point.  "In practice" probably is.

- Ed

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

A very important point. There are all sorts of wonderful things about 
Ada "In Theory". But if no practical implementations exist, then it 
doesn't matter when I've got a job to get done today. Perhaps Ada needs 
to concentrate on filling in some of those theoretical blanks?

MDC


Ed Falis wrote:> 
> Sure, but it's mainly in theory, like GC in Ada implementations.  Java 
> implementations that compile to machine code instead of a JVM 
> implementation have not exactly turned the world on fire, just like 
> getting ObjectAda to work with Great Circle, or AppletMagic or JGNAT 
> didn't.
> 
> "Inherently" is probably not the point.  "In practice" probably is.
> 
> - Ed
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

David Starner writes:
> On Fri, 02 Apr 2004 18:18:42 -0500, Beth Bruzan wrote:
> > However, with proper design
> > and implementation, Ada does not need garbage collection, 
> 
> And with proper design and implementation, C does not need bounds
> checking. If your allocation and deallocation is trivial, you don't
> need garbage collection; but if you look at something like GCC, they
> implemented garbage collection in C because it was too much work to
> keep track of the allocations. I have no doubt they would have done
> the same thing in Ada.

This turned out not to work that well; there have been large
performance and memory footprint concerns in GCC because of GC.  Linus
Torvalds recommends reference counting as a better, more predictable
and more efficient mechanism.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

Ludovic Brenta wrote:

> David Starner writes:
>> On Fri, 02 Apr 2004 18:18:42 -0500, Beth Bruzan wrote:
>> > However, with proper design
>> > and implementation, Ada does not need garbage collection,
>> 
>> And with proper design and implementation, C does not need bounds
>> checking. If your allocation and deallocation is trivial, you don't
>> need garbage collection; but if you look at something like GCC, they
>> implemented garbage collection in C because it was too much work to
>> keep track of the allocations. I have no doubt they would have done
>> the same thing in Ada.
> 
> This turned out not to work that well; there have been large
> performance and memory footprint concerns in GCC because of GC.  Linus
> Torvalds recommends reference counting as a better, more predictable
> and more efficient mechanism.

True, but for reference counting everybody has to play by the rules. I can
see that in Ada since Ada programmers know that 'Access /= 'Address. But
most C programmers think that (void*) == (int*) == (int) == (long). Not
true of corse - those who still remember the ix86 architecture for x < 3
will know.

Mind you, for Ada programers there is a pitfall as well since access /=
access all.

Wich reminds me. Does anybody know what - should - happen when:

Access_X is access X;
All_X is access all X;

for Access_X'Pool use Access_Pool;
for All_X'Pool use All_Pool;

Some_X : Access_X := new X;
Another_X : All_X := Some_X;

function Deallocate is new Unchecked_Deallocation (X, All_X);

begin
    Deallocate (Another_X);
end;

With Regards

Martin.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Martin Krischik wrote:

> Wich reminds me. Does anybody know what - should - happen when:
> 
> Access_X is access X;
> All_X is access all X;
> 
> for Access_X'Pool use Access_Pool;
> for All_X'Pool use All_Pool;
> 
> Some_X : Access_X := new X;
> Another_X : All_X := Some_X;
> 
> function Deallocate is new Unchecked_Deallocation (X, All_X);
> 
> begin
>     Deallocate (Another_X);
> end;

No.  The execution of the call to Deallocate is erroneous.  That means 
that anything can happen: RM 13.11.2(16) "The execution of a call to an 
instance of Unchecked_Deallocation is erroneous if the object was 
created other than by an allocator for an access type whose pool is 
Name'Storage_Pool."

The proper thing to do is to do the necessary check inside your 
Deallocate.  Unfortunately, there is no language defined attribute that 
can be used to determine the storage pool associated with an access 
object.  Of course, if you define a storage pool, you can also provide 
such an operation:

function Storage_Pool_Of(X: Address) return Root_Storage_Pool'Class;

But it would be nice to have 'Storage_Pool defined for both subtypes (as 
at present) and for all access objects.  That way you could do the 
necessary check to see whether access values denote an object in the 
default storage pool.  In fact, it might be better to have both 
'Storage_Pool, and 'Allocated, where Object'Allocated returns a boolean. 
  ('Storage_Pool should raise an exception if called with a parameter 
that does not belong to any storage pool.)  Or perhaps we could add a value:

No_Storage_Pool: constant Root_Storage_Pool;

to System.Storage_Pools.

However, in the meantime, the best policy is probably to only 
instantiate Unchecked_Deallocation for types which are not declared 
access all.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

Robert I. Eachus wrote:

> Martin Krischik wrote:
> 
>> Wich reminds me. Does anybody know what - should - happen when:
>> 
>> Access_X is access X;
>> All_X is access all X;
>> 
>> for Access_X'Pool use Access_Pool;
>> for All_X'Pool use All_Pool;
>> 
>> Some_X : Access_X := new X;
>> Another_X : All_X := Some_X;
>> 
>> function Deallocate is new Unchecked_Deallocation (X, All_X);
>> 
>> begin
>>     Deallocate (Another_X);
>> end;
> 
> No.  The execution of the call to Deallocate is erroneous. 
> RM 13.11.2(16) "The execution of a call to an 
> instance of Unchecked_Deallocation is erroneous if the object was 
> created other than by an allocator for an access type whose pool is 
> Name'Storage_Pool."

Thank you for the explanation. Of corse, I have never done such a nasty
thing and I never intended to. Just wanted to know. And I will continue to
not use "access all" when "access" will do nicely.

With Regards

Martin  

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

Martin Krischik writes:
> Ludovic Brenta wrote:
> 
> > David Starner writes:
> >> On Fri, 02 Apr 2004 18:18:42 -0500, Beth Bruzan wrote:
> >> > However, with proper design
> >> > and implementation, Ada does not need garbage collection,
> >> 
> >> And with proper design and implementation, C does not need bounds
> >> checking. If your allocation and deallocation is trivial, you don't
> >> need garbage collection; but if you look at something like GCC, they
> >> implemented garbage collection in C because it was too much work to
> >> keep track of the allocations. I have no doubt they would have done
> >> the same thing in Ada.
> > 
> > This turned out not to work that well; there have been large
> > performance and memory footprint concerns in GCC because of GC.  Linus
> > Torvalds recommends reference counting as a better, more predictable
> > and more efficient mechanism.
> 
> True, but for reference counting everybody has to play by the rules.

Is this not a strength rather than a weakness?  Garbage collectors
encourage sloppy programming.  I have seen this phenomenon in action.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

Ludovic Brenta wrote:

> Martin Krischik writes:
>> Ludovic Brenta wrote:
>> 
>> > David Starner writes:
>> >> On Fri, 02 Apr 2004 18:18:42 -0500, Beth Bruzan wrote:
>> >> > However, with proper design
>> >> > and implementation, Ada does not need garbage collection,
>> >> 
>> >> And with proper design and implementation, C does not need bounds
>> >> checking. If your allocation and deallocation is trivial, you don't
>> >> need garbage collection; but if you look at something like GCC, they
>> >> implemented garbage collection in C because it was too much work to
>> >> keep track of the allocations. I have no doubt they would have done
>> >> the same thing in Ada.
>> > 
>> > This turned out not to work that well; there have been large
>> > performance and memory footprint concerns in GCC because of GC.  Linus
>> > Torvalds recommends reference counting as a better, more predictable
>> > and more efficient mechanism.
>> 
>> True, but for reference counting everybody has to play by the rules.
> 
> Is this not a strength rather than a weakness? 

For you an me and most readers of this group.

> Garbage collectors 
> encourage sloppy programming.  I have seen this phenomenon in action.

True. But it can also help in tricky situation. For example: you can only
pass an integral type and an access to a task. If the task is library level
it becomes almost impossible to deallocate the memory.

Of corse, reference counting is enough here.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Florian Weimer]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Is this not a strength rather than a weakness?  Garbage collectors
> encourage sloppy programming.

So does Ada's type safety.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: postino.it, tiscali.co.uk, tiscali.cz, tiscali.it,
voila.fr.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Larry Kilgallen]

In article <87zn9sjc5r.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> 
>> Is this not a strength rather than a weakness?  Garbage collectors
>> encourage sloppy programming.
> 
> So does Ada's type safety.

Only among those who have no requirement for their program to run.
Others are required to correct their errors until the compiler approves.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sat, 03 Apr 2004 11:13:35 +0200, Ludovic Brenta wrote:

> This turned out not to work that well; there have been large
> performance and memory footprint concerns in GCC because of GC.  

There have been large performance concerns in GCC, but I'm unaware
of them being related to GC, and I don't think many of the memory
footprint concerns are related, either.

> Linus
> Torvalds recommends reference counting as a better, more predictable
> and more efficient mechanism.

Coming from a C programmer, that's unsurprising. And within a kernel,
where you need tightly controlled finalization and tight real-time
restrictions, reference counting is often better. But GCC doesn't need
those; and GC is sometimes more efficient than reference counting,
because GC doesn't have to change an object (and possibly bring a page
into memory) every time a new reference is made; the GC costs are
clustered at collection time. 

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Randy Brukardt]

"David Starner" <dvdeug@email.ro> wrote in message
news:pan.2004.04.03.22.45.16.627405@email.ro...
> On Sat, 03 Apr 2004 11:13:35 +0200, Ludovic Brenta wrote:
>
> > This turned out not to work that well; there have been large
> > performance and memory footprint concerns in GCC because of GC.
>
> There have been large performance concerns in GCC, but I'm unaware
> of them being related to GC, and I don't think many of the memory
> footprint concerns are related, either.

Of course they're related to using GC. That means that they're not paying
much attention to storage management, and that is one of the most important
determiners of performance in a compiler.

When we original built Janus/Ada, it had to run in very cramped memory. Yet
we found that it didn't pay to try to deallocate many things (like
symboltable entries). The overhead of deallocation exceeded the extra space
made in most programs (for example, less than 5% of the symboltable nodes
can be reused in typical programs; usually much less). We also found that
the overhead of allocation and deallocation, even though it is pretty small,
was taking up a substantial portion of the run-time of the compiler.
Replacing that by an allocate-once-and-reuse manager improved the compiler
performance a lot without any real impact on memory use. The use of GC
certainly wouldn't have helped in any significant way (the memory use turned
out *not* to be the issue).

For compilers (like a lot of other programs), using GC can make things
*easier*, but it can't make them *better* (and it usually will make them
worse, since compilers don't generate much garbage to begin with). Use GC
doesn't absolve designers of considering storage management (because storage
use usually will have a substantial performance impact), but it can (by
making it easy) cause them to ignore the area.

For the record, I don't see any reason to use reference counts in a
compiler, either. I don't believe we have any reference counts in Janus/Ada.
Objects are either part of a single data structure that is deallocated at
once or are in those parts of the compiler that don't benefit from storage
recovery (so we don't try to deallocate them). The no-overhead solution
always trumps the some-overhead solution. :-)

                           Randy.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Florian Weimer]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> This turned out not to work that well; there have been large
> performance and memory footprint concerns in GCC because of GC.

Previous versions of GCC used manual, arena-based memory management.
It often resulted in buggy code, but the manual approach appears to
have been resulted in a faster compiler.

> Linus Torvalds recommends reference counting as a better, more
> predictable and more efficient mechanism.

Reference counting is slower than more advanced garbage collecting
algorithms.  Only for very large heaps (file systems, for example), it
makes sense.  It might increase locality, true, but usually the added
cost to each pointer manipulation isn't worth it.

Reference counting alone won't help GCC because of its cyclic data
structures, so it's kind of a non-issue anyway.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: postino.it, tiscali.co.uk, tiscali.cz, tiscali.it,
voila.fr.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

"Beth Bruzan" writes:
> What is comes down to, for me, is the ease of finding a job in any
> specific location.  This allows me to live where I want, when I
> want.  The current call for Java is quite large, so I tend to work
> in Java.

I think this is the problem of most would-be professional Ada
programmers.  It took me 8 months to find myself an Ada job, and it's
100 km from home so I commute by train now.  But I just could not
stand Java programmers anymore.  I may be a bit harsh in saying this,
but I think that it is possible to tell them apart because of their
amateurishness and closed-mindedness.

> In short, I would say that if it cannot be done in Ada, there is a
> good chance that it SHOULDN'T be done at all.

I would rephase this, for myself, as: it you don't want it to be done
in Ada, Eiffel or Modula-3, then I don't want to do it at all; find
somebody else for the job.  I don't want to work with amateurs
anymore, I want to work with software engineers.

> BTW  Thank you again Ludovic.

:)

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Keep in mind that while Java has its market, not everything is suited to 
a virtual machine, so its not as if Java and Ada are two interchangeable 
parts.

Going along those lines, you say "if it cannot be done in Ada, there is 
a good chance that it SHOULDN'T be done at all" - I'd have to observe 
that there are lots of things that Ada does not bring to the table that 
would preclude it from playing in certain markets.

Obviously, there is the virtual machine aspect. While there was a 
compiler for the JVM, I don't think it is supported any more and there 
isn't much demand for it. Lack of a good quality compiler for the JVM is 
going to keep it from consideration where the JVM is a critical part.

Then there is the issue of a GUI. Java comes with a GUI as an integral 
part. Ada does not. There are a few GUI-building kits for Ada, but not a 
standard one. So Java gets to come to the table saying "Here's your 
language and here's your GUI and all the Java developers know how to use 
both and they both work together in a variety of places..." Ada comes to 
the table saying "Here's your language and you can go find the GUI of 
your choice and hope it works with your compiler and maybe it won't have 
as many features as our competitors, and you can spend time to train up 
your programmers in how to use it and....."

Add to that the presence of available class libraries and Ada comes up 
short there as well. While Ada does have some standard libraries and it 
has various open source libraries available out on the net and vendors 
provide libraries of their own invention, its not the same as someone 
looking at what Java provides just by virtue of being Java.

So Ada often starts out several yards back from the starting line when 
getting considered for a project. People in the business of making 
software are not there to promote some specific language or even some 
set of programming virtues. They're in it to make money and so issues 
like time to market or cost of development start becoming factors that 
make Ada a difficult choice to justify.

I understand the notion of saying "I'll become a Java expert so I can 
pick and choose from a large variety of jobs and locations." I think 
that is something that puts off a lot of developers who might otherwise 
consider Ada. But in order for there to be more Ada jobs, Ada has to 
find its way into more businesses & industries. That can only happen if 
Ada can offer something *more* than is currently there with Java, C++, 
etc. (Why should someone switch to Ada unless they can get everything 
they already have and then some?) And Ada zealots could go out and start 
businesses of their own selling something written in Ada which would 
have the effect of creating jobs and encouraging emulation of a 
successful model.

MDC



Beth Bruzan wrote:
> I recently[read today] ,after approximately 7 years of not reading, have
> started reading this newsgroup again.....   I should mention that I am a
> senior Java Architect, as well as an Ada zealot.  I recommend Ada to anyone
> that is trying to get into OO-based software engineering.  Most of them
> ignore this recommendation.  Some (I will call them the enlightened ones),
> actually take it to heart, and sit down with GNAT, and the Ada95 RM.  And
> start asking me questions.   I put it to this group (and anyone else that is
> interested), that THESE apprentices quickly progress in abilities.  I would
> gladly compare one of these pupils to an "experienced" Java (and possibly
> C++) developer, because they actually understand what, and why things need
> to be done, and designed well.
> 
> After reading the original posting, I was about to sit down and do what
> Ludovic has done so nicely.  (luckily, I read more because I just don't have
> the time at the moment)
> 
> Indeed, Java does have some niceties ( such as the automatic garbage
> collection, run-time optimization, etc).  However, with proper design and
> implementation, Ada does not need garbage collection, and optimizations can
> be done (and for most compilers do) at compile-time.  Admittedly, Ada does
> have to be recompiled for each platform, but then it runs without the need
> for a virtual machine, and is inherently more efficient.  On top of this,
> you can develop Ada that compiles to bytecode, and runs well on virtual
> machines.
> 
> What is comes down to, for me, is the ease of finding a job in any specific
> location.  This allows me to live where I want, when I want.  The current
> call for Java is quite large, so I tend to work in Java.
> 
> In short, I would say that if it cannot be done in Ada, there is a good
> chance that it SHOULDN'T be done at all.
> 
> 
> 
> 
> BTW  Thank you again Ludovic.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[James Rogers]

Marin David Condic <nobody@noplace.com> wrote in
news:406EB6D2.8030801@noplace.com: 

> Add to that the presence of available class libraries and Ada comes up
> short there as well. While Ada does have some standard libraries and
> it has various open source libraries available out on the net and
> vendors provide libraries of their own invention, its not the same as
> someone looking at what Java provides just by virtue of being Java.
> 

I would rephrase that. Java standard libraries do not exist due to the 
intrinsic nature of the Java language. They exist because Sun Microsystems
has poured millions of dollars into the development of Java standard
libraries.

While Java is a very useful tool, it is good to remember that Java is
owned by Sun. It is a proprietary product. Just ask Microsoft, who
recently paid Sun $700,000,000.00 in the settlement of a lawsuit
regarding Java.

Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

James Rogers writes:
> Marin David Condic wrote in
> 
> 
> > Add to that the presence of available class libraries and Ada comes up
> > short there as well. While Ada does have some standard libraries and
> > it has various open source libraries available out on the net and
> > vendors provide libraries of their own invention, its not the same as
> > someone looking at what Java provides just by virtue of being Java.
> > 
> 
> I would rephrase that. Java standard libraries do not exist due to the 
> intrinsic nature of the Java language. They exist because Sun Microsystems
> has poured millions of dollars into the development of Java standard
> libraries.
> 
> While Java is a very useful tool, it is good to remember that Java is
> owned by Sun. It is a proprietary product. Just ask Microsoft, who
> recently paid Sun $700,000,000.00 in the settlement of a lawsuit
> regarding Java.

Yes.  I would add that Java standard libraries cannot exist because
Java itself is not a standard; it is just a nonstandard specification
by some vendor.

At least by my definition, a "standard" is an official document
published by an official standards body such as ISO, ANSI, W3C, IETF,
or IEEE.

For Java and its libraries to become "standard", Sun would have to
submit their specification to the ISO.  They won't do that because
they'd lose control over the specification.  But, at the same time,
their PR department uses the word "Standard" all over the place, in
order to confuse the unwary and make them believe there is no vendor
lock-in with Java.  These are lies.

But all this is nitpicking.  Marin is right in saying that Java
appears to have more leverage to people who won't spend time choosing
the best tools for the job.  They would like an all-in-one,
one-stop-shop solution for most of their problems, and Java does
provide that while Ada doesn't.  Unless... you consider Debian :)

BTW, who needs a JVM when there is Linux running on all kinds of
hardware, from cell phones to mainframes?  Linux provides all the
hardware abstraction necessary, without the run-time cost of a JVM.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Ludovic Brenta wrote:
> 
> At least by my definition, a "standard" is an official document
> published by an official standards body such as ISO, ANSI, W3C, IETF,
> or IEEE.
> 
Perhaps technically true, but at the end of the day, it is a distinction 
lost in practical application. Is ISO the only way to have a "standard"? 
Sun is pretty huge in its own right and within the context of the Java 
world, they are as capable of establishing a "standard" as anybody else. 
"Standard" by virtue of the fact that they define what the language is 
and wherever you see "Java" you can count on it containing certain 
things. Its just a "standard" that doesn't make it easy for someone else 
to present a competing implementation.

Standards are a wonderful thing. Everyone should have one of their own. :-)


> 
> But all this is nitpicking.  Marin is right in saying that Java
> appears to have more leverage to people who won't spend time choosing
> the best tools for the job.  They would like an all-in-one,
> one-stop-shop solution for most of their problems, and Java does
> provide that while Ada doesn't.  Unless... you consider Debian :)
> 
I'd differ in this respect: What makes something "The Best Tool For The 
Job"? Ada is superior in some technical aspects to other languages such 
as Java when considering the language definition alone. But if Ada 
doesn't provide as much stuff in its toolbox, isn't that in some respect 
making it a less satisfactory tool? Or if the implementation under 
consideration isn't very good, does it still qualify as the best tool 
just because in theory it could be better?

The best tool for the job is the tool that lets me do the job while 
optimizing cost, schedule and quality. We tend to be convinced that Ada 
offers superior quality when one considers only the language proper. 
That may even be true in most cases, but it often ignores cost and 
schedule in evaluating "The Best Tool For The Job". "Quality" can be a 
relative thing - do I really need gold-plated screws when I'm building a 
birdhouse? Even if Java as a language doesn't detect as many bugs as 
does Ada, the presence of a well worn library means I'm not generating 
new and potentially buggy code to do the same thing. Might that not 
result in a higher quality end product - while reducing my costs and 
improving my schedule?

People don't select Java because they are fools. They often select Java 
over Ada for all sorts of legitimate and important reasons. If we want 
to get them selecting Ada over Java, we have to understand those reasons 
and come to the table being a better satisfier of those needs.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

Marin David Condic writes:
> Standards are a wonderful thing. Everyone should have one of their
> own. :-)

That's a nice way of describing Sun's policy :) I'm not as diplomatic
as you are :)

> I'd differ in this respect: What makes something "The Best Tool For
> The Job"? Ada is superior in some technical aspects to other languages
> such as Java when considering the language definition alone. But if
> Ada doesn't provide as much stuff in its toolbox, isn't that in some
> respect making it a less satisfactory tool? Or if the implementation
> under consideration isn't very good, does it still qualify as the best
> tool just because in theory it could be better?

One of the nice things with Ada is that several implementations are
available and can be evaluated.  Surely, one of these implementations
will turn out to be the best tool for the job.  But, this requires
effort to evaluate the compilers and libraries.  In my experience,
very few people actually make that effort.  Do you think they evaluate
the Java compiler and library?  If they did, they wouldn't use them.

> The best tool for the job is the tool that lets me do the job while
> optimizing cost, schedule and quality. We tend to be convinced that
> Ada offers superior quality when one considers only the language
> proper. That may even be true in most cases, but it often ignores cost
> and schedule in evaluating "The Best Tool For The Job". "Quality" can

I differ in this respect.  I find that I am much more productive with
Ada than with Java, C++, C or Pascal.  With Ada, I spend more time
developing and less time debugging.

> be a relative thing - do I really need gold-plated screws when I'm
> building a birdhouse? Even if Java as a language doesn't detect as
> many bugs as does Ada, the presence of a well worn library means I'm
> not generating new and potentially buggy code to do the same
> thing. Might that not result in a higher quality end product - while
> reducing my costs and improving my schedule?

Ada has all the libraries needed to get that kind of leverage.  The
only problem is that these libraries don't come with the compiler, so
you have to look for them.  Or use Debian :)

> People don't select Java because they are fools. They often select
> Java over Ada for all sorts of legitimate and important reasons. If
> we want to get them selecting Ada over Java, we have to understand
> those reasons and come to the table being a better satisfier of
> those needs.

No, they are not fools.  Their legitimate reason for choosing Java is
that "everybody uses it", so it is easy for them to find disposable,
cheap beginner programmers.  They instruct these programmers to
deliver buggy code quickly.  These beginners are all too happy to use
an "easy" and "fashionable" language, which their teachers at school
taught them because "the industry demands it" (see the self-fulfilling
prophecy there?).  Then, when customers complain about the bugs, they
blame the developers and fire them.  Now is an "urgent" problem, so
they quickly hire new apprentices and use them to churn out a new,
buggy release that "fixes" the worst bugs while at the same time
bringing new ones.

In short, their legitimate and important reasons are "job security for
managers" and "repeat customers".

Development managers want a high price/quality ratio, i.e. a high
development price and low quality.  Why?  Because, by spending lots of
money on development, they are important.  And by delivering low
quality, they can say "See?  My budget was too low!", and they can
also charge big bucks to customers.

In corporations, customers want a high price, because spending lots of
money makes them important.  But they also want high quality.  Once
they've paid the big bucks for the expensive software they've
selected, they are reluctant to admit that it's buggy or inadequate.
Therefore, they pay even more for fixes and upgrades, and eveyone is
happy.

Except for software developers and end users.  The former work under
pressure and get all the blame, while the latter have so totally lost
confidence in the software that they blame it for everything.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

I would add that, I think the best way to promote Ada is to write "Ada
for Dummies" books and litter bookstores with them.  This, of course,
requires millions of bucks in marketing.  At the same time, there
should be a press campaign in "Joe User's Home PC Magazine" saying
that "Ada in the Entreprise" is the next big thing.  Pointy-haired
managers and apprentice programmers alike read this kind of magazine
religiously.

Combined, these two actions would create the illusion that "everyone
uses Ada".  As Sun and Java, and C++, have demonstrated, this illusion
becomes reality when sufficiently many people believe it.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Textbooks would help. It may not be as hard as you think. Obviously, 
there are a number of good texts about Ada already in existence. One 
that was aimed at a more "How To" level could be put together and might 
encourage more people to investigate Ada.

Suppose there was a textbook that came with a whole shrink-wrap 
development kit that included a compiler (Gnat?) an editor (GPS?) a GUI 
builder (GtkAda?) a database (GNADE/MySQL?) and a class library that 
provided facilities for a wide variety of purposes such as data 
structures, networking, etc. (???)

What if they all worked nicely together?

What if it installed with the simplicity of plugging in the disk and 
answering "Yes" to everything on the install shield?

What if it had a pre-fabricated "Project Library" concept so that all 
the pieces (stuff generated by GtkAda, Gnade, etc) were kept in some 
comprehensible, manageable place rather than have the end user struggle 
to figure out where to put all the pieces and how to get them all to 
compile/run?

What if the book were not written on a high academic level and was 
instead written as a "How To" book that walked the user through how to 
build everything from a "Hello World" app to a multi-window GUI app that 
utilized a complex database & networking?

Might that not start approaching what you can get from other languages? 
Would that not make it easier for a hobbyist or student or small company 
to start using Ada? It may not be a sufficient condition for someone to 
start adopting Ada, but I think it is a necessary one. Saying that all 
the pieces exist out there on the Internet somewhere is *not* the same 
as saying "Here's your disk. Plug it in and get started learning/using 
Ada with *no* fuss over the tools."

MDC


Ludovic Brenta wrote:
> I would add that, I think the best way to promote Ada is to write "Ada
> for Dummies" books and litter bookstores with them.  This, of course,
> requires millions of bucks in marketing.  At the same time, there
> should be a press campaign in "Joe User's Home PC Magazine" saying
> that "Ada in the Entreprise" is the next big thing.  Pointy-haired
> managers and apprentice programmers alike read this kind of magazine
> religiously.
> 
> Combined, these two actions would create the illusion that "everyone
> uses Ada".  As Sun and Java, and C++, have demonstrated, this illusion
> becomes reality when sufficiently many people believe it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

Ada is not for dummies.   To seduce programmer wannabees into believing
that is might be a disservice to them and to the industry.

There are several excellent books available for free that people can
download
from the Web.   John English's book is a good start.   My book, Ada
Distilled,
has proven to be popular among some interested parties.   The Lovelace
Tutorial continues to attract a following.

The inability of Ada to attract a popular following is not due to the lack
of good
educational tools.   Rather, it is due to misperceptions rooted in some
historical
difficulties associated with the language.

Some computer professionals continue to believe Ada is a language used only
by and for military applications.   Compiler vendors, including Rational,
IBM,
and HP, when they were supporting Ada,  isolated Ada in their Federal
Systems
Sales divisions and rarely, if ever, discussed it with their commercial
customers.
Compiler vendors, with a few exceptions (e.g., Meridian, RR Software) priced
Ada compilers at a price so unattractive for commercial customers that few
commercial developers could even consider Ada as an option.   They realized,
while the "mandate" was in effect that they had the DoD "over a barrel" and
could charge whatever they wanted.   There were no libraries available that
made
Ada easy to use on the new Personal Computers of the 1980's.  Ada compilers
were more difficult to use,  and a BASIC programmer could write powerful
programs for simple business problems more easily than most Ada compiler
users.   Meridian tried to overcome this problem with its DOS libraries, but
there were problems with those libraries that created frustration among even
the advocates of Ada.

Starting with Ada 95, Ada got better.  Its reputation did not get better.
Once
a language, product, or person is saddled with a bad reputation, it is
difficult
to overcome it.   It did not help that the DoD abrogated its support for Ada
in the mid-90's.   This was seen, by the software community at large as not
only
the abandonment of Ada for all DoD projects, but the death knell for the
language itself.   Companies solely dedicated to Ada suddenly found
themselves
with a diminishing customer base.   The resulting reduction in the sale of
Ada
compilers and tools led to layoffs,  corporate restructuring,  mergers in
which
Ada products virtually vanished, and smaller number of universities choosing
Ada as part of their curriculum.

Ada continues to be one of the best options for developing robust software.
Even
if it were the best option, that would not be enough.  We need to somehow
get
the message to the larger software community that Ada is a good alternative
to the languages already popular.  For several years, during the 1990's, I,
along
with others, had the opportunity to get the message out through writing
articles
about Ada's success.   I know of several organizations that were attracted
to
Ada through some of those articles.

One company's engineering manager called me and asked for a presentation
on Ada for his engineers.   After the presentation they were enthusiastic
about using it for their commercial real-time applications.  Then they
encountered
a compiler vendor, one of the most prominent of the compiler vendors of the
1990's.   The Ada representatives of the compiler vendor did not understand
commercial applications or commercial needs. They approached the entire
problem as they would a "funded" military project.   Their prices were too
high.
Their service too military-oriented.  Their attitude was interpreted by the
prospect
as, "We don't really know how to serve you and we already have plenty of
military customers who are a lot less trouble than you."    Whether this was
their
intent, this is how the prospect percieved them.  We lost that large
multinational
company to C++, not because C++ was better, but because of the attitudes
of the compiler vendor.

This story is not unique.  As long as Ada was considered, even by its
advocates,
a primarily a "government" language, it had no chance to survive in
commercial
industry.  Now, Ada is not directly tied to the military.  In fact, most
military
contractors have rejected it in favor of C++ or Java.  I see that directly
because
so many of my military contractor clients have all but abandoned Ada.  One
excuse for doing so is the lame, "We can't find experience Ada programmers."

If we want to revitalize interest in Ada, we must do so by creating good
systems
in Ada.   I mean by this, good commercial software products.  As we do so,
we
can make it known that the quality of these products is, in part, because we
used
Ada.   At present, with the exception of ACT and RR Software, even the Ada
compiler vendors use other languages for their own internal software
projects.

Ada can be popular.  It is all uphill from here.   Ada programmers of the
world
unite.  You have nothing to lose but your C++.

Richard Riehle



"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message
news:87zn9sygtj.fsf@insalien.org...
> I would add that, I think the best way to promote Ada is to write "Ada
> for Dummies" books and litter bookstores with them.  This, of course,
> requires millions of bucks in marketing.  At the same time, there
> should be a press campaign in "Joe User's Home PC Magazine" saying
> that "Ada in the Entreprise" is the next big thing.  Pointy-haired
> managers and apprentice programmers alike read this kind of magazine
> religiously.
>
> Combined, these two actions would create the illusion that "everyone
> uses Ada".  As Sun and Java, and C++, have demonstrated, this illusion
> becomes reality when sufficiently many people believe it.
>
> -- 
> Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Without commercial products being built in Ada, there is no revenue. 
Without revenue, nobody spends much to buy Ada from the vendors. The 
vendors eventually start following the revenue. Hobbyists & students are 
not going to keep the vendors interested. So Ada needs to target the 
commercial developers of software or its vendors eventually go off and 
write C++ compilers - or go out of business. That seems obvious, but its 
difficult to get any real consensus on how to do that or where to go 
with it.

Ada may shine in some areas - large, long lived, high reliability 
systems where connections to ancillary products (GUI, database, 
netrwork, libraries, OS's, development/support tools) are a negligible 
issue. But those systems are few and far between. Other languages do 
better because they provide more leverage in some application domains - 
they come equipped with all the stuff someone needs to get their app 
done quicker. Ada needs to identify some reasonably large sector of the 
compiler-buying public and go way out of its way to make life as easy as 
possible for developers in that sector.

We just won't win out if the best answer we have to someone who needs a 
GUI or a database or a network connection or some other 
non-general-programming need is to say "Well, you can always go build a 
binding to this C library...." We have to give them a *better* answer 
than they already get with C/C++/Java/VB/etc. or they have no incentive 
to want to go learn Ada and start using it. Pick a new market and start 
catering to it.

MDC

Richard Riehle wrote:
> 
> If we want to revitalize interest in Ada, we must do so by creating good
> systems
> in Ada.   I mean by this, good commercial software products.  As we do so,
> we
> can make it known that the quality of these products is, in part, because we
> used
> Ada.   At present, with the exception of ACT and RR Software, even the Ada
> compiler vendors use other languages for their own internal software
> projects.
> 
> Ada can be popular.  It is all uphill from here.   Ada programmers of the
> world
> unite.  You have nothing to lose but your C++.
> 
> Richard Riehle
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Ludovic Brenta wrote:
> 
> I differ in this respect.  I find that I am much more productive with
> Ada than with Java, C++, C or Pascal.  With Ada, I spend more time
> developing and less time debugging.
> 
Yeah, but let's be fair. If you have to go out and roll your own GUI 
interfaces or database access interfaces or data structures or other 
numerous things that you might or might not get with a given language, 
that's making things dramatically worse. You have to develop the code 
and you have to test & debug the code (Ada doesn't guarantee zero 
defects, does it?) and that time is not zero. The more I get with an 
environment the less work I do getting an app up and running. And I 
probably spend less time debugging as well, because on the whole, I 
write less code. What I reuse from the vendor's libraries is *probably* 
more stable than something I just now coded up, so I'm likely to save 
time reusing their work.



> 
> Ada has all the libraries needed to get that kind of leverage.  The
> only problem is that these libraries don't come with the compiler, so
> you have to look for them.  Or use Debian :)
> 
Ada might or might not have available libraries that end up providing 
the same amount of support you'd get with some other language like Java. 
You'd have to do a study to find out. But they are clearly not 
"standard", they are not delivered with the compiler, they may or may 
not have documentation of questionable quality and consistency, they 
probably won't look similar in design, they are mostly unsupported, etc...

Why is something like Visual Basic popular with developers? They get 
*everything* they need to develop an app in one nice shrink-wrapped 
package. It has documentation (some might be critical of it, but having 
it at all is better than nothing and usually I've found I can learn what 
I need to from Microsoft docs.) Books are written about how to use it. 
It has all the pre-built interfaces to what you need on the system. It 
*works* right out of the box with no need to mess around trying to 
integrate the different pieces and get them all to work together.

When someone goes to build an app, they generally have some limited time 
in which to get the job done. Spending time researching different 
libraries, pulling them all together, trying to figure out how they 
work, trying to simply get them to work at all, reading source code 
because there is little to no documentation, building "glue" code to 
stick them together because they aren't all built on the same design 
philosophy, etc., etc., etc... This is all time spent *NOT* developing 
the app of interest.

Perhaps there are geeks out there who enjoy building their own custom 
development environment out of bits and pieces. They can play "Systems 
Integrator" and spend their time on tool development. I'm afraid I don't 
want to hire those guys because I have a *job* that needs to get done 
and tinkering around endlessly with the tools isn't going to get it 
done. That's why I can easily understand when someone opts for "One Stop 
Shopping" in selecting a toolset.




> 
> No, they are not fools.  Their legitimate reason for choosing Java is
> that "everybody uses it", so it is easy for them to find disposable,
> cheap beginner programmers.  They instruct these programmers to
> deliver buggy code quickly.  These beginners are all too happy to use
> an "easy" and "fashionable" language, which their teachers at school
> taught them because "the industry demands it" (see the self-fulfilling
> prophecy there?).  Then, when customers complain about the bugs, they
> blame the developers and fire them.  Now is an "urgent" problem, so
> they quickly hire new apprentices and use them to churn out a new,
> buggy release that "fixes" the worst bugs while at the same time
> bringing new ones.
> 
> In short, their legitimate and important reasons are "job security for
> managers" and "repeat customers".
> 
> Development managers want a high price/quality ratio, i.e. a high
> development price and low quality.  Why?  Because, by spending lots of
> money on development, they are important.  And by delivering low
> quality, they can say "See?  My budget was too low!", and they can
> also charge big bucks to customers.
> 
> In corporations, customers want a high price, because spending lots of
> money makes them important.  But they also want high quality.  Once
> they've paid the big bucks for the expensive software they've
> selected, they are reluctant to admit that it's buggy or inadequate.
> Therefore, they pay even more for fixes and upgrades, and eveyone is
> happy.
> 
> Except for software developers and end users.  The former work under
> pressure and get all the blame, while the latter have so totally lost
> confidence in the software that they blame it for everything.
> 

This sounds a little cynical and a bit like setting up a strawman in 
order to knock him down. I've worked in a number of places that have 
used a variety of toolsets to make lots of different products. In 
general, I've found that people basically *want* to do a good job - 
including management. I've also learned over time that often the "worker 
bees" like to criticize any/all management decisions as "stupid" or 
"selfish" when in fact, they are not. Often management decisions are 
just being made based on criteria that worker bees either don't know 
about, don't understand or disagree with. In my experience, the 
decisions are seldom either stupid or selfish - they are usually 
someone's honest attempt to make the best decision they could to further 
the goals of the organization. Its real easy to play "Monday Morning 
Quarterback" and criticize every decision that gets made, but its a lot 
harder to take the reigns, make the decisions and live with the 
consequences.

That said, I will again reiterate that selecting Java is not a foolish 
choice in many contexts. I think it is more productive to understand 
*why* people will select Java and - if we would rather they selected Ada 
instead - give them what they need in Ada to satisfy their selection 
criteria.

Why did Java - starting out from zero - garner a large user base? 
Because Sun was big and Sun was promoting it hard and Sun forced it on 
people? The same could be said for Ada and the DoD. Java catches on and 
Ada doesn't? Maybe Java was satisfying some needs out there pretty well. 
Maybe Ada could take a lesson on that score and go out and satisfy some 
customer needs better than any other choice.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:40714C98.90601@noplace.com...
> Why did Java - starting out from zero - garner a large user base?
> Because Sun was big and Sun was promoting it hard and Sun forced it on
> people? The same could be said for Ada and the DoD. Java catches on and
> Ada doesn't? Maybe Java was satisfying some needs out there pretty well.
> Maybe Ada could take a lesson on that score and go out and satisfy some
> customer needs better than any other choice.

The reason that Java got successful (like the reason that *anything* or
*anyone* gets successful) was luck. Sun got what had been a widely ignored
language/system tied to a skyrocket (the internet) by putting applet support
into Netscape. That got the foot in the door where heavy promotion could
make an effect.

Remember, it's a combination of luck and marketing that makes anyone or
anything successful. Merit has very little to do with it - the only
requirement being that the product fufill some (but not necessarily all) of
its promises.

Most software is crap because you can sell crap as well as easily as
gold-plated programs. Since most managers know this, why would they care if
they use crap to develop it? It's the same reason that so many software jobs
are being outsourced -- there it's any reason to get anything beyond an
adequate job at the cheapest possible rate.

Those of us who would like something better are swimming upstream in the
Niagara River; we're almost (but not certainly) doomed to fail.

                          Randy.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Randy Brukardt wrote:

>The reason that Java got successful (like the reason that *anything* or
>*anyone* gets successful) was luck. Sun got what had been a widely ignored
>language/system tied to a skyrocket (the internet) by putting applet support
>into Netscape. That got the foot in the door where heavy promotion could
>make an effect.
>
>Remember, it's a combination of luck and marketing that makes anyone or
>anything successful. Merit has very little to do with it - the only
>requirement being that the product fufill some (but not necessarily all) of
>its promises.

In the case of Java the most significant reason for that skyrocketed success
was (I think) not just luck and aggressive marketing, but very high level of
professional traitorousness among CS teachers in American universities. In
late 90th they massively adopted Java for their courses despite obvious defects
of the language (the most beautiful example is absence of enumerations in Java
- before appearance of Java those academic people always claimed that
enumerations are very important and necessary, but no one them said a word
about their absence in Java - they were too busy in praising Java to notice
such a tiny detail).



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Randy Brukardt wrote:
> 
>>The reason that Java got successful (like the reason that *anything* or
>>*anyone* gets successful) was luck. Sun got what had been a widely ignored
>>language/system tied to a skyrocket (the internet) by putting applet
>>support into Netscape. That got the foot in the door where heavy promotion
>>could make an effect.
>>
>>Remember, it's a combination of luck and marketing that makes anyone or
>>anything successful. Merit has very little to do with it - the only
>>requirement being that the product fufill some (but not necessarily all)
>>of its promises.
> 
> In the case of Java the most significant reason for that skyrocketed
> success was (I think) not just luck and aggressive marketing, but very
> high level of professional traitorousness among CS teachers in American
> universities. In late 90th they massively adopted Java for their courses
> despite obvious defects of the language (the most beautiful example is
> absence of enumerations in Java - before appearance of Java those academic
> people always claimed that enumerations are very important and necessary,
> but no one them said a word about their absence in Java - they were too
> busy in praising Java to notice such a tiny detail).

But why they adopted Java? It was the same combination of luck and marketing
Randy Brukardt wrote about. That time many of them had Sun worstations
avaiable. Nobody ever liked Microsoft. End of story. 

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > In the case of Java the most significant reason for that skyrocketed
> > success was (I think) not just luck and aggressive marketing, but very
> > high level of professional traitorousness among CS teachers in American
> > universities. In late 90th they massively adopted Java for their courses
> > despite obvious defects of the language (the most beautiful example is
> > absence of enumerations in Java - before appearance of Java those academic
> > people always claimed that enumerations are very important and necessary,
> > but no one them said a word about their absence in Java - they were too
> > busy in praising Java to notice such a tiny detail).
>
> But why they adopted Java? It was the same combination of luck and marketing
> Randy Brukardt wrote about.

Why you, not being an American, use this luck-based theory, which is proprietary
American? -:)  Do you really think that Sun, when investing not small money in
that Java move, did so just in adventurous hope of meeting luck on the road?
Didn't you noticed how IBM pushed Java all the way - was it just luck for Sun?

> That time many of them had Sun worstations
>avaiable. Nobody ever liked Microsoft. End of story. 

I don't think that availability of Sun workstations played significant role
there - nobody liked Sun workstations too much (except of those who used
multiprocessors, which couldn't be widely available in universities)... some
liked SGIs, some Alphas, but I never heard of anyone being particularly fond
of uniprocessor Sun workstation.

And frowning at the Microsoft played no role there - in fact, Microsoft readily
produced their JVM and equipped IE accordingly (the fact that MS "tried to
poison" Java is immaterial here as we talk about skyrocketed adoption of Java
language).

There was real matter that time - dot-coms were booming and there was widespread
strong feeling about the need of easily distributable specialized clients for
online shopping. And this was the trampoline for Java - applets. Then, after
several years, dot-com bubble bursted, applets faded, but critical mass for
the language was already reached - thanks to conformant university CS teachers
in big part.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> > In the case of Java the most significant reason for that skyrocketed
>> > success was (I think) not just luck and aggressive marketing, but very
>> > high level of professional traitorousness among CS teachers in American
>> > universities. In late 90th they massively adopted Java for their
>> > courses despite obvious defects of the language (the most beautiful
>> > example is absence of enumerations in Java - before appearance of Java
>> > those academic people always claimed that enumerations are very
>> > important and necessary, but no one them said a word about their
>> > absence in Java - they were too busy in praising Java to notice such a
>> > tiny detail).
>>
>> But why they adopted Java? It was the same combination of luck and
>> marketing Randy Brukardt wrote about.
> 
> Why you, not being an American, use this luck-based theory, which is
> proprietary American? -:)

I lost my faith in Karl Marx long time ago! (:-))

BTW, there is no big difference between the "luck-based" theory and one of
Marin. Both agree that technical issues are irrelevant. The "luck-based"
theory stops here. Marin and you continue that probably managers have some
other [supreme, unknowable] reasons for their choices. Maybe. But this
changes nothing. And nothing techincal can be made about Ada to change
that. Because see above, technical issues are irrelevant.

> Do you really think that Sun, when investing not small
> money in that Java move, did so just in adventurous hope of meeting luck
> on the road?

Yes.

> Didn't you noticed how IBM pushed Java all the way - was it
> just luck for Sun?

Yes.

>> That time many of them had Sun worstations
>>avaiable. Nobody ever liked Microsoft. End of story.
> 
> I don't think that availability of Sun workstations played significant
> role there - nobody liked Sun workstations too much (except of those who
> used multiprocessors, which couldn't be widely available in
> universities)... some liked SGIs, some Alphas, but I never heard of anyone
> being particularly fond of uniprocessor Sun workstation.

I didn't say they were popular. I said they were avaialble. They were the
core of LANs. They were attached to the Internet. So Java was in the right
time at the right place.

> And frowning at the Microsoft played no role there - in fact, Microsoft
> readily produced their JVM and equipped IE accordingly (the fact that MS
> "tried to poison" Java is immaterial here as we talk about skyrocketed
> adoption of Java language).

Microsoft tried to spoil it and so to get the control over it. They always
do things like that.

> There was real matter that time - dot-coms were booming and there was
> widespread strong feeling about the need of easily distributable
> specialized clients for online shopping.

Mmm, that was 3 years or so later. As for "easily distributable specialized
clients", well, that existed for years before, though under other name:
"virus".

> And this was the trampoline for
> Java - applets. Then, after several years, dot-com bubble bursted,
> applets faded,

And of course, we do not ask ourselves, why. Because that would lead us to
those unloved technical issues...

> but critical mass for the language was already reached - thanks to
> conformant university CS teachers in big part.

Huh, those conformant teachers already switched C#.

Isn't it mysterious, how universities are promoting bad technologies? It was
C and UNIX before Java.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

A manager's reasons for selecting a language are not necessarily 
"supreme" - other than in the sense that ultimately, they have to make 
the decision and be responsible for the net effect so their reasons 
trump those of the technocrat. Also, often, the manager is operating on 
the recommendations of his staff - who are technical - and they have 
reasons to want to use something other than Ada as well. The manager's 
reasons are also not "unknowable". Usually, all you have to do is ask. 
When I try to persuade those above me or my customers that Ada is 
technically superior and they should choose it, I take time to listen 
when they say "Yes, but....."

As it turns out, the reasons they have are - as you observe - not 
"technical" in nature. They are usually more practical business 
concerns. (And lest we all forget, business concerns are important 
because without paying attention to them, we're all out of jobs.) Try 
some of these:

"People I interview for jobs don't know Ada and don't want to know Ada - 
they want to use languages they like & will be marketable. How do I hire 
the programmers I need?"

"My staff doesn't like Ada and I don't want to force them to use 
something they don't like because they won't be as productive."

"Industry in general ignores Ada so I can't get the tools I need - or I 
can only at a much higher cost..."

"Other, more popular languages, come with things that give me leverage 
in developing the product I need so I get to market sooner..."

"I've already got existing software in Language X and all the related 
things I have to connect to are in Language X, so why do I want to incur 
the extra cost of using some other language?"

'Ada is a dying language and I need to use something that is going to 
have a future..."

There are obviously more but the important thing is that these concerns 
are *REAL* and *VALID* - if not *TECHNICAL*. So if Ada doesn't want to 
just slowly go down the toilet, it ought to look to addressing the 
concerns of that manager voicing those objections. Telling him he's 
wrong and stupid is only going to get you dismissed as a kook because he 
*knows* his concerns are legetimate and important. Why not address those 
concerns and take the language in a new direction that might start 
alleviating some of them?

MDC


Dmitry A. Kazakov wrote:
> 
> BTW, there is no big difference between the "luck-based" theory and one of
> Marin. Both agree that technical issues are irrelevant. The "luck-based"
> theory stops here. Marin and you continue that probably managers have some
> other [supreme, unknowable] reasons for their choices. Maybe. But this
> changes nothing. And nothing techincal can be made about Ada to change
> that. Because see above, technical issues are irrelevant.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
 
: There are obviously more but the important thing is that these concerns 
: are *REAL* and *VALID* - if not *TECHNICAL*. So if Ada doesn't want to 
: just slowly go down the toilet, it ought to look to addressing the 
: concerns of that manager voicing those objections.

So, a technical thing like a language should be addressing issues that are
also related to
- the kind of project
- prejudice
- following the herd
- assumptions (you have alluded to many in your list, I think)
   
Is there any convincing evidence of a correlation of market success and
the concerns you named?
For example, I can imagine long term projects where
programmer competence is more important than knowledge of language X.
(Because they can learn it.  After all, Java projects have been started
when there were no experienced Java programmers, or development environments,
or data base bindings, or .... you name it. And job ads frequently
feature "similar object oriented technology" etc..)

: Telling him he's 
: wrong and stupid is only going to get you dismissed as a kook because he 
: *knows* his concerns are legetimate and important.
  ^^^^^^^
*thinks*. Who is suggesting to tell a manager that he is stupid?

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Marin David Condic wrote:

> A manager's reasons for selecting a language are not necessarily
> "supreme" - other than in the sense that ultimately, they have to make
> the decision and be responsible for the net effect so their reasons
> trump those of the technocrat. Also, often, the manager is operating on
> the recommendations of his staff - who are technical - and they have
> reasons to want to use something other than Ada as well. The manager's
> reasons are also not "unknowable". Usually, all you have to do is ask.

Someone as genius as Dr.Freud could probably understand their answers...
(:-))

> When I try to persuade those above me or my customers that Ada is
> technically superior and they should choose it, I take time to listen
> when they say "Yes, but....."
> 
> As it turns out, the reasons they have are - as you observe - not
> "technical" in nature. They are usually more practical business
> concerns. (And lest we all forget, business concerns are important
> because without paying attention to them, we're all out of jobs.) Try
> some of these:
> 
> "People I interview for jobs don't know Ada and don't want to know Ada -
> they want to use languages they like & will be marketable. How do I hire
> the programmers I need?"

Firstly, it is his job to hire people. If it cannot do his job, he should
look for another.

Secondly, time to time I interview people. It is true that almost nobody
knows Ada. But the truth also is that good people have no problems with
that. While bad people are bad in any language. Many managers tend to think
that any problem can be solved by doubling the resources. It is an
incompetence.

> "My staff doesn't like Ada and I don't want to force them to use
> something they don't like because they won't be as productive."

Honestly, I never met any opposition to Ada from the side of CS
professionals and programmers. It was always engineers grown to the
managing positions having no CS background. Though this cannot count as a
statistical observation, of course.

> "Industry in general ignores Ada so I can't get the tools I need - or I
> can only at a much higher cost..."

It is a silly argument, if one compares the price of a tool with the salary
of a programmer. The problem is that the advantage of higher productivity
is not directly seen.

> "Other, more popular languages, come with things that give me leverage
> in developing the product I need so I get to market sooner..."

They also make me dependent on third party products, which quality is
questionable. A wrong choice may lead to project collapse. [I saw one] A
certification of all alien software components is very expensive,
unreliable and delays the project.

> "I've already got existing software in Language X and all the related
> things I have to connect to are in Language X, so why do I want to incur
> the extra cost of using some other language?"

This is a real argument. Many software houses have home grown libraries etc.
So I am absolutely on your side, when you are promoting a larger standard
Ada environment. That could really change the situation here.

I would also like to see JGNAT revived and more progress in A#.

> 'Ada is a dying language and I need to use something that is going to
> have a future..."

I do not think that a manager really cares. Once the project is done, it is
no matter whether Ada will die or not.

> There are obviously more but the important thing is that these concerns
> are *REAL* and *VALID* - if not *TECHNICAL*. So if Ada doesn't want to
> just slowly go down the toilet, it ought to look to addressing the
> concerns of that manager voicing those objections. Telling him he's
> wrong and stupid is only going to get you dismissed as a kook because he
> *knows* his concerns are legetimate and important. Why not address those
> concerns and take the language in a new direction that might start
> alleviating some of them?

If you reread arguments of your "virtual" manager you will see that most of
them are related the view on Ada. Improvements of Ada (though I wished
them) cannot change that. One need a great promotion campaign. One need Ada
being taught in universities.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

I'd disagree with some of your analysis, but not all of it. Common 
criticisms of Ada may not always be valid - but usually, behind them 
there is some real concern with being able to do a job efficiently and 
staying competitive. Approaching the manager or developer who has these 
concerns and saying "You're stupid" isn't going to get the desired 
result. Saying "I understand your concern and why it is important to you 
and we're working on improving that thing by doing XYZ..." probably will 
get a lot better results.

I won't address everything here, but I'll say that there can be great 
additional costs and risks when "going against the heard" so a manager 
has very valid concerns if he chooses to use something that is not the 
common tool for the job. People's jobs and a company's future are on the 
line so failed experiments with the unknown can be incredibly 
disasterous. (Anyone out there want to volunteer to be fired if a switch 
to Ada doesn't go well?) Keep that in mind when being critical of the 
manager who wants to "follow the crowd".

I agree that not all those concerns can be addressed by changing 
something in the language standard. What I am suggesting is that a) be 
*sensitive* to those concerns when looking at where the language needs 
to go and b) figure out if there is some way to do a better job of 
marketing Ada in areas that would help build up that larger user base so 
that the "follow the crowd" related concerns start to minimize.

Just to illustrate: If Ada had determined to go out and provide - say - 
"Network Programming" utility to try to capture that market. When the 
manager of a network related job says "well, I'd be spitting against the 
wind, my programmers won't like it, etc...." then there is the comeback: 
"True, but look at all this clever stuff you get that will help you get 
your job done TWICE as fast as if you used C/C++/Java....." A major 
improvement in his efficiency will go a long way towards overcoming 
other objections. That's how Java got into a lot of projects - by being 
able to bring a lot more leverage to a specific type of programming.

MDC



Dmitry A. Kazakov wrote:
> Marin David Condic wrote:
> 
> 
>>A manager's reasons for selecting a language are not necessarily
>>"supreme" - other than in the sense that ultimately, they have to make
>>the decision and be responsible for the net effect so their reasons
>>trump those of the technocrat. Also, often, the manager is operating on
>>the recommendations of his staff - who are technical - and they have
>>reasons to want to use something other than Ada as well. The manager's
>>reasons are also not "unknowable". Usually, all you have to do is ask.
> 
> 
> Someone as genius as Dr.Freud could probably understand their answers...
> (:-))
> 
> 
>>When I try to persuade those above me or my customers that Ada is
>>technically superior and they should choose it, I take time to listen
>>when they say "Yes, but....."
>>
>>As it turns out, the reasons they have are - as you observe - not
>>"technical" in nature. They are usually more practical business
>>concerns. (And lest we all forget, business concerns are important
>>because without paying attention to them, we're all out of jobs.) Try
>>some of these:
>>
>>"People I interview for jobs don't know Ada and don't want to know Ada -
>>they want to use languages they like & will be marketable. How do I hire
>>the programmers I need?"
> 
> 
> Firstly, it is his job to hire people. If it cannot do his job, he should
> look for another.
> 
> Secondly, time to time I interview people. It is true that almost nobody
> knows Ada. But the truth also is that good people have no problems with
> that. While bad people are bad in any language. Many managers tend to think
> that any problem can be solved by doubling the resources. It is an
> incompetence.
> 
> 
>>"My staff doesn't like Ada and I don't want to force them to use
>>something they don't like because they won't be as productive."
> 
> 
> Honestly, I never met any opposition to Ada from the side of CS
> professionals and programmers. It was always engineers grown to the
> managing positions having no CS background. Though this cannot count as a
> statistical observation, of course.
> 
> 
>>"Industry in general ignores Ada so I can't get the tools I need - or I
>>can only at a much higher cost..."
> 
> 
> It is a silly argument, if one compares the price of a tool with the salary
> of a programmer. The problem is that the advantage of higher productivity
> is not directly seen.
> 
> 
>>"Other, more popular languages, come with things that give me leverage
>>in developing the product I need so I get to market sooner..."
> 
> 
> They also make me dependent on third party products, which quality is
> questionable. A wrong choice may lead to project collapse. [I saw one] A
> certification of all alien software components is very expensive,
> unreliable and delays the project.
> 
> 
>>"I've already got existing software in Language X and all the related
>>things I have to connect to are in Language X, so why do I want to incur
>>the extra cost of using some other language?"
> 
> 
> This is a real argument. Many software houses have home grown libraries etc.
> So I am absolutely on your side, when you are promoting a larger standard
> Ada environment. That could really change the situation here.
> 
> I would also like to see JGNAT revived and more progress in A#.
> 
> 
>>'Ada is a dying language and I need to use something that is going to
>>have a future..."
> 
> 
> I do not think that a manager really cares. Once the project is done, it is
> no matter whether Ada will die or not.
> 
> 
>>There are obviously more but the important thing is that these concerns
>>are *REAL* and *VALID* - if not *TECHNICAL*. So if Ada doesn't want to
>>just slowly go down the toilet, it ought to look to addressing the
>>concerns of that manager voicing those objections. Telling him he's
>>wrong and stupid is only going to get you dismissed as a kook because he
>>*knows* his concerns are legetimate and important. Why not address those
>>concerns and take the language in a new direction that might start
>>alleviating some of them?
> 
> 
> If you reread arguments of your "virtual" manager you will see that most of
> them are related the view on Ada. Improvements of Ada (though I wished
> them) cannot change that. One need a great promotion campaign. One need Ada
> being taught in universities.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > Why you, not being an American, use this luck-based theory, which is
> > proprietary American? -:)
>
> I lost my faith in Karl Marx long time ago! (:-))

Did you also lost faith in Pythagorean theorem after studying non-Euclidian
and differential geometries? I mean, do you believe now that relation between
sides of a triangle depends upon luck only? -:)

> BTW, there is no big difference between the "luck-based" theory and one of
> Marin. Both agree that technical issues are irrelevant. The "luck-based"
> theory stops here. Marin and you continue that probably managers have some
> other [supreme, unknowable] reasons for their choices. Maybe. But this
> changes nothing. And nothing techincal can be made about Ada to change
> that. Because see above, technical issues are irrelevant.

No. At least one major technical issue is relevant - it is anticipated
lifecycle for a product. Long lifecycles are much less influenced by luck
(whatever it means) than short lifecycles. And Ada was specifically designed
for long lifecycles, and what is particularly important here - for anticipated
long lifecycles. (Actually any kind of big volume suppresses influence of
luck - it need not be specifically volume of time.)

> So Java was in the right time at the right place.

This argument - "right time at the right place" is as binded to the Luck
theory (let's call it Luckism -:) as the progressive role of working class
to Marxism.

> > There was real matter that time - dot-coms were booming and there was
> > widespread strong feeling about the need of easily distributable
> > specialized clients for online shopping.

> Mmm, that was 3 years or so later.

3 years or so later you could read about that in newspapers. Application
programmers felt, knew and discussed that need at least 1 year before 
emergence of Java.

> > And this was the trampoline for
> > Java - applets. Then, after several years, dot-com bubble bursted,
> > applets faded,
>
> And of course, we do not ask ourselves, why. Because that would lead us to
> those unloved technical issues...

Well, you are wrong here. We asked ourselves, and not *after*, but before
applets faded - actually when Java specs were published. And at least for
some of us (including me) the answer was clear and purely technical: JVM
appeared a bad virtual machine - plainly bad, by its specs. All other things
(including Java language itself) were secondary, but failure in JVM specs
was certainly irrecoverable. Well, you may ask - why I think (or thought)
that JVM is a bad machine - and I'll answer that if you saw enough various
architectures you should see it yourself, but if not then I can't explain...
I can say only one thing on this matter: if you look at JVM specs without
prior knowlegde about its purpose you have no chance to guess that purpose,
and that's enough.

> Isn't it mysterious, how universities are promoting bad technologies? It was
> C and UNIX before Java.

Well, there are different kinds of promotion of technologies by universities.
For example, I have nothing against Berkeley's promotions of C and Unix
those times - because they really contributed to the techologies thus
obtaining actual experience, and did not just propagate unproven and
obviously suspectible things.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> > Why you, not being an American, use this luck-based theory, which is
>> > proprietary American? -:)
>>
>> I lost my faith in Karl Marx long time ago! (:-))
> 
> Did you also lost faith in Pythagorean theorem after studying
> non-Euclidian and differential geometries? I mean, do you believe now that
> relation between sides of a triangle depends upon luck only? -:)

Science is not a subject of belief! (:-))

>> BTW, there is no big difference between the "luck-based" theory and one
>> of Marin. Both agree that technical issues are irrelevant. The
>> "luck-based" theory stops here. Marin and you continue that probably
>> managers have some other [supreme, unknowable] reasons for their choices.
>> Maybe. But this changes nothing. And nothing techincal can be made about
>> Ada to change that. Because see above, technical issues are irrelevant.
> 
> No. At least one major technical issue is relevant - it is anticipated
> lifecycle for a product.

... only if that is shorter than the "lifecycle" of a manager.

> Long lifecycles are much less influenced by luck
> (whatever it means) than short lifecycles. And Ada was specifically
> designed for long lifecycles, and what is particularly important here -
> for anticipated long lifecycles.

It is a technical argument. Try it on a manager and hear what he will reply.

> (Actually any kind of big volume
> suppresses influence of luck - it need not be specifically volume of
> time.)

If you want to say that market does not work in the case of monopoly, then
you are right. The problem is that the system [of software product
business] has a positive feedback. It natively produces monopolies. Small
noise on the input produces an enormous random output. All that is
summarized by one short word *luck*.

>> So Java was in the right time at the right place.
> 
> This argument - "right time at the right place" is as binded to the Luck
> theory (let's call it Luckism -:) as the progressive role of working class
> to Marxism.

Yes of course.

>> > There was real matter that time - dot-coms were booming and there was
>> > widespread strong feeling about the need of easily distributable
>> > specialized clients for online shopping.
> 
>> Mmm, that was 3 years or so later.
> 
> 3 years or so later you could read about that in newspapers. Application
> programmers felt, knew and discussed that need at least 1 year before
> emergence of Java.

Yes, and this supports "Luckism"! They felt, discussed and what was the
result?

Could fathers of cybernetics imagine VisualBasic crowning their efforts?
(:-))

>> > And this was the trampoline for
>> > Java - applets. Then, after several years, dot-com bubble bursted,
>> > applets faded,
>>
>> And of course, we do not ask ourselves, why. Because that would lead us
>> to those unloved technical issues...
> 
> Well, you are wrong here. We asked ourselves, and not *after*, but before
> applets faded - actually when Java specs were published. And at least for
> some of us (including me) the answer was clear and purely technical: JVM
> appeared a bad virtual machine - plainly bad, by its specs. All other
> things (including Java language itself) were secondary, but failure in JVM
> specs was certainly irrecoverable. Well, you may ask - why I think (or
> thought) that JVM is a bad machine - and I'll answer that if you saw
> enough various architectures you should see it yourself, but if not then I
> can't explain... I can say only one thing on this matter: if you look at
> JVM specs without prior knowlegde about its purpose you have no chance to
> guess that purpose, and that's enough.

See, all this was irrelevant to the success of Java. You may cry that 2x2=4,
but if 2x2=5 sells better it will! "Luckism" teaches us, that in the
equation 2x2=n sells good, n cannot be predicted. (:-))

>> Isn't it mysterious, how universities are promoting bad technologies? It
>> was C and UNIX before Java.
> 
> Well, there are different kinds of promotion of technologies by
> universities. For example, I have nothing against Berkeley's promotions of
> C and Unix those times - because they really contributed to the
> techologies thus obtaining actual experience, and did not just propagate
> unproven and obviously suspectible things.

Come on, UNIX was a great set-back in OS architecture, design and ideology. 
Its spreading was a catastrophe outperformed by only Windows. If someone
could esimate the losses resulting in this twin disaster!

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > Did you also lost faith in Pythagorean theorem after studying
> > non-Euclidian and differential geometries? I mean, do you believe now that
> > relation between sides of a triangle depends upon luck only? -:)
>
> Science is not a subject of belief! (:-))

It is, and always was. Do you, for example, believe in intermediate boson?
Or do you believe that Universe is 7-dimensional? Or do you believe in Big
Bang and in some estimate of the age of Universe (either from modern physics
or from the Bible)? Well, you may think that Pythagorean theorem is true for
some ideal triangles, but do you believe that real triangles, which you can
meet in nature, resemble those ideal ones?

> > At least one major technical issue is relevant - it is anticipated
> > lifecycle for a product.
>
> ... only if that is shorter than the "lifecycle" of a manager.

So the problem is that too many managers prefer *own* short lifecycles, that
is, they are oriented to frequent change of their job.

> Small noise on the input produces an enormous random output. All that is
> summarized by one short word *luck*.

Luckism is a good cover for various calculated clandestine actions.

> >> > There was real matter that time - dot-coms were booming and there was
> >> > widespread strong feeling about the need of easily distributable
> >> > specialized clients for online shopping.
> > 
> >> Mmm, that was 3 years or so later.
> > 
> > 3 years or so later you could read about that in newspapers. Application
> > programmers felt, knew and discussed that need at least 1 year before
> > emergence of Java.
>
> Yes, and this supports "Luckism"!

Not at all.

> They felt, discussed and what was the result?

Hm, it seems that you have too much contacts with managers - that you phrase
sounds too familiar -;) .

> Could fathers of cybernetics imagine VisualBasic crowning their efforts?
> (:-))

Why not? They were quite competent in stochastic matters and behaviour of
large systems.

> UNIX was a great set-back in OS architecture, design and ideology. 

Although I am not a fan of Unix (actually I have very few personal contacts
with it and most of my info about it comes from friends and from reading of
assorted sources) nevertheless I don't see why it should be called as a
setback and even great setback. Unix is (in my view) just based on another
paradigm, which is still not properly abstracted and formalized: Unix is
tools-oriented OS, while competitors (those times) - such OSes as IBM's
OS/370 (and VM/370), DEC's RSX and then VMS were dispatcher-oriented. In
other words the latter gave more direct powers and convenience to system
administrator while Unix gave more powers and convenience to users and
especially to power users (and superusers -:) .

Well, if you wish to compare Unix not with OS/370, RSX and VMS but with
Multics then I can say only that Multics never existed in big real world.
Its users definitely admired it, but there was rather small number of them,
and they even do not seem to be a representative sample of programmer
population - their average skills, motivation and environment were far better
than normal. Academics also loved Multics but nevertheless they did not bother
themselves with carrying its inheritance into the future. So no one knows how
this potentially superior Multics would behave in big real world.

>Its spreading was a catastrophe outperformed by only Windows.

Also for Windows - I don't see any disaster in proliferation of Windows.
Although I do not like this system too much, but I see that it really works
in very dirty world. I do not think that it is easy to develop an OS that
will perform better for the same user base. So I think that in your above
(quoted) sentence the word "disaster" should be related to "spreading" but
not to "Windows". that is, the catastrophe you mentioned is the fact of
access of millions of users to computers, and not a particular OS that
provided that access.

> If someone could esimate the losses resulting in this twin disaster!

Yes, I can: it's a loss of virginity of masses regarding computers.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> > Did you also lost faith in Pythagorean theorem after studying
>> > non-Euclidian and differential geometries? I mean, do you believe now
>> > that relation between sides of a triangle depends upon luck only? -:)
>>
>> Science is not a subject of belief! (:-))
> 
> It is, and always was. Do you, for example, believe in intermediate boson?
> Or do you believe that Universe is 7-dimensional? Or do you believe in Big
> Bang and in some estimate of the age of Universe (either from modern
> physics or from the Bible)?

Ah, no theory can be proved, it can be only disproved. So yes one can only
believe that a particular theory is true. But that is not science. It is
philosophy.

> Well, you may think that Pythagorean theorem
> is true for some ideal triangles, but do you believe that real triangles,
> which you can meet in nature, resemble those ideal ones?

See above. BTW, in the philosophy I believe in (:-)), there is no real
triangles.

>> > At least one major technical issue is relevant - it is anticipated
>> > lifecycle for a product.
>>
>> ... only if that is shorter than the "lifecycle" of a manager.
> 
> So the problem is that too many managers prefer *own* short lifecycles,
> that is, they are oriented to frequent change of their job.

The problem is that the system rewards this.

>> Small noise on the input produces an enormous random output. All that is
>> summarized by one short word *luck*.
> 
> Luckism is a good cover for various calculated clandestine actions.

The hidden parameter theory? (:-)) I am on Bohr's side!

> Hm, it seems that you have too much contacts with managers - that you
> phrase sounds too familiar -;) .

Yes I do. This is why I have no illusions. (:-()

>> UNIX was a great set-back in OS architecture, design and ideology.

[... blaming good OSes for "having no curly brackets" ...]

> that will perform better for the same user base. So I think that in your
> above (quoted) sentence the word "disaster" should be related to
> "spreading" but not to "Windows". that is, the catastrophe you mentioned
> is the fact of access of millions of users to computers, and not a
> particular OS that provided that access.

Isn't it a Marxist's way to blame innocent people for their inability to
work with our "excellent" software? "How they dare open E-mail attachments!
Any PC-user shall have a license for using it. Let's educate them, better,
grow a new Windows-man!"

>> If someone could esimate the losses resulting in this twin disaster!
> 
> Yes, I can: it's a loss of virginity of masses regarding computers.

No it is vasting enormous resources for nothing. It is real, physical
catastrophes yet to come as more and more things become controlled by
software.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> Ah, no theory can be proved, it can be only disproved. So yes one can only
> believe that a particular theory is true. But that is not science. It is
> philosophy.

Well, yes, clear separation of science from philosophy is a nesessary
prerequisite of Luckism. Perhaps Ph.D degrees in appropriate domains should
be renamed to Sc.D (or Sc.Ex - scientific expert).

> >> > At least one major technical issue is relevant - it is anticipated
> >> > lifecycle for a product.
> >>
> >> ... only if that is shorter than the "lifecycle" of a manager.
> > 
> > So the problem is that too many managers prefer *own* short lifecycles,
> > that is, they are oriented to frequent change of their job.
>
> The problem is that the system rewards this.

So we turn to the system and immediately recognize themselves in dangerous
proximity to revolutionaries (because even naming the system is identifying
it as external object, which is certainly at least a kind of hesery for
well-intentioned member of society).

> > Luckism is a good cover for various calculated clandestine actions.
>
> The hidden parameter theory? (:-)) I am on Bohr's side!

So you must be a regular subscriber to the "Journal of Irreproducible Results".

> > Hm, it seems that you have too much contacts with managers - that you
> > phrase sounds too familiar -;) .
>
> Yes I do. This is why I have no illusions. (:-()

You have an illusion that you have no illusions. Having passed this stage
long ago I can tell you that this isn't even meta-illusion - it is just one
of regular illusions... well. slightly more sophisticated than average one.
Nothing wrong in that. though - an illusion is just a sort of viewpoint, and
as such it may be instrumental.

> >> UNIX was a great set-back in OS architecture, design and ideology.
>
> [... blaming good OSes for "having no curly brackets" ...]

Not at all, I did not blame those good OSes for anything. I just stated that
they (except Multics for which I can't say anything definite) were
dispatcher-oriented rather than tools-oriented and thus favored system
administrators vs. users. I do not consider that a blame, because those
preferences were good those times and they adequately reflected the needs of
programmer's community (and I'm not in position to blame those OSes for their
preferences particularly because those times I was no less a senior system
administrator than an application programmer, and it was one of my
responsibilities to organize and control batch- and teleprocessing for
several IBM-clone mainframes and PDP-11 clones).

> > that will perform better for the same user base. So I think that in your
> > above (quoted) sentence the word "disaster" should be related to
> > "spreading" but not to "Windows". that is, the catastrophe you mentioned
> > is the fact of access of millions of users to computers, and not a
> > particular OS that provided that access.
>
> Isn't it a Marxist's way to blame innocent people for their inability to
> work with our "excellent" software?

Well, I don't know about Marxist's way in computing (which class holds a
progressive role?), but I saw those innocent people enough - both as a
system administrator (there I saw innocent programmers) and as an application
programmer (there I saw both innocent suppliers and innocent end users of
information). Those innocent people were often too stupid, easily lying and
sometimes even intentionally damaging cables. They could somehow participate
in a productive job only under a kind of iron rule - executing by either their
managers or by system administration team. But for PCs you have neither the
head of department immediately behind your shoulder nor a system administrator
closely monitoring your resources and your potentially damaging actions. All
you have there is the OS, which can't take into account most of specific
intrications of your personality.

> "How they dare open E-mail attachments!
> Any PC-user shall have a license for using it. Let's educate them, better,
> grow a new Windows-man!"

Do you think that this is an end-user OS issue and not an Internet issue?

> it is vasting enormous resources for nothing.

For nothing? You are really joking. That enormous progress in hardware
(including dramatic decrease of prices) was certainly impossible without
providing OSes for those innocent people, with which they can run their
beloved applications - Word, Excel, typesetting etc., etc - more or less
succesfully.

> It is real, physical
> catastrophes yet to come as more and more things become controlled by
> software.

Certainly. Software will prevent some catastrophes and create others. Just
as any other widespread and powerful technology. So what?



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> Ah, no theory can be proved, it can be only disproved. So yes one can
>> only believe that a particular theory is true. But that is not science.
>> It is philosophy.
> 
> Well, yes, clear separation of science from philosophy is a nesessary
> prerequisite of Luckism. Perhaps Ph.D degrees in appropriate domains
> should be renamed to Sc.D (or Sc.Ex - scientific expert).

exorcist sounds better (:-))

>> >> > At least one major technical issue is relevant - it is anticipated
>> >> > lifecycle for a product.
>> >>
>> >> ... only if that is shorter than the "lifecycle" of a manager.
>> > 
>> > So the problem is that too many managers prefer *own* short lifecycles,
>> > that is, they are oriented to frequent change of their job.
>>
>> The problem is that the system rewards this.
> 
> So we turn to the system and immediately recognize themselves in dangerous
> proximity to revolutionaries (because even naming the system is
> identifying it as external object, which is certainly at least a kind of
> hesery for well-intentioned member of society).

Nope, revolutionaries want to change the system (quickly and bruttaly). I am
just an observer.

>> > Luckism is a good cover for various calculated clandestine actions.
>>
>> The hidden parameter theory? (:-)) I am on Bohr's side!
> 
> So you must be a regular subscriber to the "Journal of Irreproducible
> Results".

I am a MSDN subscriber.

>> > Hm, it seems that you have too much contacts with managers - that you
>> > phrase sounds too familiar -;) .
>>
>> Yes I do. This is why I have no illusions. (:-()
> 
> You have an illusion that you have no illusions. Having passed this stage
> long ago I can tell you that this isn't even meta-illusion - it is just
> one of regular illusions... well. slightly more sophisticated than average
> one. Nothing wrong in that. though - an illusion is just a sort of
> viewpoint, and as such it may be instrumental.

So it is even worse. Or you mean that even managers will be saved? (:-))

>> >> UNIX was a great set-back in OS architecture, design and ideology.
>>
>> [... blaming good OSes for "having no curly brackets" ...]
> 
> Not at all, I did not blame those good OSes for anything. I just stated
> that they (except Multics for which I can't say anything definite) were
> dispatcher-oriented rather than tools-oriented and thus favored system
> administrators vs. users. I do not consider that a blame, because those
> preferences were good those times and they adequately reflected the needs
> of programmer's community (and I'm not in position to blame those OSes for
> their preferences particularly because those times I was no less a senior
> system administrator than an application programmer, and it was one of my
> responsibilities to organize and control batch- and teleprocessing for
> several IBM-clone mainframes and PDP-11 clones).

I do not know what is a tool-oriented OS. Tools are application programs
they are not a part of the OS. OSes twenty years ago were multitasking and
multiuser. They were highly reliable and efficient with respect of memory
and CPU use. They were parallel. They had virtual memory and time sharing.
They provided virtual machines. They had highly integrated IDE and
debuggers. They were networking. They were stable for DoS attacks of all
sorts. What new gave UNIX and Windows to us in recent 20 years, except for
awk and viruses?

>> > that will perform better for the same user base. So I think that in
>> > your above (quoted) sentence the word "disaster" should be related to
>> > "spreading" but not to "Windows". that is, the catastrophe you
>> > mentioned is the fact of access of millions of users to computers, and
>> > not a particular OS that provided that access.
>>
>> Isn't it a Marxist's way to blame innocent people for their inability to
>> work with our "excellent" software?
> 
> Well, I don't know about Marxist's way in computing (which class holds a
> progressive role?), but I saw those innocent people enough - both as a
> system administrator (there I saw innocent programmers) and as an
> application programmer (there I saw both innocent suppliers and innocent
> end users of information). Those innocent people were often too stupid,
> easily lying and sometimes even intentionally damaging cables. They could
> somehow participate in a productive job only under a kind of iron rule -
> executing by either their managers or by system administration team. But
> for PCs you have neither the head of department immediately behind your
> shoulder nor a system administrator closely monitoring your resources and
> your potentially damaging actions. All you have there is the OS, which
> can't take into account most of specific intrications of your personality.

Come on, I never heard of PC users chewing cables. And do not tell me that
PC users are responsible for viruses and spam.

>> "How they dare open E-mail attachments!
>> Any PC-user shall have a license for using it. Let's educate them,
>> better, grow a new Windows-man!"
> 
> Do you think that this is an end-user OS issue and not an Internet issue?

This is one issue. Internet is as good as OSes involved let it to be. What
is the difference between an attachment and a stack of punched cards you
used to feed to an OS-370 machine 30 years ago? Did it crash the system?

>> it is vasting enormous resources for nothing.
> 
> For nothing? You are really joking. That enormous progress in hardware
> (including dramatic decrease of prices) was certainly impossible without
> providing OSes for those innocent people, with which they can run their
> beloved applications - Word, Excel, typesetting etc., etc - more or less
> succesfully.

Is a man running Word the goal of evolution?

>> It is real, physical
>> catastrophes yet to come as more and more things become controlled by
>> software.
> 
> Certainly. Software will prevent some catastrophes and create others. Just
> as any other widespread and powerful technology. So what?

It is absolutely uncontrolled.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> > So the problem is that too many managers prefer *own* short lifecycles,
> >> > that is, they are oriented to frequent change of their job.
> >>
> >> The problem is that the system rewards this.
> > 
> > So we turn to the system and immediately recognize themselves in dangerous
> > proximity to revolutionaries (because even naming the system is
> > identifying it as external object, which is certainly at least a kind of
> > hesery for well-intentioned member of society).
>
> Nope, revolutionaries want to change the system (quickly and bruttaly). I am
> just an observer.

It may be just a starting point; also an observer may serve as a detonator or
catalyst for others.

> even managers will be saved? (:-))

Yes, of course. Today, within the celebration of Orthodox Easter Sunday,
I declare that the managers are among the common people and will be saved,
except those who were permanently succumbed to the Satan thus adding to and
severely aggravating their Original Sin.

> I do not know what is a tool-oriented OS. Tools are application programs
> they are not a part of the OS.

Well. suppose you delete all compilers, utilities and optional services
from OS/370 (or OS/390), and show the rest to a regular IBM mainframe
programmer. I'm sure that s/he will say that it is still OS/370 (or 390).
But if you make the same operation with Unix then, I think, every regular
Unix programmer will say that it isn't Unix at all.
  In more technical terms, Unix pay much more attention (and provides much
more means) to interoperation between separate processes. In classical IBM
mainframe OSes all processes were really separated from each other, and when
a need emerged to establish some kind of cooperation between parallel
processes it always was a pain and required the skills far above the ordinary
programmer's level. And that was right and good approach those times and for
typical applications. In RSX (DEC PDP-11) situation shifted: it became much
easier to establish cooperation between parallel processes (at the cost of
slightly weaker separation), but it still required programmer's skills above
average (although not "far above" any longer). And again, it was right and
good approach for intended applications. In Unix the concept of interprocess
cooperation was made one of central system concepts, and it was made routinely
accessible for all users. It became possible and easy to use tools/utilities
in concert, not in sequential order via external data files.

> OSes twenty years ago were multitasking and multiuser.
Of course, they were.

> They were highly reliable and efficient with respect of memory
> and CPU use. They were parallel. They had virtual memory and time sharing.
> They provided virtual machines. They had highly integrated IDE and
> debuggers.

All that is true.

> They were networking.

They were. But it was not a pleasure. Networking was not a strong side of
those OSes - it was quite expensive and required highly skilled system
administrators, which often weren't available. SNA, and even DECNET looked
like monsters. I think that with those kinds of networking we would still have
Internet in science fiction only. Instead we would have government, military,
financial and perhaps big business networks only. And moreover, perhaps the
world would look otherwise... I know too well about the critical role that
emerging Internet played in the beginning of 90th in collapsing Soviet Union
and (re)starting Russia.

> They were stable for DoS attacks of all sorts.

There were no DoS attacks those times. From where they could be originated?

> What new gave UNIX and Windows to us in recent 20 years, except for
> awk and viruses?

They gave radical extension of user base, which stimulated investments, which,
in turn, stimulates hardware vendors, which results in dramatic decrease of
hardware prices. Well, they did not exactly *gave* us all that, but they
substantially participated in that.

And they gave us many proud young programmers, for good or for bad -;)
Instead of herds of "poor users" (as I remember them from my system
administrator's past). You may say those youngsters are unskilled and even
spoiled in some sense. But at least they are alive, while those "poor users"
of past time (absolute majority of them) were essentially dead.

>> Those innocent people were often too stupid,
>> easily lying and sometimes even intentionally damaging cables.
>...
> Come on, I never heard of PC users chewing cables.

It was in pre-PC time - when IBM mainframes and DEC and HP minis reigned.
I suppose that users of those computers were no less innocent then PC users,
weren't they?

> And do not tell me that
> PC users are responsible for viruses and spam.

Do you really think that all (or most) viruses and spam messages are originated
from non-PC computers... or from PCs but not by their users? Well there is
no need to fight with opinions - just look at job sites (at least .ru job
sites) and observe there explicit requests for spammers. And I guess that you
don't mean that wicked Unix and Windows are capable to *originate* viruses
by themselves, without substantial help of their users.

Anyway, those viruses provided good income for a number of anti-virus vendors,
and besides that they alarmed the public, which is good for parties trying to
put Internet under control. Spam helps the latter purpose too, and besides 
that it is an excellent medium for secret messages.

> >> "How they dare open E-mail attachments!
> >> Any PC-user shall have a license for using it. Let's educate them,
> >> better, grow a new Windows-man!"
> > 
> > Do you think that this is an end-user OS issue and not an Internet issue?
>
> This is one issue. Internet is as good as OSes involved let it to be.

No. end-user OSes are secondary at this stage. There are various standards
(protocols, formats etc.) and backbones - they play primary roles in this
issue.

> What
> is the difference between an attachment and a stack of punched cards you
> used to feed to an OS-370 machine 30 years ago? Did it crash the system?

Well, it did sometimes. Not exactly punched cards stack, but a magnetic tape
(which is, by the way, more proper analogy). I knew several victims of 
carelessness of this kind (on mainframes). There were so-called self-loading
tapes. OS couln't protect itself because it was not in memory when such a
tape was being loaded. A program from the tape accessed system disk and
damaged the system. Old story - do not believe those who claim that viruses
were invented on PC.

> >> It is real, physical
> >> catastrophes yet to come as more and more things become controlled by
> >> software.
> > 
> > Certainly. Software will prevent some catastrophes and create others. Just
> > as any other widespread and powerful technology. So what?
>
> It is absolutely uncontrolled.

No, far from that. Don't panic -:) . There are people scattered on the world
- programmers, engineers, scientists and others... even managers may appear
among them - who are competent, thinking and responsible... and sometimes
feeling responsibity not only for their own piece of work and/or their own
piece of time. And most of them are silent, so in normal circumstances you
will not hear any uproar from them.

And one more remark for the same issue: making a piece of software very
reliable is not necessary a good thing. If this piece is too reliable then
one may rely upon it for an unanticipated, perhaps very bad purpose - and
that piece will serve him, that is, will participate in that you just called 
"uncontrolled".

And anyway, software is still much more effectively controlled than light
weapons, explosives and car traffic (perhaps you know that the latter kills
huge number of people every year... software can't come near that number of
victims in near future).




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> >> > So the problem is that too many managers prefer *own* short
>> >> > lifecycles, that is, they are oriented to frequent change of their
>> >> > job.
>> >>
>> >> The problem is that the system rewards this.
>> > 
>> > So we turn to the system and immediately recognize themselves in
>> > dangerous proximity to revolutionaries (because even naming the system
>> > is identifying it as external object, which is certainly at least a
>> > kind of hesery for well-intentioned member of society).
>>
>> Nope, revolutionaries want to change the system (quickly and bruttaly). I
>> am just an observer.
> 
> It may be just a starting point; also an observer may serve as a detonator
> or catalyst for others.

As we know, a problem has to be solved this or that way.

>> I do not know what is a tool-oriented OS. Tools are application programs
>> they are not a part of the OS.
> 
> Well. suppose you delete all compilers, utilities and optional services
> from OS/370 (or OS/390), and show the rest to a regular IBM mainframe
> programmer. I'm sure that s/he will say that it is still OS/370 (or 390).
> But if you make the same operation with Unix then, I think, every regular
> Unix programmer will say that it isn't Unix at all.

Exactly, because Unix is that sort of half-baked OS. Tools do not replace
the OS. But what UNIX and later Microsoft shown, one can well sell tools
and call them OS.

>   In more technical terms, Unix pay much more attention (and provides much
> more means) to interoperation between separate processes.

You definitely mean fork and copying file descriptors. Indeed, an excellent
way of interoperation.

> In classical IBM
> mainframe OSes all processes were really separated from each other, and
> when a need emerged to establish some kind of cooperation between parallel
> processes it always was a pain and required the skills far above the
> ordinary programmer's level. And that was right and good approach those
> times and for typical applications. In RSX (DEC PDP-11) situation shifted:
> it became much easier to establish cooperation between parallel processes
> (at the cost of slightly weaker separation), but it still required
> programmer's skills above average (although not "far above" any longer).

And you intentionally do not mention VMS which had uncounted ways of inter
process communication.

> And again, it was right and good approach for intended applications. In
> Unix the concept of interprocess cooperation was made one of central
> system concepts, and it was made routinely accessible for all users. It
> became possible and easy to use tools/utilities in concert, not in
> sequential order via external data files.

Come on, in UNIX everything is a file. Even locks are files...

>> OSes twenty years ago were multitasking and multiuser.
> Of course, they were.
> 
>> They were highly reliable and efficient with respect of memory
>> and CPU use. They were parallel. They had virtual memory and time
>> sharing. They provided virtual machines. They had highly integrated IDE
>> and debuggers.
> 
> All that is true.
> 
>> They were networking.
> 
> They were. But it was not a pleasure. Networking was not a strong side of
> those OSes - it was quite expensive and required highly skilled system
> administrators, which often weren't available. SNA, and even DECNET looked
> like monsters. I think that with those kinds of networking we would still
> have Internet in science fiction only.

Yes, we would have one global distributed OO networking system with nodes in
PCs. One would need no ftp to get a file. One would even have no files, but
persistent objects of different types...

> Instead we would have government,
> military, financial and perhaps big business networks only. And moreover,
> perhaps the world would look otherwise... I know too well about the
> critical role that emerging Internet played in the beginning of 90th in
> collapsing Soviet Union and (re)starting Russia.

(:-))

>> They were stable for DoS attacks of all sorts.
> 
> There were no DoS attacks those times. From where they could be
> originated?

In early 90s my friend wrote a one-line program:

for (;;) sbrk (1);

causing Sun-Solaris to stand still. Or consider fork-ing in a cycle until
there were no free slots in the process table. These kinds of DoS attacks
were just impossible under VMS.

>> What new gave UNIX and Windows to us in recent 20 years, except for
>> awk and viruses?
> 
> They gave radical extension of user base, which stimulated investments,
> which, in turn, stimulates hardware vendors, which results in dramatic
> decrease of hardware prices. Well, they did not exactly *gave* us all
> that, but they substantially participated in that.

Which features of UNIX and Windows gave that extension? What makes you think
that LSI-11 under RSX would be worse than IBM PC under CP/M? That extension
would happen anyway, but on a much higher level.

> And they gave us many proud young programmers, for good or for bad -;)
> Instead of herds of "poor users" (as I remember them from my system
> administrator's past). You may say those youngsters are unskilled and even
> spoiled in some sense. But at least they are alive, while those "poor
> users" of past time (absolute majority of them) were essentially dead.

Ah, and they were also dead if not MS-DOS!

>>> Those innocent people were often too stupid,
>>> easily lying and sometimes even intentionally damaging cables.
>>...
>> Come on, I never heard of PC users chewing cables.
> 
> It was in pre-PC time - when IBM mainframes and DEC and HP minis reigned.
> I suppose that users of those computers were no less innocent then PC
> users, weren't they?

No. Being that time a system *manager* you just suffered from the disease
all managers have. (:-))

>> And do not tell me that
>> PC users are responsible for viruses and spam.
> 
> Do you really think that all (or most) viruses and spam messages are
> originated from non-PC computers... or from PCs but not by their users?

No. The problem is that 0.001% of community can produce 60% of mail traffic.
So it is not 99.999% who are responsible, but the system, which allows
that.

> Well there is no need to fight with opinions - just look at job sites (at
> least .ru job sites) and observe there explicit requests for spammers. And
> I guess that you don't mean that wicked Unix and Windows are capable to
> *originate* viruses by themselves, without substantial help of their
> users.

See above. If the OSes and their services were developed at a minimal level
of responsibility there were no way to produce spam in its current volume.
There are elementary ways from prevent that.

> Anyway, those viruses provided good income for a number of anti-virus
> vendors, and besides that they alarmed the public, which is good for
> parties trying to put Internet under control. Spam helps the latter
> purpose too, and besides that it is an excellent medium for secret
> messages.

So you are agree that human resources are just being vasted. That is my
point.

>> >> "How they dare open E-mail attachments!
>> >> Any PC-user shall have a license for using it. Let's educate them,
>> >> better, grow a new Windows-man!"
>> > 
>> > Do you think that this is an end-user OS issue and not an Internet
>> > issue?
>>
>> This is one issue. Internet is as good as OSes involved let it to be.
> 
> No. end-user OSes are secondary at this stage. There are various standards
> (protocols, formats etc.) and backbones - they play primary roles in this
> issue.

This is what I meant.

>> What
>> is the difference between an attachment and a stack of punched cards you
>> used to feed to an OS-370 machine 30 years ago? Did it crash the system?
> 
> Well, it did sometimes. Not exactly punched cards stack, but a magnetic
> tape (which is, by the way, more proper analogy). I knew several victims
> of carelessness of this kind (on mainframes). There were so-called
> self-loading tapes. OS couln't protect itself because it was not in memory
> when such a tape was being loaded. A program from the tape accessed system
> disk and damaged the system. Old story - do not believe those who claim
> that viruses were invented on PC.

A bootable tape is not a virus, not a parasite, but an independent host, so
to say. Of course, boot sector viruses and ones writting into the system
files were impossible even under UNIX. Note also an important difference
between circumventing a protection and absence of any.

>> >> It is real, physical
>> >> catastrophes yet to come as more and more things become controlled by
>> >> software.
>> > 
>> > Certainly. Software will prevent some catastrophes and create others.
>> > Just as any other widespread and powerful technology. So what?
>>
>> It is absolutely uncontrolled.
> 
> No, far from that. Don't panic -:) . There are people scattered on the
> world - programmers, engineers, scientists and others... even managers may
> appear among them - who are competent, thinking and responsible... and
> sometimes feeling responsibity not only for their own piece of work and/or
> their own piece of time. And most of them are silent, so in normal
> circumstances you will not hear any uproar from them.

Neither we will see results of their activity of the shelves of software
shops. Ada is an example.

> And one more remark for the same issue: making a piece of software very
> reliable is not necessary a good thing. If this piece is too reliable then
> one may rely upon it for an unanticipated, perhaps very bad purpose - and
> that piece will serve him, that is, will participate in that you just
> called "uncontrolled".

Should we have build air planes falling apart to prevent 9/11?

> And anyway, software is still much more effectively controlled than light
> weapons, explosives and car traffic (perhaps you know that the latter
> kills huge number of people every year... software can't come near that
> number of victims in near future).

You are joking. To your knowledge, the next generation of cars will have
dozens of contolling computers conntected by up to 6 field buses. Guess
which language will be used to program them? Wellcome into the new bright
world.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> ... Unix is that sort of half-baked OS. Tools do not replace
> the OS. But what UNIX and later Microsoft shown, one can well sell tools
> and call them OS.

Well, half-baked... but weren't half-baked food products popular in
supermarkets? Quite similar situation: making a product from raw components
may be expensive in terms of workforce and time, while turning to a good
restaurant may be expensive in terms of money; at the same time half-baked
products may provide optimal compromise in many cases.

> >   In more technical terms, Unix pay much more attention (and provides much
> > more means) to interoperation between separate processes.
>
> You definitely mean fork and copying file descriptors. Indeed, an excellent
> way of interoperation.

Actually I meant pipes in first place.

> > In classical IBM
> > mainframe OSes all processes were really separated from each other, and
> > when a need emerged to establish some kind of cooperation between parallel
> > processes it always was a pain and required the skills far above the
> > ordinary programmer's level. And that was right and good approach those
> > times and for typical applications. In RSX (DEC PDP-11) situation shifted:
> > it became much easier to establish cooperation between parallel processes
> > (at the cost of slightly weaker separation), but it still required
> > programmer's skills above average (although not "far above" any longer).
>
> And you intentionally do not mention VMS which had uncounted ways of inter
> process communication.

Well, I have no personal experience with VMS, I have read its general docs
but no more. But: 1) VMS appeared (as far as I know) when Unix was already
known and already gained some popularity; 2) VMS ran on VAXes, which were
near mainframes (well, somewhere between mainframes and minis) in many
aspects, including cost and availability; 3) VMS was not portable in any
sense.

I think (from the docs I have read and other assorted sources) that VMS was
quite good OS, although some of its features surprised me by their seemingly
unnecesessary complications, for example a mixture of rollin/rollout with
virtual memory.

But nobody, including DEC, did attempt to give this OS an independent status,
that is, to loosen its dependance upon VAXes. And subsequent MicroVAXes weren't
too successful and widespread. 

What followed was Cutler's migration to Microsoft and then appearance of 
Windows NT. It was said once (or more than once) that Windows NT has the
heart of VMS, legs of Unix and the face of Windows. Not discussing here the
"legs" and "face", I believe that metaphor for the heart had some grounds.

The bottom line of that VMS story is that DEC did not qualify to true
heavyweight and therefore was unable to maintain strong influence in the
wide market (like IBM did), and at the same time it did not let competitors
to use the potential of VMS another way that letting Cutler to go to MS.

> > In
> > Unix the concept of interprocess cooperation was made one of central
> > system concepts, and it was made routinely accessible for all users. It
> > became possible and easy to use tools/utilities in concert, not in
> > sequential order via external data files.
>
> Come on, in UNIX everything is a file. Even locks are files...

Regargless of what is was at the system level, for an application programmer
the concept usually was a stream.

> > Networking was not a strong side of
> > those OSes - it was quite expensive and required highly skilled system
> > administrators, which often weren't available. SNA, and even DECNET looked
> > like monsters. I think that with those kinds of networking we would still
> > have Internet in science fiction only.
>
> Yes, we would have one global distributed OO networking system with nodes in
> PCs. One would need no ftp to get a file. One would even have no files, but
> persistent objects of different types...

Besides that this is a hardcore idealistic dream, this means that regular
users would be deprived from the basic low-level abstraction.

> >> What new gave UNIX and Windows to us in recent 20 years, except for
> >> awk and viruses?
> > 
> > They gave radical extension of user base, which stimulated investments,
> > which, in turn, stimulates hardware vendors, which results in dramatic
> > decrease of hardware prices. Well, they did not exactly *gave* us all
> > that, but they substantially participated in that.
>
> Which features of UNIX and Windows gave that extension?

Availability of these OSes and accessability of the features, which are/were
important for general/mass end-users and corresponding applications. A quality
in strictly software engineering sense was not among those features simply
because it was not among the most important things for that audience.

> What makes you think
> that LSI-11 under RSX would be worse than IBM PC under CP/M?

At the same price and quantities? Perhaps it would be better. Even RSX was
not necessary - more restricted and simple TSX would be better choice for
many beginners. But it was not there at these conditions. 

> That extension would happen anyway, but on a much higher level.

This is a pure guess, and I think it is wrong guess. Anyway, we aren't going
to rewrite history.

> >>> Those innocent people were often too stupid,
> >>> easily lying and sometimes even intentionally damaging cables.
> >>...
> >> Come on, I never heard of PC users chewing cables.
> > 
> > It was in pre-PC time - when IBM mainframes and DEC and HP minis reigned.
> > I suppose that users of those computers were no less innocent then PC
> > users, weren't they?
>
> No. Being that time a system *manager* you just suffered from the disease
> all managers have. (:-))

Well, I see, you never seen intentionally damaged cables, and you find it
hard to believe in that. You find it easier to assume that the teller simply
suffered from the Manager Disease or UserPhobia. The concept of innocent users
appears more important then other things.

> The problem is that 0.001% of community can produce 60% of mail traffic.
> So it is not 99.999% who are responsible, but the system, which allows
> that.

The "system", which allows that is not Windows or Unix but the Internet.

> If the OSes and their services were developed at a minimal level
> of responsibility there were no way to produce spam in its current volume.
> There are elementary ways from prevent that.

I don't know which elementary ways you mean, but I'm sure that at least at
the current stage, any elementary way of that kind that will not broke the
service to the end, will be immediately circumvented.

> > And anyway, software is still much more effectively controlled than light
> > weapons, explosives and car traffic (perhaps you know that the latter
> > kills huge number of people every year... software can't come near that
> > number of victims in near future).
>
> You are joking.

Strange. How can I be joking about million of car accident victims (worldwide)
every year?

> To your knowledge, the next generation of cars will have
> dozens of contolling computers conntected by up to 6 field buses. Guess
> which language will be used to program them?

I have read something about MISRA-C regarding this matter. But I think that
language is irrelevant there. Just as sex, race or average age of programmers.
There are much more important issues in the case. For example, will be car
vendors required to publish full sources of the software used in their cars?



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> ... Unix is that sort of half-baked OS. Tools do not replace
>> the OS. But what UNIX and later Microsoft shown, one can well sell tools
>> and call them OS.
> 
> Well, half-baked... but weren't half-baked food products popular in
> supermarkets?

Exactly. Are half-baked products healthy?

> Quite similar situation: making a product from raw
> components may be expensive in terms of workforce and time, while turning
> to a good restaurant may be expensive in terms of money; at the same time
> half-baked products may provide optimal compromise in many cases.

I would not call having no other choice a compromise.

>> >   In more technical terms, Unix pay much more attention (and provides
>> >   much
>> > more means) to interoperation between separate processes.
>>
>> You definitely mean fork and copying file descriptors. Indeed, an
>> excellent way of interoperation.
> 
> Actually I meant pipes in first place.

No matter. In a classical UNIX you would create a pipe file first and then
fork, the descriptor is copied and here you are. A pretty idiotic way, IMO.

>> > In classical IBM
>> > mainframe OSes all processes were really separated from each other, and
>> > when a need emerged to establish some kind of cooperation between
>> > parallel processes it always was a pain and required the skills far
>> > above the ordinary programmer's level. And that was right and good
>> > approach those times and for typical applications. In RSX (DEC PDP-11)
>> > situation shifted: it became much easier to establish cooperation
>> > between parallel processes (at the cost of slightly weaker separation),
>> > but it still required programmer's skills above average (although not
>> > "far above" any longer).
>>
>> And you intentionally do not mention VMS which had uncounted ways of
>> inter process communication.
> 
> Well, I have no personal experience with VMS, I have read its general docs
> but no more. But: 1) VMS appeared (as far as I know) when Unix was already
> known and already gained some popularity;

Huh, there was ULTRIX for VAX, guess who wished to use it?

> 2) VMS ran on VAXes, which were
> near mainframes (well, somewhere between mainframes and minis) in many
> aspects, including cost and availability;

There was microVAX. As for costs, that was management choice, which ruined
DEC.

> 3) VMS was not portable in any sense.

It is not a property of OS. VMS could be implemented on any platform and if
they wrote it in Ada... (:-))

> I think (from the docs I have read and other assorted sources) that VMS
> was quite good OS, although some of its features surprised me by their
> seemingly unnecesessary complications, for example a mixture of
> rollin/rollout with virtual memory.
> 
> But nobody, including DEC, did attempt to give this OS an independent
> status, that is, to loosen its dependance upon VAXes. And subsequent
> MicroVAXes weren't too successful and widespread.

Mismanagement, the key point of the discussion. DEC had the best operating
system, the best hardware, the best compilers and tools (remember DEC Ada
and LSE). And lo and behold, where it is now. The system worked first for
UNIX and then Microsoft, because latter were even worse than UNIX.

> What followed was Cutler's migration to Microsoft and then appearance of
> Windows NT. It was said once (or more than once) that Windows NT has the
> heart of VMS, legs of Unix and the face of Windows. Not discussing here
> the "legs" and "face", I believe that metaphor for the heart had some
> grounds.

Heart pacemaker would be more appropriate.

> The bottom line of that VMS story is that DEC did not qualify to true
> heavyweight and therefore was unable to maintain strong influence in the
> wide market (like IBM did), and at the same time it did not let
> competitors to use the potential of VMS another way that letting Cutler to
> go to MS.

And MS in its early days was heavyweight?

>> > In
>> > Unix the concept of interprocess cooperation was made one of central
>> > system concepts, and it was made routinely accessible for all users. It
>> > became possible and easy to use tools/utilities in concert, not in
>> > sequential order via external data files.
>>
>> Come on, in UNIX everything is a file. Even locks are files...
> 
> Regargless of what is was at the system level, for an application
> programmer the concept usually was a stream.

Who is using streams for communication for interprocess now? We are using
APIs, mutexes, shared regions, events instead. Only in Internet, because
see previous posts, we are using stream-based protocols.

>> > Networking was not a strong side of
>> > those OSes - it was quite expensive and required highly skilled system
>> > administrators, which often weren't available. SNA, and even DECNET
>> > looked like monsters. I think that with those kinds of networking we
>> > would still have Internet in science fiction only.
>>
>> Yes, we would have one global distributed OO networking system with nodes
>> in PCs. One would need no ftp to get a file. One would even have no
>> files, but persistent objects of different types...
> 
> Besides that this is a hardcore idealistic dream,

It is not a dream. It is pretty doable, but not sellable.

> this means that regular
> users would be deprived from the basic low-level abstraction.

No more than Ada depriving programmers from *p++;

>> >> What new gave UNIX and Windows to us in recent 20 years, except for
>> >> awk and viruses?
>> > 
>> > They gave radical extension of user base, which stimulated investments,
>> > which, in turn, stimulates hardware vendors, which results in dramatic
>> > decrease of hardware prices. Well, they did not exactly *gave* us all
>> > that, but they substantially participated in that.
>>
>> Which features of UNIX and Windows gave that extension?
> 
> Availability of these OSes and accessability of the features, which
> are/were important for general/mass end-users and corresponding
> applications. A quality in strictly software engineering sense was not
> among those features simply because it was not among the most important
> things for that audience.

See, technical ussues are irrelevant.

>> What makes you think
>> that LSI-11 under RSX would be worse than IBM PC under CP/M?
> 
> At the same price and quantities?

Is that a technical problem?

> Perhaps it would be better. Even RSX was
> not necessary - more restricted and simple TSX would be better choice for
> many beginners. But it was not there at these conditions.

The point is that the idea to start with a crap and then level it to a
quality product *never* ever worked for software. What you are starting
with is what you get in the end. We started with CP/M and now, decades
later, it is still CP/M, though maybe containing no single line of its
original code!

>> That extension would happen anyway, but on a much higher level.
> 
> This is a pure guess, and I think it is wrong guess. Anyway, we aren't
> going to rewrite history.

Alas

>> The problem is that 0.001% of community can produce 60% of mail traffic.
>> So it is not 99.999% who are responsible, but the system, which allows
>> that.
> 
> The "system", which allows that is not Windows or Unix but the Internet.

The Internet was *shaped* by UNIX and later Windows. It is as good as OSes
involved allow it to be, especially by the ideology ignoring quality as
irrelevant.

>> If the OSes and their services were developed at a minimal level
>> of responsibility there were no way to produce spam in its current
>> volume. There are elementary ways from prevent that.
> 
> I don't know which elementary ways you mean, but I'm sure that at least at
> the current stage, any elementary way of that kind that will not broke the
> service to the end, will be immediately circumvented.

There are thousands of ways. Just attach an ID to any mail source and limit
the amount of mail generated by a source by some limit per day. The IDs can
be made unique, provider-local, untrackable. If a provider refuses to
conform then instead of being mail "relayer" it becomes a "source".

>> > And anyway, software is still much more effectively controlled than
>> > light weapons, explosives and car traffic (perhaps you know that the
>> > latter kills huge number of people every year... software can't come
>> > near that number of victims in near future).
>>
>> You are joking.
> 
> Strange. How can I be joking about million of car accident victims
> (worldwide) every year?

Because human fault /= software fault. When you make a car accident you are
liable. Who is, when a program crashes? Right, the program, and nobody
else.

>> To your knowledge, the next generation of cars will have
>> dozens of contolling computers conntected by up to 6 field buses. Guess
>> which language will be used to program them?
> 
> I have read something about MISRA-C regarding this matter. But I think
> that language is irrelevant there.

Its choice is relevant. It is an indicator of how seriosly people are going
to make their job.

> Just as sex, race or average age of
> programmers. There are much more important issues in the case. For
> example, will be car vendors required to publish full sources of the
> software used in their cars?

What for? To laugh at? How would it help the society of incompetence? C is a
consequence, not the problem.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> In a classical UNIX you would create a pipe file first and then
> fork, the descriptor is copied and here you are. A pretty idiotic way, IMO.

When you use pipes within a shell you may know nothing about "fork". And that
(and similar cases) is what I meant in first place.

> there was ULTRIX for VAX, guess who wished to use it?

I had no close contacts with VAX community, but I have heard not once that
Ultrix had some popularity, In one time it was even regarded by some people
as the best Unix of that time.

> There was microVAX. As for costs, that was management choice,

Not purely management choice, though. There was a range to choose within it,
but that range certainly did not start from zero.

> 3) VMS was not portable in any sense.

> It is not a property of OS. VMS could be implemented on any platform and if
> they wrote it in Ada... (:-))

Well, Cutler once publicly regretted that VMS was written in assembly language
and not in a portable language (perhaps he meant C, but I dont't know).

As for your statement that VMS could be implemented on any platform, this is
simply false. For example, do you really think that VMS could be implemented
on early IBM PC (with 8086, 640 Kb memory and 5-10 Mb disk)? Or, 20 years
later, on Palm handhelds?

> DEC had the best operating system,

Your previous statements imply that you mean VMS here. But some people those 
times liked TOPS-10/20 (also DEC's) much better. And Multics users most
probably would not agree with you.

> the best hardware,

It is disputable. Good doesn't mean the best. My own impression after reading
VAX hardware handbook was that the instruction set (as well as some particular
instructions) is overcomplicated. That gorgeous instruction set was perhaps
justified by the targetted application domain, which I thought was CADs, but 
nevertheless I don't see a reason to call this hardware architecture "the best".

> the best compilers

I can't agree with this claim. Their COBOL was probably weaker then IBM COBOL,
their PL/I was probably (I didn't try it, but I have read some docs) weaker
than IBM's PL/I Optimizer/Checkout pair, their Fortan IV was not better
than IBM Fortran H (although for Fortran 77 the situation possibly was in
favor of DEC).

Although I agree that DEC had quite good collection of compilers for VAX/VMS,
and some of them probably were be among the best. 

> The system worked first for
> UNIX and then Microsoft, because latter were even worse than UNIX.

You continue to ignore the fact that the population of users was radically
changed. It is your beloved market, with which aristocracy/nobility naturally
faded as the market widened.

> And MS in its early days was heavyweight?

MS in its early days was fully backed by IBM, didn't you know?

> >> we would have one global distributed OO networking system with nodes
> >> in PCs. One would need no ftp to get a file. One would even have no
> >> files, but persistent objects of different types...
> > 
> > Besides that this is a hardcore idealistic dream,
>
> It is not a dream. It is pretty doable, but not sellable.

The dream is that that was doable decades ago. Whether it is doable now -
we shall see relatively soon: development of more or less serious grids is
in progress.

> >> Which features of UNIX and Windows gave that extension?
> > 
> > Availability of these OSes and accessability of the features, which
> > are/were important for general/mass end-users and corresponding
> > applications. A quality in strictly software engineering sense was not
> > among those features simply because it was not among the most important
> > things for that audience.
>
> See, technical ussues are irrelevant.

A technical issue doesn't become relevant automatically, just as a consequence
of its technical status. Perhaps you knew that it was considered not important
for Soviet tanks to have the motor resource more than a few dozens hours.

> >> What makes you think
> >> that LSI-11 under RSX would be worse than IBM PC under CP/M?
> > 
> > At the same price and quantities?
>
> Is that a technical problem?

Surely it is. Do you think that materials, components and production work and
production equipment naturally cost nothing, and it is entirely management's
plays that determine the prices?

> The Internet was *shaped* by UNIX and later Windows.

But why it was not shaped by IBM mainframe OSes, PDP-11 RSX, VAX/VMS and other
noble systems? Do you think that this is just bad luck?

> >> If the OSes and their services were developed at a minimal level
> >> of responsibility there were no way to produce spam in its current
> >> volume. There are elementary ways from prevent that.
> > 
> > I don't know which elementary ways you mean, but I'm sure that at least at
> > the current stage, any elementary way of that kind that will not broke the
> > service to the end, will be immediately circumvented.
>
> There are thousands of ways. Just attach an ID to any mail source and limit
> the amount of mail generated by a source by some limit per day. The IDs can
> be made unique, provider-local, untrackable. If a provider refuses to
> conform then instead of being mail "relayer" it becomes a "source".

Good for China. Perhaps will more or less work for few European countries
(for other reasons). But that's all - it can't work for the whole world and
many individual countries without many additional rules and devices, which
have to be supported not just by end-user OSes (which is trivial addition to
any OS), but by real nation-scale and world-scale forces, which is problematic. 

> >> > And anyway, software is still much more effectively controlled than
> >> > light weapons, explosives and car traffic (perhaps you know that the
> >> > latter kills huge number of people every year... software can't come
> >> > near that number of victims in near future).
> >>
> >> You are joking.
> > 
> > Strange. How can I be joking about million of car accident victims
> > (worldwide) every year?
>
> Because human fault /= software fault. When you make a car accident you are
> liable. Who is, when a program crashes? Right, the program, and nobody
> else.

I can't get you here: do you think that a car itself (that is, by its own
failures - mechanical and other) can't cause an accident without a crucial
participation of a human (driver) or (in the future) of the car's internal
software?

By the way, don't you think (according to the logic you applied the Internet)
that the construction of a car shaped driver's behaviour and traffic patterns?

> > There are much more important issues in the case. For
> > example, will be car vendors required to publish full sources of the
> > software used in their cars?
>
> What for? To laugh at?

There are enough people in the world who know cars and at the same have some
programmer skills. Some of them may become interested in studying those
sources (of their own car's software, for example). It may constitute very
significant resource for finding remaining bugs and glitches.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:

> I had no close contacts with VAX community, but I have heard not once that
> Ultrix had some popularity, In one time it was even regarded by some
> people as the best Unix of that time.

Yep, DEC was good in making software, which led it to downfall.

>> There was microVAX. As for costs, that was management choice,
> 
> Not purely management choice, though. There was a range to choose within
> it, but that range certainly did not start from zero.

If I correctly remember, Olson said that nobody would need a computer at
home. DEC's policy was to promote the nonsense of the "best
perfomance/price relation" instead of giving VAXes to universities for free
and selling DEC Proffessional for a reasonable price.

>> 3) VMS was not portable in any sense.
> 
>> It is not a property of OS. VMS could be implemented on any platform and
>> if they wrote it in Ada... (:-))
> 
> Well, Cutler once publicly regretted that VMS was written in assembly
> language and not in a portable language (perhaps he meant C, but I dont't
> know).
> 
> As for your statement that VMS could be implemented on any platform, this
> is simply false. For example, do you really think that VMS could be
> implemented on early IBM PC (with 8086, 640 Kb memory and 5-10 Mb disk)?
> Or, 20 years later, on Palm handhelds?

To your knowledge, I worked under RSX-11M running on a machine, which had
256K RAM, 2 x 1.5Mb HD disks and sort of 0.3MHz. That machine supported 2
interactive users.

>> DEC had the best operating system,
> 
> Your previous statements imply that you mean VMS here. But some people
> those times liked TOPS-10/20 (also DEC's) much better. And Multics users
> most probably would not agree with you.

Sounds as if we all were using Multics! It is less relevant which OS was the
best, the problem is that the worst won.

>> the best hardware,
> 
> It is disputable. Good doesn't mean the best. My own impression after
> reading VAX hardware handbook was that the instruction set (as well as
> some particular instructions) is overcomplicated. That gorgeous
> instruction set was perhaps justified by the targetted application domain,
> which I thought was CADs, but nevertheless I don't see a reason to call
> this hardware architecture "the best".

Just compare PDP-11 instruction set with other CISCs like x86 or Motorola.
[VAX instruction set is an extension of PDP-11.] Actually, MACRO-11
(PDP/VAX assembler) was a higher level language than C. I believe that
PDP-11 instruction set was rewarded in a contest as the best one.

>> the best compilers
> 
> I can't agree with this claim. Their COBOL was probably weaker then IBM
> COBOL, their PL/I was probably (I didn't try it, but I have read some
> docs) weaker than IBM's PL/I Optimizer/Checkout pair, their Fortan IV was
> not better than IBM Fortran H (although for Fortran 77 the situation
> possibly was in favor of DEC).

I do not know COBOL, but IBM PL/1 was not that good, because different
compiler modes implemented different language subsets. I never had any
problems with DEC Fortran IV. It was excellent. As for DEC C and DEC Ada
they were definitively the best at that time. DEC C gave you a meaningfull
error message when you forgot a }-bracket. That was a revolution, in C
compilers! (:-)) I remember first PC Pascal, which had nearly one error
message "error in expression". (:-))

>> The system worked first for
>> UNIX and then Microsoft, because latter were even worse than UNIX.
> 
> You continue to ignore the fact that the population of users was radically
> changed. It is your beloved market, with which aristocracy/nobility
> naturally faded as the market widened.

As I said, the problem is that the marked, beloved or not, does not work
well for software. This is the only reason why even less beloved government
should intervene. Because software is essential to the future of humankind.

>> And MS in its early days was heavyweight?
> 
> MS in its early days was fully backed by IBM, didn't you know?

You mean that IBM invested in MS?

>> >> Which features of UNIX and Windows gave that extension?
>> > 
>> > Availability of these OSes and accessability of the features, which
>> > are/were important for general/mass end-users and corresponding
>> > applications. A quality in strictly software engineering sense was not
>> > among those features simply because it was not among the most important
>> > things for that audience.
>>
>> See, technical ussues are irrelevant.
> 
> A technical issue doesn't become relevant automatically, just as a
> consequence of its technical status.

And this is exactly the problem I am talking about.

>> The Internet was *shaped* by UNIX and later Windows.
> 
> But why it was not shaped by IBM mainframe OSes, PDP-11 RSX, VAX/VMS and
> other noble systems? Do you think that this is just bad luck?

Yes.

>> >> If the OSes and their services were developed at a minimal level
>> >> of responsibility there were no way to produce spam in its current
>> >> volume. There are elementary ways from prevent that.
>> > 
>> > I don't know which elementary ways you mean, but I'm sure that at least
>> > at the current stage, any elementary way of that kind that will not
>> > broke the service to the end, will be immediately circumvented.
>>
>> There are thousands of ways. Just attach an ID to any mail source and
>> limit the amount of mail generated by a source by some limit per day. The
>> IDs can be made unique, provider-local, untrackable. If a provider
>> refuses to conform then instead of being mail "relayer" it becomes a
>> "source".
> 
> Good for China. Perhaps will more or less work for few European countries
> (for other reasons). But that's all - it can't work for the whole world
> and many individual countries without many additional rules and devices,
> which have to be supported not just by end-user OSes (which is trivial
> addition to any OS), but by real nation-scale and world-scale forces,
> which is problematic.

And again, this is just another statement that technical issues are
irrelevant.

>> >> > And anyway, software is still much more effectively controlled than
>> >> > light weapons, explosives and car traffic (perhaps you know that the
>> >> > latter kills huge number of people every year... software can't come
>> >> > near that number of victims in near future).
>> >>
>> >> You are joking.
>> > 
>> > Strange. How can I be joking about million of car accident victims
>> > (worldwide) every year?
>>
>> Because human fault /= software fault. When you make a car accident you
>> are liable. Who is, when a program crashes? Right, the program, and
>> nobody else.
> 
> I can't get you here: do you think that a car itself (that is, by its own
> failures - mechanical and other) can't cause an accident without a crucial
> participation of a human (driver) or (in the future) of the car's internal
> software?

If that is a construction defect then the car producer is liable. If it was
the driver's fault, then the driver is liable. There is always a human
being to send to jail. For software it isn't so.

> By the way, don't you think (according to the logic you applied the
> Internet) that the construction of a car shaped driver's behaviour and
> traffic patterns?

Surely. If cars could fly, we would have no highways.

>> > There are much more important issues in the case. For
>> > example, will be car vendors required to publish full sources of the
>> > software used in their cars?
>>
>> What for? To laugh at?
> 
> There are enough people in the world who know cars and at the same have
> some programmer skills. Some of them may become interested in studying
> those sources (of their own car's software, for example). It may
> constitute very significant resource for finding remaining bugs and
> glitches.

So the system of that complexity should be controlled by a crowd of
hobbists? Excellent. The next step would be to adopt this for aircrafts,
nuclear reactors and weapon systems!

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Wes Groleau]

Dmitry A. Kazakov wrote:
> compilers! (:-)) I remember first PC Pascal, which had nearly one error
> message "error in expression". (:-))

CP/M:

"BDOS error on C:"

let's try verbose mode...

"BDOS error on C: Select"

:-)

-- 
Wes Groleau

    "A man with an experience is never
     at the mercy of a man with an argument."
                       -- Ron Allen

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > As for your statement that VMS could be implemented on any platform, this
> > is simply false. For example, do you really think that VMS could be
> > implemented on early IBM PC (with 8086, 640 Kb memory and 5-10 Mb disk)?
> > Or, 20 years later, on Palm handhelds?
>
> To your knowledge, I worked under RSX-11M running on a machine, which had
> 256K RAM, 2 x 1.5Mb HD disks and sort of 0.3MHz. That machine supported 2
> interactive users.

No problem with that, assuming that your disks weren't fixed (so you may
change cassetes), you had technicians not far away from the computer, and
your applications were of particular domain (one of those domains targetted
by PDP-11). I developed (well, I was the team leader of a small team) software
for taxi call center on and for very similar machine (disks became bigger
after some time), and it was running successfully for several years (about
10-15 terminals active in peak periods - that time there was only one taxi
call center for 5-million Leningrad).

But I asked you not about RSX-11M, and even not about RSX-11M-PLUS, but about
VMS. And not on PDP-11 (which, after all, had memory dispatcher, and even
I-D space for some models), but on early IBM PC or Palm handhelds.

> >> the best hardware,
> > 
> > It is disputable. Good doesn't mean the best. My own impression after
> > reading VAX hardware handbook was that the instruction set (as well as
> > some particular instructions) is overcomplicated. That gorgeous
> > instruction set was perhaps justified by the targetted application domain,
> > which I thought was CADs, but nevertheless I don't see a reason to call
> > this hardware architecture "the best".
>
> Just compare PDP-11 instruction set with other CISCs like x86 or Motorola.

Why should I compare it with x86 or Motorola? I naturally compared it with
IBM/370, and I was not very happy with that transition. I understood, though,
that targetted application domains are different, and that justified the
difference in architectures. I also compared it with HP minis, and found
PDP-11 architecture much more attractive and powerful.

>[VAX instruction set is an extension of PDP-11.]

Yes, but very far fetched extension. And some elements of that extension
seemed doubful to me.

> Actually, MACRO-11
> (PDP/VAX assembler) was a higher level language than C. I believe that
> PDP-11 instruction set was rewarded in a contest as the best one.

I guess that you was raised as a programmer on PDP-11. What you just said is
quite typical to programmers for whom PDP-11 was first computer to which they
obtain real access. My impression was quite different, as I compared Macro-11
with IBM Assembler H.

> IBM PL/1 was not that good, because different
> compiler modes implemented different language subsets.

I don't know what you mean here: PL/I Optimizer and PL/I Checkout were quite
compatible with each other. If you mean PL/I F then it is improper comparison,
because PL/I F was considered obsolete after release of PL/I Optimizer. But
if you actually mean some compiler modes for PL/I Optimizer then I can't
recall what they could be, and what could be bad with different language
subsets (if they constitute a tower).

> I never had any
> problems with DEC Fortran IV. It was excellent.

I said nothing against DEC Fortran IV, I just said that was not better than
IBM Fortran H.

> As for DEC C and DEC Ada
> they were definitively the best at that time.

Perhaps. As far as I know IBM did not develop own compilers for this languages
that time, so there were no competitors (in compilers) of equal or bigger
weight.

> >> The system worked first for
> >> UNIX and then Microsoft, because latter were even worse than UNIX.
> > 
> > You continue to ignore the fact that the population of users was radically
> > changed. It is your beloved market, with which aristocracy/nobility
> > naturally faded as the market widened.
>
> As I said, the problem is that the marked, beloved or not, does not work
> well for software.

Hm, but for what is works better? For science? For fims? For literature?

> This is the only reason why even less beloved government
> should intervene. Because software is essential to the future of humankind.

So you think (applying the same logic) that government should intervene in
science, in some arts and all other matters which we (or it) find essential
to humankind. By the way, from where you know about the future of humankind?
Did you have a revelation?

> >> And MS in its early days was heavyweight?
> > 
> > MS in its early days was fully backed by IBM, didn't you know?
>
> You mean that IBM invested in MS?

It is hard to believe that you know absolutely nothing about early story of
MS-DOS. Windows and OS/2. But if it so then I'm not going to tell you that
story - it is too well-known, just consult the Net.

> >> > There are much more important issues in the case. For
> >> > example, will be car vendors required to publish full sources of the
> >> > software used in their cars?
> >>
> >> What for? To laugh at?
> > 
> > There are enough people in the world who know cars and at the same have
> > some programmer skills. Some of them may become interested in studying
> > those sources (of their own car's software, for example). It may
> > constitute very significant resource for finding remaining bugs and
> > glitches.
>
> So the system of that complexity should be controlled by a crowd of
> hobbists?

Controlled? Is GNAT controlled by the crowd of hobbyists who have an easy
opportunity to read its sources?

But anyway, in the case of cars, I'd like to tell you that in that crowd of
hobbyists, easily can happen people who are more skilled in software, and even
in complex software, than the software engineering personnel that developed
the car's software. Those skilled people may have an interesting reason to
look at the sources: they may own the car. Just as Boeing engineer may become
interested in some construction details of a small piston single airplane,
which he owns. Imagine that, say, a Cisco engineer or former DEC engineer
becomes suspecting that some sporadic trouble in his own car is caused by a
software glitch. Then, there are graduate students (EE and CS), and some part 
of them are already better skilled then some part of that car software
development personnel - and they also often own cars.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> > As for your statement that VMS could be implemented on any platform,
>> > this is simply false. For example, do you really think that VMS could
>> > be implemented on early IBM PC (with 8086, 640 Kb memory and 5-10 Mb
>> > disk)? Or, 20 years later, on Palm handhelds?
>>
>> To your knowledge, I worked under RSX-11M running on a machine, which had
>> 256K RAM, 2 x 1.5Mb HD disks and sort of 0.3MHz. That machine supported 2
>> interactive users.
> 
> No problem with that, assuming that your disks weren't fixed (so you may
> change cassetes), you had technicians not far away from the computer, and
> your applications were of particular domain (one of those domains
> targetted by PDP-11). I developed (well, I was the team leader of a small
> team) software for taxi call center on and for very similar machine (disks
> became bigger after some time), and it was running successfully for
> several years (about 10-15 terminals active in peak periods - that time
> there was only one taxi call center for 5-million Leningrad).
> 
> But I asked you not about RSX-11M, and even not about RSX-11M-PLUS, but
> about VMS. And not on PDP-11 (which, after all, had memory dispatcher, and
> even I-D space for some models), but on early IBM PC or Palm handhelds.

I'd consider RSX and PDP compatible as a natural opposition to MS-DOS and
IBM PC. So it is unfair to compare the latter with VAX/VMS. However I
remember a VAX compatible under VMS have 1-2Mb and 2x24MB disks. It
supported 6 users.

>> Actually, MACRO-11
>> (PDP/VAX assembler) was a higher level language than C. I believe that
>> PDP-11 instruction set was rewarded in a contest as the best one.
> 
> I guess that you was raised as a programmer on PDP-11. What you just said
> is quite typical to programmers for whom PDP-11 was first computer to
> which they obtain real access. My impression was quite different, as I
> compared Macro-11 with IBM Assembler H.

No I started with IBM 360/70, TSO and some other interactive system for IBM,
which name I cannot recall. Then switched to PDP.

I knew no programmer who liked IBM assembler. You should a rare exception.

>> As for DEC C and DEC Ada
>> they were definitively the best at that time.
> 
> Perhaps. As far as I know IBM did not develop own compilers for this
> languages that time, so there were no competitors (in compilers) of equal
> or bigger weight.

There was a disgusting C compiler for Sun workstations. There was one, I
guess from Motorola, no less bad. There were first GCC attempts.

>> As I said, the problem is that the marked, beloved or not, does not work
>> well for software.
> 
> Hm, but for what is works better? For science? For fims? For literature?

You have admitted that there is a problem.

>> This is the only reason why even less beloved government
>> should intervene. Because software is essential to the future of
>> humankind.
> 
> So you think (applying the same logic) that government should intervene in
> science,

Doesn't it? Or do you think that space program is sponsored by Microsoft?

> in some arts

Who pays for those museums and theatres? If you want to check what kind of
art the market selects turn on MTV.

> and all other matters which we (or it) find
> essential to humankind. By the way, from where you know about the future
> of humankind? Did you have a revelation?

No, I just have an experience that Ada is better than C++.

>> >> And MS in its early days was heavyweight?
>> > 
>> > MS in its early days was fully backed by IBM, didn't you know?
>>
>> You mean that IBM invested in MS?
> 
> It is hard to believe that you know absolutely nothing about early story
> of MS-DOS. Windows and OS/2. But if it so then I'm not going to tell you
> that story - it is too well-known, just consult the Net.

Then you should probably know that OS/2 was better than Windows. How your
theory would explain its fault?

>> >> > There are much more important issues in the case. For
>> >> > example, will be car vendors required to publish full sources of the
>> >> > software used in their cars?
>> >>
>> >> What for? To laugh at?
>> > 
>> > There are enough people in the world who know cars and at the same have
>> > some programmer skills. Some of them may become interested in studying
>> > those sources (of their own car's software, for example). It may
>> > constitute very significant resource for finding remaining bugs and
>> > glitches.
>>
>> So the system of that complexity should be controlled by a crowd of
>> hobbists?
> 
> Controlled? Is GNAT controlled by the crowd of hobbyists who have an easy
> opportunity to read its sources?
> 
> But anyway, in the case of cars, I'd like to tell you that in that crowd
> of hobbyists, easily can happen people who are more skilled in software,
> and even in complex software, than the software engineering personnel that
> developed the car's software. Those skilled people may have an interesting
> reason to look at the sources: they may own the car.

Ah, now I have understand your scientical theory of how it should be done.
Ignorant, uneducated personnel will write rubbish being well paid for that.
Highly qualified people in their spare time (after a day of sweeping
streets, I suppose) will analyse their work for free. The rest is still a
bit in clouds. Should they send their analysis to the managers? I am afraid
that if that would distract managers from playing golf, they could get
angry.

> Just as Boeing
> engineer may become interested in some construction details of a small
> piston single airplane, which he owns. Imagine that, say, a Cisco engineer
> or former DEC engineer becomes suspecting that some sporadic trouble in
> his own car is caused by a software glitch.

Yes, a sporadic ignition of the air bag caused by the pre-crash detection
system fault at the speed of 180 km/h on the highway. 

> Then, there are graduate
> students (EE and CS), and some part of them are already better skilled
> then some part of that car software development personnel - and they also
> often own cars.

It seems that you do not understand the complexity of the system. It cannot
be analyzed afterwards. To create such a system you have do it in the
framework of a very strict development procedure.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> I knew no programmer who liked IBM assembler. You should a rare exception.

Well, probably it is true - I am indeed a rare exception (although certainly
far from unique) in that aspect. The cause is simple, I think - not many
people had disasembled (mostly manually) enough IBM 360/370 code, not many
people had to device and apply (succesfully -;) their own patches to OS/360
kernel, and in fact, not too many peoply were in position of system
administrator with responsibilities of running 4 IBM-clone mainframes for
mid-sized datacenter without any external professional support, being at the
same time an active application programmer.

In fact one tends to like "the native language" of the first machine, to which
he had close access, and which he took seriously. Good qualities of the native
languages of subsequent machines may be recognized and appreciated, but the
first one (like first true love -:) remains forever.

There was not too many programmers who had close access to IBM 360/370
mainframes - they were mostly system administrators (in Soviet Union they were
called "system programmers" - without much justificaion -;) . But much more
programmers had sufficiently close access to PDP-11; and the essense of
applications that were typical for PDP-11 was usually more easily felt by
programmers (than in the case of mainframes).
  
> >> As I said, the problem is that the marked, beloved or not, does not work
> >> well for software.
> > 
> > Hm, but for what is works better? For science? For fims? For literature?
>
> You have admitted that there is a problem.

Certainly, there is a problem. And there isn't (and cannot be) a general
solution. In fact, there usually can't be a *solution* at all; instead of
solution there will (as a rule) be a struggle - in some form, one or another
- and the result will usually be not a solution, but a decision or win.

> >> This is the only reason why even less beloved government
> >> should intervene. Because software is essential to the future of
> >> humankind.
> > 
> > So you think (applying the same logic) that government should intervene in
> > science,
>
> Doesn't it? Or do you think that space program is sponsored by Microsoft?

"intervene" isn't a synonym for "sponsor"; when the government sponsors then
it is taxpayers who actually are sponsoring, but if the govenrment *intervene*
- it may well be the government indeed.

As for government sponsoring, why do you (apparently) believe that the
government will chose right projects for its sponsoring more often than wrong
- not just fruitless, but harmful ones (harm may be easily produced by unfair
competition to good projects).

> Then you should probably know that OS/2 was better than Windows. How your
> theory would explain its fault?

OS/2 was certainly better than Windows 3.1/3.11 (but it required more costly
computer) or Windows 95/98 (except of nomenclature of supported devices, that
is, except device drivers - which was significant for many users). But I can't
say whether it was really better than reasonably matured Windows NT (say, 4.0).

> >> >> > There are much more important issues in the case. For
> >> >> > example, will be car vendors required to publish full sources of the
> >> >> > software used in their cars?
> >> >>
> >> >> What for? To laugh at?
> >> > 
> >> > There are enough people in the world who know cars and at the same have
> >> > some programmer skills. Some of them may become interested in studying
> >> > those sources (of their own car's software, for example). It may
> >> > constitute very significant resource for finding remaining bugs and
> >> > glitches.
> >>
> >> So the system of that complexity should be controlled by a crowd of
> >> hobbists?
> > 
> > Controlled? Is GNAT controlled by the crowd of hobbyists who have an easy
> > opportunity to read its sources?
> > 
> > But anyway, in the case of cars, I'd like to tell you that in that crowd
> > of hobbyists, easily can happen people who are more skilled in software,
> > and even in complex software, than the software engineering personnel that
> > developed the car's software. Those skilled people may have an interesting
> > reason to look at the sources: they may own the car.
>
> Ah, now I have understand your scientical theory of how it should be done.
> Ignorant, uneducated personnel will write rubbish being well paid for that.
> Highly qualified people in their spare time (after a day of sweeping
> streets, I suppose) will analyse their work for free. The rest is still a
> bit in clouds. Should they send their analysis to the managers? I am afraid
> that if that would distract managers from playing golf, they could get
> angry.

Why send it those managers? Put it on website, send it to approriate forum,
and discuss with others interested in that topic. It is enough. It will be
mass-media who will translate the analysis to the managers of appropriate
managers, if there will be anything potentially interesting and significant.

> > Just as Boeing
> > engineer may become interested in some construction details of a small
> > piston single airplane, which he owns. Imagine that, say, a Cisco engineer
> > or former DEC engineer becomes suspecting that some sporadic trouble in
> > his own car is caused by a software glitch.
>
> ...
>
> > Then, there are graduate
> > students (EE and CS), and some part of them are already better skilled
> > then some part of that car software development personnel - and they also
> > often own cars.
>
> It seems that you do not understand the complexity of the system.

It seems that you do not understand the complexity and abilities of free
people society regarding an investigation and testing of a relatively stable
system.

I understand that the system is complex enough (although not at the cutting
edge of software complexity these times). But that complexity shows itself
mostly (assuming a reasonably proper development process) in the process of
creation of the system - that is, in the first phase of the lifecycle, while
I'm talking about subsequent phases.

> It cannot be analyzed afterwards.

Why? Do you mean that in particular, car crashes will not be investigated
any more if it will seem probable that the software functionality (not
necessary a malfunction) was a contributing factor to the crash? Or you mean
that only specs will be accessible for such an investigation, even if it 
the real behaviour of the car apparently contradicted the specs?

> To create such a system you have do it in the
> framework of a very strict development procedure.

I said absolutely nothing about any involvement in the process of creating
such a system. Obviously, that process shouldn't and can't be made open to
strangers in any sense.

I'm talking about post-release part of each car model lifecycle.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> >> As I said, the problem is that the marked, beloved or not, does not
>> >> work well for software.
>> > 
>> > Hm, but for what is works better? For science? For fims? For
>> > literature?
>>
>> You have admitted that there is a problem.
> 
> Certainly, there is a problem. And there isn't (and cannot be) a general
> solution. In fact, there usually can't be a *solution* at all; instead of
> solution there will (as a rule) be a struggle

a class struggle (:-))

> - in some form, one or
> another - and the result will usually be not a solution, but a decision or
> win.

In any case, it cannot be controlled by the market only, without some
additional game rules imposed by a legislative body. This is what I meant.
The society has two major instruments for intervening. One is liability,
shoe makes are liable, why software produces should not be? Other is
redistribution of wealth. I'd like to see our taxes spent rather on Ada
than on windmills in the North Sea.

>> >> This is the only reason why even less beloved government
>> >> should intervene. Because software is essential to the future of
>> >> humankind.
>> > 
>> > So you think (applying the same logic) that government should intervene
>> > in science,
>>
>> Doesn't it? Or do you think that space program is sponsored by Microsoft?
> 
> "intervene" isn't a synonym for "sponsor"; when the government sponsors
> then it is taxpayers who actually are sponsoring, but if the govenrment
> *intervene* - it may well be the government indeed.
> 
> As for government sponsoring, why do you (apparently) believe that the
> government will chose right projects for its sponsoring more often than
> wrong - not just fruitless, but harmful ones (harm may be easily produced
> by unfair competition to good projects).

Because to convince the government could be easier than to convince millions
of customers, who according to you, only waiting for an opportunity to tear
a cable from a computer and start to chew it. Cable chewers already made
their choice!

>> Ah, now I have understand your scientical theory of how it should be
>> done. Ignorant, uneducated personnel will write rubbish being well paid
>> for that. Highly qualified people in their spare time (after a day of
>> sweeping streets, I suppose) will analyse their work for free. The rest
>> is still a bit in clouds. Should they send their analysis to the
>> managers? I am afraid that if that would distract managers from playing
>> golf, they could get angry.
> 
> Why send it those managers? Put it on website, send it to approriate
> forum, and discuss with others interested in that topic. It is enough. It
> will be mass-media who will translate the analysis to the managers of
> appropriate managers, if there will be anything potentially interesting
> and significant.

So it is the mass media to find something significant. Oh they would, they
already found green men, UFO. I see: next to the page of horoscopes, "how I
removed race condition in my ignition controller".

>> It seems that you do not understand the complexity of the system.
> 
> It seems that you do not understand the complexity and abilities of free
> people society regarding an investigation and testing of a relatively
> stable system.
> 
> I understand that the system is complex enough (although not at the
> cutting edge of software complexity these times). But that complexity
> shows itself mostly (assuming a reasonably proper development process)

But this is the key point! I do not believe in magic. I do in technology. A
technology is not based on craftworks. You cannot rely on them. You have to
have a procedure which warranties you a definite level of quality on each
stage of software development. Starting from writting the requirements (and
BTW, choosing the programming language.) Presently this is not the case.
And I do not see how mass media or even (unrealistic to get) open source
could change that. Again the matter of interest is not the source, but the
way it was produced.

> in
> the process of creation of the system - that is, in the first phase of the
> lifecycle, while I'm talking about subsequent phases.
> 
>> It cannot be analyzed afterwards.
> 
> Why? Do you mean that in particular, car crashes will not be investigated
> any more if it will seem probable that the software functionality (not
> necessary a malfunction) was a contributing factor to the crash? Or you
> mean that only specs will be accessible for such an investigation, even if
> it the real behaviour of the car apparently contradicted the specs?

You have a system with dozens processors running dozens of tasks. Some of
them are hard real-time. These tasks are communicating over a number of
field buses using protocols of different nature (time-triggered, with
arbitration etc). Some of these tasks receive data from external sources
(GPS, navigation data etc.) All this is from dozens of different vendors,
written in C. Tell me, how you will analyze that. As an example, I know a
car vendor, which for years is unable to find a bug in its *one* engine
controller, running *one* task, causing sporadic stop. I saw some code of
another vendor. It far beyond any imagination!

>> To create such a system you have do it in the
>> framework of a very strict development procedure.
> 
> I said absolutely nothing about any involvement in the process of creating
> such a system. Obviously, that process shouldn't and can't be made open to
> strangers in any sense.
> 
> I'm talking about post-release part of each car model lifecycle.

Then it is much too late. Your observers would state: this is a mess. So
what? Everybody knows that Windows is a mess. One need no sources for that.
How does it help?

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> The society has two major instruments for intervening. One is liability,
> shoe makes are liable, why software produces should not be?

Because the public did not want (so far) to triple (at best) software prices 
by involving lawyers in the detailed specification of every software product.

There is well-established tradition for shoes, for centures, both for their
production and their use. So common sense is well-formed regarding shoes,
and enough independent experts are always (and easily) available - again,
both for production and for use of shoes.

But we still do not have enough tradition for software products - neither for
their production nor for their use. We have little common sense regarding
software, and certainly not enough independent and at the same time competent
experts.

And all above is only one side of the problem. Another side looks even worse:
significant part of software is a cutting edge in one or another dimension,
and therefore it naturally can't guarantee its performance in every particular
circumstances. So, general liability will severely impede progress, and this
for many applications overweights eventual losses. Note that it may be true
even for software that may directly endanger life of a human person.

For a change, you may think also why so many advertisments (not necessarily
related to sofware) aren't liable -;)

> Other is redistribution of wealth.

Hm, probably you mean internal/domestic redistribution, and not redistribution
between this country and others (although the latter is also often seen as
a major government's instrument or purpose, depending on circumstances).
In this case, regarding technical/scientific problems it is usually called
"concentration of resources", I think.

> I'd like to see our taxes spent rather on Ada
> than on windmills in the North Sea.

When you enter in some govenment or at least become a prominent consultant
for the government then your preferences about spending taxes will matter.
So you know the way.

> to convince the government could be easier than to convince millions
> of customers,

Sometimes it may be true, but in this case it may be true also for your
competitor. Why goverment should help Ada and not some other language -
should it depend upon links and bribes and hot political issues? Actually,
when you appeal to the government for such purposes, you just try to exploit
another market - a narrow one, for privileged parties only. You can't have 
any strong reasons to believe that Ada will be a winner in this, rather opaque
market. Better not to try to shift the competition (for resources) there.

Maintainance or even major overhaul of already established language is not the
same thing as create an entirely new one with some unprecedented qualities.
As Ada's experience shows, if government decides to spend resources on a
programming language, it will be probably not just Better Ada, but entirely
new language, which may be far from Ada as much as Ada was far from Jovial.

Perhaps you'll be pleased with such a perspective, but I doubt that currenlty
there is a ground for that. Ada as a multi-purpose language had a serious
predecessor - PL/I, while now we do not see anything of that kind (unless we
agree to consider Java or C# as candidates).


> >> Ignorant, uneducated personnel will write rubbish being well paid
> >> for that. Highly qualified people in their spare time (after a day of
> >> sweeping streets, I suppose) will analyse their work for free. The rest
> >> is still a bit in clouds. Should they send their analysis to the
> >> managers? I am afraid that if that would distract managers from playing
> >> golf, they could get angry.
> > 
> > Why send it those managers? Put it on website, send it to approriate
> > forum, and discuss with others interested in that topic. It is enough. It
> > will be mass-media who will translate the analysis to the managers of
> > appropriate managers, if there will be anything potentially interesting
> > and significant.
>
> So it is the mass media to find something significant. Oh they would, they
> already found green men, UFO.

I think that mass-media never connected UFOs with a particular brand, that is,
with well-known vendor of some products. 

> I do not believe in magic.

You may not believe in magic, but you can't avoid some dose of it -:) - for
big and/or complex systems. Even if magic is not present in the final product
then some magic helped you during the development process -:) .

> I do in technology. A technology is not based on craftworks.

Every technology is based on craftworks - on one level or another.
I recall that Dijkstra once wrote something like that: "Even the most
theoretically-minded physists will admit that every digital computer is, in
some depth, an analog device" (sorry, I had read that in Russian translation,
so this my quote probably is somehow inexact).

> You cannot rely on them. You have to
> have a procedure which warranties you a definite level of quality on each
> stage of software development.

Very well, but those warranting procedures aren't God-sent, they must be
crafted... and sad to say, according to your own position, you cannot
carelessly rely upon them.

> Starting from writting the requirements (and
> BTW, choosing the programming language.) Presently this is not the case.
> And I do not see how mass media or even (unrealistic to get) open source
> could change that.

Surely nothing external can change that. But again, I'm talking not about 
intervention into development process, but about post-release stage, where
development is completed, but investigations by external parties must be
possible.

> Again the matter of interest is not the source, but the way it was produced.

For investigation of a malfunction (or crash) of a released product the
sources is primary thing... the way it was produced may be of some interest, 
but it is definitely secondary.

You dream to prevent all errors (without magic -:) , while I do not believe
that this dream may come true - at all levels at the same time.

> You have a system with dozens processors running dozens of tasks. Some of
> them are hard real-time. These tasks are communicating over a number of
> field buses using protocols of different nature (time-triggered, with
> arbitration etc). Some of these tasks receive data from external sources
> (GPS, navigation data etc.)

Well, so what? I'm still not too much impressed (much less then, for example,
when I was reading an article about National Ignition Facility). Yes, this
is a rather complicated system, but not breathtakingly complicated.

> All this is from dozens of different vendors,

What? You mean parts of the system? Why should I worry about those vendors
at all? I don't want to know about vendors and their habits! I'll take specs,
and that's all I want to know about the parts. If the specs appear incomplete
for the purpose then I'll ask (someone) for secondary specs (which may depend
on vendor) but not in advance.

> written in C.

My experience in reading "foreign" code tells me that it doesn't matter too
much (for "emergency" reading) which language is used. Once I saw absolutely
fantastic code in Pascal (and that certainly was not a joke or something of
that kind), which was harder to read than most convoluted C.

> Tell me, how you will analyze that.

Well, I don't know in advance... I never know that in advance - I must see
the code before I decide how I'll analyze it...

> As an example, I know a
> car vendor, which for years is unable to find a bug in its *one* engine
> controller, running *one* task, causing sporadic stop.

Poor vendor, he can't reach me -:)  Did he try to create a simulator?

> I saw some code of
> another vendor. It far beyond any imagination!

Perhaps, not *any* imagination. I think you mean "expectations", well,
"bad expectations" rather than "imagination".

> > > I'm talking about post-release part of each car model lifecycle.
> >
> > Then it is much too late. Your observers would state: this is a mess. So
> > what?

They need not to evaluate the whole system, whether it is a mess or not.
Each of them may have a paricular, very local interest, and it may well
happen, that the cause if the trouble is indeed reasonably local.

> Everybody knows that Windows is a mess. One need no sources for that.
> How does it help?

Well, not everybody ends up saying "the Windows is a mess". A good and
well-known example of another approach you may see at www.sysinternals.com .




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> The society has two major instruments for intervening. One is liability,
>> shoe makes are liable, why software produces should not be?
> 
> Because the public did not want (so far) to triple (at best) software
> prices by involving lawyers in the detailed specification of every
> software product.

1. Where these figures come from?
2. Who wants to ask public? They had been asked before, they shown absolute
inability to make reasonable choice.

> There is well-established tradition for shoes, for centures, both for
> their production and their use. So common sense is well-formed regarding
> shoes, and enough independent experts are always (and easily) available -
> again, both for production and for use of shoes.

Common sense is not formed, it either exists or not.

> But we still do not have enough tradition for software products - neither
> for their production nor for their use. We have little common sense
> regarding software, and certainly not enough independent and at the same
> time competent experts.

You need no experts to analyze the software. Requirements and terms of
liability are pretty easy to set and check. You need no spectral analysis
to determine whether shoes peel off.

> And all above is only one side of the problem. Another side looks even
> worse: significant part of software is a cutting edge in one or another
> dimension, and therefore it naturally can't guarantee its performance in
> every particular circumstances. So, general liability will severely impede
> progress, and this for many applications overweights eventual losses. Note
> that it may be true even for software that may directly endanger life of a
> human person.

The only edge MS-Office cuts is consuming as much memory as any new
generation of computers might have. Who needs *this* progress? Concede, you
get this argument from Bill Gates, who said that separating Explorer and
Windows would stop the progress. (:-)) Very convincing.

> For a change, you may think also why so many advertisments (not
> necessarily related to sofware) aren't liable -;)

Because they are for free! No pay, no play.

>> to convince the government could be easier than to convince millions
>> of customers,
> 
> Sometimes it may be true, but in this case it may be true also for your
> competitor. Why goverment should help Ada and not some other language -
> should it depend upon links and bribes and hot political issues? Actually,
> when you appeal to the government for such purposes, you just try to
> exploit another market - a narrow one, for privileged parties only.

and more competent ones.

> You
> can't have any strong reasons to believe that Ada will be a winner in
> this, rather opaque market. Better not to try to shift the competition
> (for resources) there.

Again, there are issues essential to the existence of our civilization.
Software development becomes one of them. Ada is just an indicator of how
things are going on.

> Maintainance or even major overhaul of already established language is not
> the same thing as create an entirely new one with some unprecedented
> qualities. As Ada's experience shows, if government decides to spend
> resources on a programming language, it will be probably not just Better
> Ada, but entirely new language, which may be far from Ada as much as Ada
> was far from Jovial.

Let it be a better language, I have no problem with that.

>> You cannot rely on them. You have to
>> have a procedure which warranties you a definite level of quality on each
>> stage of software development.
> 
> Very well, but those warranting procedures aren't God-sent, they must be
> crafted... and sad to say, according to your own position, you cannot
> carelessly rely upon them.

So, according to you, it is better to have *nothing*.

>> Starting from writting the requirements (and
>> BTW, choosing the programming language.) Presently this is not the case.
>> And I do not see how mass media or even (unrealistic to get) open source
>> could change that.
> 
> Surely nothing external can change that.

Come on, to sell a new car model, you have to get tonns of papers.

> But again, I'm talking not about
> intervention into development process, but about post-release stage, where
> development is completed, but investigations by external parties must be
> possible.

That will not happen. But, again, it would be rather useless.

>> Again the matter of interest is not the source, but the way it was
>> produced.
> 
> For investigation of a malfunction (or crash) of a released product the
> sources is primary thing... the way it was produced may be of some
> interest, but it is definitely secondary.

Nope. I need not study the laws of Newzeland, because I know the
"procedure", and I expect it to be democratic and respecting human rights.

> You dream to prevent all errors (without magic -:) , while I do not
> believe that this dream may come true - at all levels at the same time.

If that will not become true, we as humankind, will simply commit suicide.

>> As an example, I know a
>> car vendor, which for years is unable to find a bug in its *one* engine
>> controller, running *one* task, causing sporadic stop.
> 
> Poor vendor, he can't reach me -:)  Did he try to create a simulator?

Of what? Motor simulator? Roller dynamometer? Climatic chamber? Autopilot?

>> I saw some code of
>> another vendor. It far beyond any imagination!
> 
> Perhaps, not *any* imagination. I think you mean "expectations", well,
> "bad expectations" rather than "imagination".

Consider code using no subprograms. People believed that they are
inefficient. (:-)) So anything to be repeated was cut and pasted. For the
same reason (I suppose), they used only global variables! Do you really
think that *this* kind of code should be analyzed at all?

>> > > I'm talking about post-release part of each car model lifecycle.
>> >
>> > Then it is much too late. Your observers would state: this is a mess.
>> > So what?
> 
> They need not to evaluate the whole system, whether it is a mess or not.
> Each of them may have a paricular, very local interest, and it may well
> happen, that the cause if the trouble is indeed reasonably local.

It is a dangerous delusion to think this way. Compare it with somebody
reasoning in early 50s: as soon as +,-,*,/ implemented and tested, there is
no problem with any program.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
: Common sense is not formed, it either exists or not.

Uhm, common sense is a term with a number of definitions, and
it typically is a construct of anthropology (in a broader sense
of the word). One more or less "formalised" view is by Kant,
Sensus Communis. (It's a long time I had a chance to even look
at this one.)   Anyway common sense it is conceptualised with 
different frames of reference in mind.
There is at best a correlation, like: this aggregate of persons
might think P about subject S, whereas another aggregate of persons
thinks Q about S, so there is a P-common sense among P-people,
and a Q-common sense among Q-people.

 So comon sense does not exist in an absolute sense, and it
is certainly formed. This can be seen in studies that
have employed ethnomethodology in various worldwise or
regional comparisons.
It doesn't exists in an absolute sense unless ideas (in the sense
of ideology, prejudice, preconceptions, etc) have a material
counterpart and and "idea-matter" does not depend on time, place,
human beings, ...

For example, when you ask Ada programmers, they might say
common sense dictates software production procedures of type A,
whereas when you ask managment people, they might say
common sense dictates software production procedures of type B.

-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>  
> : Common sense is not formed, it either exists or not.
> 
> Uhm, common sense is a term with a number of definitions, and
> it typically is a construct of anthropology (in a broader sense
> of the word). One more or less "formalised" view is by Kant,
> Sensus Communis. (It's a long time I had a chance to even look
> at this one.)   Anyway common sense it is conceptualised with
> different frames of reference in mind.
> There is at best a correlation, like: this aggregate of persons
> might think P about subject S, whereas another aggregate of persons
> thinks Q about S, so there is a P-common sense among P-people,
> and a Q-common sense among Q-people.
> 
>  So comon sense does not exist in an absolute sense, and it
> is certainly formed. This can be seen in studies that
> have employed ethnomethodology in various worldwise or
> regional comparisons.
> It doesn't exists in an absolute sense unless ideas (in the sense
> of ideology, prejudice, preconceptions, etc) have a material
> counterpart and and "idea-matter" does not depend on time, place,
> human beings, ...
> 
> For example, when you ask Ada programmers, they might say
> common sense dictates software production procedures of type A,
> whereas when you ask managment people, they might say
> common sense dictates software production procedures of type B.

I should have added a smiley to my sentence! (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> shoe makes are liable, why software produces should not be?
> > 
> > Because the public did not want (so far) to triple (at best) software
> > prices by involving lawyers in the detailed specification of every
> > software product.
>
> 1. Where these figures come from?

>From a finger, of course (as most other public figures). Try your own finger,
I hope it will tell you something alike.

> 2. Who wants to ask public? They had been asked before, they shown absolute
> inability to make reasonable choice.

There is no need to ask public for this matter. There is a perception that
public simply will not buy software at those prices in comparable quantities
- and this is enough.

There is a big difference between continental Europe and America that matters
here, and as America formed current software usage attitudes, the things are
as they are.

> You need no experts to analyze the software.

Here should be a smile also? Or a grin?

> Requirements and terms of
>liability are pretty easy to set and check.

Are you a lawyer? I think that a person who is not a lawyer should not make
statements of this kind anyway.

By the way, I remind you that Robert Dewar (who, although not being a lawyer
himself, nevertheless have some real experience with these matters regarding
software) warned many times (both here and in GCC mailing list) against making
law-related statements about software without consulting a professional lawyer.

> >  significant part of software is a cutting edge in one or another
> > dimension, and therefore it naturally can't guarantee its performance in
> > every particular circumstances. So, general liability will severely impede
> > progress, and this for many applications overweights eventual losses. Note
> > that it may be true even for software that may directly endanger life of a
> > human person.
>
> The only edge MS-Office cuts is consuming as much memory as any new
> generation of computers might have.

Well, it is easy to show you at least one dimension in which MS Word is at the
cutting edge: it is the number of users (with all their diversity in needs,
habits and preferences).

> Who needs *this* progress?

Perhaps, people. Those people who want to prepare a document and print it -
and then go to other, perhaps more attractive things.

> Concede, you get this argument from Bill Gates,

You understimate my own creativity. And anyway, there still aren't patents
for arguments, so I'm not worried.

> > For a change, you may think also why so many advertisments (not
> > necessarily related to sofware) aren't liable -;)
>
> Because they are for free! No pay, no play.

What? This is simply beautiful. Well, good, advertisments do not directly take
money from those who do not believe them; but they take enough money from
those who do believe them - these people really pay for all advertisments
(the cost of adverstisments is naturally added to the cost of the products
themselves).

> > when you appeal to the government for such purposes, you just try to
> > exploit another market - a narrow one, for privileged parties only.
>
> and more competent ones.

You are very loyal. Good for you. Yes, certainly, they are most competent,
most responsible, and even most handsome/beautiful. How can it be otherwise,
as they are chosen either by free general elections or, recursively, by those
who was chosen by free general election, etc. ?

> Again, there are issues essential to the existence of our civilization.

You are so focusing on our civilization... don't you think that civilization
is quite a complex thing, and it is not easy to determine what is essential
for it? But at least you don't refer to the God's will, and this is good.

> Software development becomes one of them. Ada is just an indicator of how
> things are going on.

Don't you see that these two your sentences contradict each other?
Ada essentially defies the general notion of "software", Ada expects you to
analyze each your problem deeply, with all its specifics, not relying upon
some general "software" fashions and solutions. It does not mean that you
should forget all your previous experience and it doesn not preclude any
general computer science - you can use all that if it helps you, but you
can't rely upon that, you can't get excuses from that.

> > post-release stage, where
> > development is completed, but investigations by external parties must be
> > possible.
>
> That will not happen.

Perhaps. But let's see.

> But, again, it would be rather useless.

You can't know. You never been an investigator, I'm sure - from your words.

> I need not study the laws of Newzeland, because I know the
> "procedure", and I expect it to be democratic and respecting human rights.

Well, it may be enough if you'll not deal with New Zealand in any way other
than visiting her as a tourist.

> > You dream to prevent all errors (without magic -:) , while I do not
> > believe that this dream may come true - at all levels at the same time.
>
> If that will not become true, we as humankind, will simply commit suicide.

Not at all. We as humankind were making countless errors all the history,
and still are alive, and even are observing some progress.

Well, maybe you don't know, but in dark years of the Cold War, a substantial
part of the hope was that there are enough errors in missile systems (that is,
missiles themselves, navigation etc.) on both sides; so that if they will be
really launched then most of them either will not takeoff or will not explode
or will explode somewhere in ocean. And some of us also hoped that the goverments
are also somehow aware of that possibility of those massive errors, and neither
side can be sure whether it has much less errors or much more errors than the
opponent.

> >> As an example, I know a
> >> car vendor, which for years is unable to find a bug in its *one* engine
> >> controller, running *one* task, causing sporadic stop.
> > 
> > Poor vendor, he can't reach me -:)  Did he try to create a simulator?
>
> Of what? Motor simulator? Roller dynamometer? Climatic chamber? Autopilot?

You said - "a bug in its engine controller", so I mean a simulator of that
engine controller.

> Consider code using no subprograms. People believed that they are
> inefficient. (:-)) So anything to be repeated was cut and pasted. For the
> same reason (I suppose), they used only global variables! Do you really
> think that *this* kind of code should be analyzed at all?

Well, I saw such progams enough. They were in COBOL (even operator "perform"
was rarely used by those poor programmers) and in Assembler - all for IBM/360.
Those users (called programmers -;) showed me their long listings and claimed
that there is a computer fault (usually: "this program ran fine yesterday,
I changed absolutely nothing, and today it crashes").



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> 2. Who wants to ask public? They had been asked before, they shown
>> absolute inability to make reasonable choice.
> 
> There is no need to ask public for this matter. There is a perception that
> public simply will not buy software at those prices in comparable
> quantities - and this is enough.

Again, show me figures. So far it is one perception against another.

>> You need no experts to analyze the software.
> 
> Here should be a smile also? Or a grin?

Neither.

>> Requirements and terms of
>>liability are pretty easy to set and check.
> 
> Are you a lawyer? I think that a person who is not a lawyer should not
> make statements of this kind anyway.

I was not talking about technical details of a particular license agreement.
I was talking about a common, long established practice of protecting
customers from frauds. So, are you a lawyer to claim that this practice is
inapplicaple to software?

> By the way, I remind you that Robert Dewar (who, although not being a
> lawyer himself, nevertheless have some real experience with these matters
> regarding software) warned many times (both here and in GCC mailing list)
> against making law-related statements about software without consulting a
> professional lawyer.

These discussions concerned concrete details of various GPLs.

>> >  significant part of software is a cutting edge in one or another
>> > dimension, and therefore it naturally can't guarantee its performance
>> > in every particular circumstances. So, general liability will severely
>> > impede progress, and this for many applications overweights eventual
>> > losses. Note that it may be true even for software that may directly
>> > endanger life of a human person.
>>
>> The only edge MS-Office cuts is consuming as much memory as any new
>> generation of computers might have.
> 
> Well, it is easy to show you at least one dimension in which MS Word is at
> the cutting edge: it is the number of users (with all their diversity in
> needs, habits and preferences).

Excellent. First you said about some "cutting edge" preventing "sofware
performance". Then you continued, that the "cutting edge" was the number of
users. So it is the users buying MS products, who are responsible for the
miserable sate of the software? Ergo the market does not work. My point, we
are in full argeement.

>> Who needs *this* progress?
> 
> Perhaps, people. Those people who want to prepare a document and print it
> - and then go to other, perhaps more attractive things.

I didn't asked about purpose of a text processor. I did about the software
quality.

>> > For a change, you may think also why so many advertisments (not
>> > necessarily related to sofware) aren't liable -;)
>>
>> Because they are for free! No pay, no play.
> 
> What? This is simply beautiful. Well, good, advertisments do not directly
> take money from those who do not believe them; but they take enough money
> from those who do believe them - these people really pay for all
> advertisments (the cost of adverstisments is naturally added to the cost
> of the products themselves).

Exactly. They do not like it, they hate it, yet they pay for it. Now,
substitute "Ada" for "advertisements" and you will have a glimpse of what I
meant.

>> > when you appeal to the government for such purposes, you just try to
>> > exploit another market - a narrow one, for privileged parties only.
>>
>> and more competent ones.
> 
> You are very loyal.

Delegation of rights is a fundamental difference between anarchy and
democraty.

> Good for you. Yes, certainly, they are most competent,
> most responsible, and even most handsome/beautiful. How can it be
> otherwise, as they are chosen either by free general elections or,
> recursively, by those who was chosen by free general election, etc. ?

This is how it works. Should I quote Churchill?

>> Again, there are issues essential to the existence of our civilization.
> 
> You are so focusing on our civilization... don't you think that
> civilization is quite a complex thing, and it is not easy to determine
> what is essential for it? But at least you don't refer to the God's will,
> and this is good.
> 
>> Software development becomes one of them. Ada is just an indicator of how
>> things are going on.
> 
> Don't you see that these two your sentences contradict each other?
> Ada essentially defies the general notion of "software", Ada expects you
> to analyze each your problem deeply, with all its specifics, not relying
> upon some general "software" fashions and solutions. It does not mean that
> you should forget all your previous experience and it doesn not preclude
> any general computer science - you can use all that if it helps you, but
> you can't rely upon that, you can't get excuses from that.

Where is any contradiction?

>> > You dream to prevent all errors (without magic -:) , while I do not
>> > believe that this dream may come true - at all levels at the same time.
>>
>> If that will not become true, we as humankind, will simply commit
>> suicide.
> 
> Not at all. We as humankind were making countless errors all the history,
> and still are alive, and even are observing some progress.

If your definition of progress reads as "cutting edge" = number of sold
copies, then yes, we are.

> Well, maybe you don't know, but in dark years of the Cold War, a
> substantial part of the hope was that there are enough errors in missile
> systems (that is, missiles themselves, navigation etc.) on both sides; so
> that if they will be really launched then most of them either will not
> takeoff or will not explode or will explode somewhere in ocean. And some
> of us also hoped that the goverments are also somehow aware of that
> possibility of those massive errors, and neither side can be sure whether
> it has much less errors or much more errors than the opponent.

Pretty silly, because it is actually no matter where it would explode.
Having an atomic tonnage of America or Russia, one needs no missiles. One
could explode it on own territory with the same effect.

>> >> As an example, I know a
>> >> car vendor, which for years is unable to find a bug in its *one*
>> >> engine controller, running *one* task, causing sporadic stop.
>> > 
>> > Poor vendor, he can't reach me -:)  Did he try to create a simulator?
>>
>> Of what? Motor simulator? Roller dynamometer? Climatic chamber?
>> Autopilot?
> 
> You said - "a bug in its engine controller", so I mean a simulator of that
> engine controller.

Controller is just a processor, usually there is no need to simulate it.
Anyway the cost of various testing, simulating etc, hardware/software is
measured in tens of millions of dollars. Their maintenance..., who knows.
So a manager might think that this is more than enough to find a bug. But
it is quite strange to hear similar statements from a software man.
Debugging is the least productive way for preventing software faults in
embedded/real-time world. In many cases it does not work at all.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> Requirements and terms of
> >>liability are pretty easy to set and check.
> > 
> > Are you a lawyer? I think that a person who is not a lawyer should not
> > make statements of this kind anyway.
>
> I was not talking about technical details of a particular license agreement.
> I was talking about a common, long established practice of protecting
> customers from frauds.

The problem is that in software it often isn't easy to differentiate a fraud
or liable negligence from a reasonable risk, to which the user was knowingly
agreed. Almost all computer professionals will agree that given the current
state-of-art, there is a risk-cost tradeoff for common software products. And
with the risk of eventual software error being pushed too down the cost will
skyrocket. So users have a good reason to agree with some risks - because they
need (or want) the functionality, provided by the product, but only for a
certain price, and not higher. This is a user's choice - either to take a
proposed risk, or not to buy the product. The problem is that with huge
diversity of both software products and user's background, attitudes and
education, it is impossible to represent clearly that trade-off as it is set
in a particular product. And even to represent it vaguely, but more or less
enough for anticipated courts, the professional lawyers are needed.

> So, are you a lawyer to claim that this practice is
> inapplicaple to software?

Well, I'm not a lawyer, although once I attended law school for 2 months -
just for getting some understanding of basic principles of law and of logic
of lawyers.

> > By the way, I remind you that Robert Dewar (who, although not being a
> > lawyer himself, nevertheless have some real experience with these matters
> > regarding software) warned many times (both here and in GCC mailing list)
> > against making law-related statements about software without consulting a
> > professional lawyer.
>
> These discussions concerned concrete details of various GPLs.

Yes (as far as I remember), but the warnings often were general - for
law-related statements about software without consulting a professional lawyer.

> I didn't asked about purpose of a text processor. I did about the software
> quality.

Being accesible and usable for large number of diverse people is one of the
most essensial qualities for some kinds of software.

> >> > when you appeal to the government for such purposes, you just try to
> >> > exploit another market - a narrow one, for privileged parties only.
> >>
> >> and more competent ones.
>
> ...
>
> Should I quote Churchill?

If you know a piece of Churchill's speech or writing containing his opinion
about the government's competence in technological issues then please, quote
it.

> >> Again, there are issues essential to the existence of our civilization.
> > 
> > You are so focusing on our civilization... don't you think that
> > civilization is quite a complex thing, and it is not easy to determine
> > what is essential for it? But at least you don't refer to the God's will,
> > and this is good.
> > 
> >> Software development becomes one of them. Ada is just an indicator of how
> >> things are going on.
> > 
> > Don't you see that these two your sentences contradict each other?
> > Ada essentially defies the general notion of "software", Ada expects you
> > to analyze each your problem deeply, with all its specifics, not relying
> > upon some general "software" fashions and solutions. It does not mean that
> > you should forget all your previous experience and it doesn not preclude
> > any general computer science - you can use all that if it helps you, but
> > you can't rely upon that, you can't get excuses from that.
>
> Where is any contradiction?

You said that software development - general process for general notion/issue
- becomes critically important. Then you said that the things are going very
badly in this respect. Then you hinted that the negligence to Ada is a symptom
as the latter. But Ada essentially defies general notion of "software", so you
logically should perceive the negative attitude towards Ada as a good symptom,
that is, a symptom of widened understanding of importance of general notion
of "software".

> > Well, maybe you don't know, but in dark years of the Cold War, a
> > substantial part of the hope was that there are enough errors in missile
> > systems (that is, missiles themselves, navigation etc.) on both sides; so
> > that if they will be really launched then most of them either will not
> > takeoff or will not explode or will explode somewhere in ocean. And some
> > of us also hoped that the goverments are also somehow aware of that
> > possibility of those massive errors, and neither side can be sure whether
> > it has much less errors or much more errors than the opponent.
>
> Pretty silly, because it is actually no matter where it would explode.

If it would explode at all, and explode by nuclear way (that is, warhead) and
not by chemical way (that is, missile's body - engine, fuel tanks).

> > Having an atomic tonnage of America or Russia,

Crucially important was the bootstrap behaviour. The hope was that the
bootstrap will not succeed, but will abort - on both sides.

> >> >> As an example, I know a
> >> >> car vendor, which for years is unable to find a bug in its *one*
> >> >> engine controller, running *one* task, causing sporadic stop.
> >> > 
> >> > Poor vendor, he can't reach me -:)  Did he try to create a simulator?
> >>
> >> Of what? Motor simulator? Roller dynamometer? Climatic chamber?
> >> Autopilot?
> > 
> > You said - "a bug in its engine controller", so I mean a simulator of that
> > engine controller.
>
> Controller is just a processor, usually there is no need to simulate it.

I see (with surprise) that an explanation is needed: it is input signal
stream(s) that should be simulated. Whether the hardware involved should be
simulated also, or the actual hardware may be used instead - this depends on
particular circumstances and equipment.

> Anyway the cost of various testing, simulating etc, hardware/software is
> measured in tens of millions of dollars. Their maintenance..., who knows.

A particular simulator of/for a particular controller for investigating a
particular bug - tens of millions of dollars? Perhaps you mean some ideal
error-preventing system, which will cost more than than accumulated cost of
all errors, which it prevents over current error-prevention/debugging
technique,

> So a manager might think that this is more than enough to find a bug.

What can he wish else, if a bug is already present and perceived? 

> But it is quite strange to hear similar statements from a software man.

I don't know about software men, I never meet such people, at least in person...
or didn't recognize them as such.

> Debugging is the least productive way for preventing software faults in
> embedded/real-time world. In many cases it does not work at all.

But what to do when a bug was not prevented, and shows itself in released
product? You are proposing to drop away this product and rebuild it using
some (very costly) ideal error-free methodology, from scratch?



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> >> Requirements and terms of
>> >>liability are pretty easy to set and check.
>> > 
>> > Are you a lawyer? I think that a person who is not a lawyer should not
>> > make statements of this kind anyway.
>>
>> I was not talking about technical details of a particular license
>> agreement. I was talking about a common, long established practice of
>> protecting customers from frauds.
> 
> The problem is that in software it often isn't easy to differentiate a
> fraud or liable negligence from a reasonable risk, to which the user was
> knowingly agreed. Almost all computer professionals will agree that given
> the current state-of-art, there is a risk-cost tradeoff for common
> software products.

I disagree. 90% of software impose no risk in development. Risk exists, but
it is related to management, marketing etc. Anyway, why the customers have
to care this risk?

> And with the risk of eventual software error being
> pushed too down the cost will skyrocket. So users have a good reason to
> agree with some risks - because they need (or want) the functionality,
> provided by the product, but only for a certain price, and not higher.
> This is a user's choice - either to take a proposed risk, or not to buy
> the product.

There is no such choice. You know it very well. This is why there are
regulations, to prevent you from buying rotten food in supermarkets.

> The problem is that with huge diversity of both software
> products and user's background, attitudes and education, it is impossible
> to represent clearly that trade-off as it is set in a particular product.
> And even to represent it vaguely, but more or less enough for anticipated
> courts, the professional lawyers are needed.

As I said before, you need not to look into the code. You have to look at
the procedure. Compare it with food regulations. Most of them tell that the
flesh shall be kept under some definite temperature, no longer than ...
etc. Further, if you get poisoned in McDonalds, it will be responsible for
that. That is. If you have lost your document in MS-Word, and this could be
made provable (regulation might require some kind of log), then MS has to
pay.

>> I didn't asked about purpose of a text processor. I did about the
>> software quality.
> 
> Being accesible and usable for large number of diverse people is one of
> the most essensial qualities for some kinds of software.

Nonsense. This is not a quality to be paid for. It is MS's business. We
should pay for a text processor, not for an ability to swallow a market
segment.

>> >> Again, there are issues essential to the existence of our
>> >> civilization.
>> > 
>> > You are so focusing on our civilization... don't you think that
>> > civilization is quite a complex thing, and it is not easy to determine
>> > what is essential for it? But at least you don't refer to the God's
>> > will, and this is good.
>> > 
>> >> Software development becomes one of them. Ada is just an indicator of
>> >> how things are going on.
>> > 
>> > Don't you see that these two your sentences contradict each other?
>> > Ada essentially defies the general notion of "software", Ada expects
>> > you to analyze each your problem deeply, with all its specifics, not
>> > relying upon some general "software" fashions and solutions. It does
>> > not mean that you should forget all your previous experience and it
>> > doesn not preclude any general computer science - you can use all that
>> > if it helps you, but you can't rely upon that, you can't get excuses
>> > from that.
>>
>> Where is any contradiction?
> 
> You said that software development - general process for general
> notion/issue - becomes critically important. Then you said that the things
> are going very badly in this respect. Then you hinted that the negligence
> to Ada is a symptom as the latter. But Ada essentially defies general
> notion of "software", so you logically should perceive the negative
> attitude towards Ada as a good symptom, that is, a symptom of widened
> understanding of importance of general notion of "software".

Sorry, but I cannot follow you. How a negative attitude to something (Ada),
which defines X, could be a symptom of widened understanding of importance
of that X?

>> Anyway the cost of various testing, simulating etc, hardware/software is
>> measured in tens of millions of dollars. Their maintenance..., who knows.
> 
> A particular simulator of/for a particular controller for investigating a
> particular bug - tens of millions of dollars?

For development/testing cars.

> Perhaps you mean some ideal
> error-preventing system, which will cost more than than accumulated cost
> of all errors, which it prevents over current error-prevention/debugging
> technique,

What makes you to think that the current level of error-prevention is so
high that the next step would cost as much as the space-shuttle program? It
is just guessing, a far from reality one.

>> So a manager might think that this is more than enough to find a bug.
> 
> What can he wish else, if a bug is already present and perceived?

To leave the firm, because the "patient" is already dead. As I said, you
cannot debug this. The chances are high that the error will be never found.
So they have a choice between trying to locate the situation where it
appears and then to compensate it somehow, or to trow all that mess away.

>> Debugging is the least productive way for preventing software faults in
>> embedded/real-time world. In many cases it does not work at all.
> 
> But what to do when a bug was not prevented, and shows itself in released
> product?

To shoot yourself.

> You are proposing to drop away this product and rebuild it using
> some (very costly) ideal error-free methodology, from scratch?

In many cases there is no other way. This why I am talking about a
catastrophe coming. In the future we will have much larger percent of
systems like this. Costs of their development will be astronomcal. With the
current way of thinking: let's do something and see if it works, where we
will come?

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > The problem is that in software it often isn't easy to differentiate a
> > fraud or liable negligence from a reasonable risk, to which the user was
> > knowingly agreed. Almost all computer professionals will agree that given
> > the current state-of-art, there is a risk-cost tradeoff for common
> > software products.
>
> I disagree. 90% of software impose no risk in development. Risk exists, but
> it is related to management, marketing etc.

If you have complete and unambiguous requirements before software development
phase than yes, this development may be error-free. But this means only that
you shifted all the risk to the requirements. If your analysts are much
stronger than your programmers then that may be good tactics. But if not...
you will possibly get a sound failure without any prior warnings/symptoms.

> Anyway, why the customers have to care this risk?

Ask that on a meeting of Customer Party. As for me, the customers do not have
to deal with that risk - they aren't required by law to buy any software (so
far), I think - they may ignore it altogether... and if they still need some
software then they are free (again, so far) to create it by themselves.

Why I have to care about a car incident that can hurt me on the road?
Well, I don't have to, I can choose not to leave my home.

> > And with the risk of eventual software error being
> > pushed too down the cost will skyrocket. So users have a good reason to
> > agree with some risks - because they need (or want) the functionality,
> > provided by the product, but only for a certain price, and not higher.
> > This is a user's choice - either to take a proposed risk, or not to buy
> > the product.
>
> There is no such choice. You know it very well. This is why there are
> regulations, to prevent you from buying rotten food in supermarkets.

We have common understanding of what it means for a food to be rotten - for
many centures. What comes relatively recently - it is just means (methods,
devices) for quick and precise recognition of this state, while its general
definition was commonly agreed long ago.

For software we have no such, commonly agreed definition - partly because we
dealt with software for decades and not for centures. Perhaps it will not
take several centures this time, but the experience, which we have accumulated
so far is not enough.

> As I said before, you need not to look into the code. You have to look at
> the procedure. Compare it with food regulations. Most of them tell that the
> flesh shall be kept under some definite temperature, no longer than ...

With a food, a product is just a copy. So the procedures can cover almost all.
And with software we also have no problems with copying - any vendor or shop
with replace you non-readable CD with good one, without any arguments.

But new software product isn't a copy, you know, and there can't be exact and
complete procedures for its development.

> > Being accesible and usable for large number of diverse people is one of
> > the most essensial qualities for some kinds of software.
>
> Nonsense. This is not a quality to be paid for. It is MS's business. We
> should pay for a text processor, not for an ability to swallow a market
> segment.

You are wrong here, and particularly in the case of MS Word. It is an
important quality for this kind of text processor to be shared by very many
users. Presence of this quality means (for a user) that documents can be
shared, sent and received (note that this isn't just issue of file format,
because different processors may print the same file format slightly
differently, and this is significant for many documents); visual formats and
styles can be more or less easily shared; and learning is much easier for
beginners because very often there are neighbours who already mastered this
text processor.

> >> >> Again, there are issues essential to the existence of our
> >> >> civilization.
> >> > 
> >> > You are so focusing on our civilization... don't you think that
> >> > civilization is quite a complex thing, and it is not easy to determine
> >> > what is essential for it? But at least you don't refer to the God's
> >> > will, and this is good.
> >> > 
> >> >> Software development becomes one of them. Ada is just an indicator of
> >> >> how things are going on.
> >> > 
> >> > Don't you see that these two your sentences contradict each other?
> >> > Ada essentially defies the general notion of "software", Ada expects
> >> > you to analyze each your problem deeply, with all its specifics, not
> >> > relying upon some general "software" fashions and solutions. It does
> >> > not mean that you should forget all your previous experience and it
> >> > doesn not preclude any general computer science - you can use all that
> >> > if it helps you, but you can't rely upon that, you can't get excuses
> >> > from that.
> >>
> >> Where is any contradiction?
> > 
> > You said that software development - general process for general
> > notion/issue - becomes critically important. Then you said that the things
> > are going very badly in this respect. Then you hinted that the negligence
> > to Ada is a symptom as the latter. But Ada essentially defies general
> > notion of "software", so you logically should perceive the negative
> > attitude towards Ada as a good symptom, that is, a symptom of widened
> > understanding of importance of general notion of "software".
>
> Sorry, but I cannot follow you. How a negative attitude to something (Ada),
> which defines X, could be a symptom of widened understanding of importance
> of that X?

A funny thing happened... Inadvertenly we created a good case - a proof of
that even a clear and unambiguous sentence may be confused if it is not
expected. Look, I wrote "defies" (from "defy"), not "defines"!

I wrote it twice, and this was exactly what I meant, but nevertheless you
either overlooked the absence of "n" in this word or decided that this were
just typos, in both cases. After that you naturally had no chance to follow
the logic of the text. And even after second iteration you appear unable
either to recognize the meaning of that word or to believe that your opponent
could say such a strange thing.

Well, I agree that this was an accident - two perfectly legal sentences with
very different, almost opposite meaning happened to be in dangerous lexical
proximity; and the situation was aggravated by the fact that the language of
dialogue was not native for both speakers involved.

It is too hard to prevent *all* significant errors -;)

> What makes you to think that the current level of error-prevention is so
> high that the next step would cost as much as the space-shuttle program? It
> is just guessing, a far from reality one.

Experience... not just my own experience, but experience of 20th century.
When you are trying to increase the level of error-prevention in large scale
then you have to worry very much about not increasing the level of
progress-prevention and the level of diversity-prevention. In 20th century
we have several examples - some very famous, some less known, but nevertheless
quite substantial, where too strong attitude towards error-prevention (without
worrying about side-effects) was a major contributing factor for sound
catastrophes. That is, the achieved good level of error-prevention made the
final catastrophes much more sound.

In many cases, suppressing a natural stream of errors with some general,
domain-independent technique, is similar to switching off sensors that show
unpleasant data.

> With the
> current way of thinking: let's do something and see if it works, where we
> will come?

To the Day Of Judgement, of course.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Mon, 19 Apr 2004 05:53:17 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> > The problem is that in software it often isn't easy to differentiate a
>> > fraud or liable negligence from a reasonable risk, to which the user was
>> > knowingly agreed. Almost all computer professionals will agree that given
>> > the current state-of-art, there is a risk-cost tradeoff for common
>> > software products.
>>
>> I disagree. 90% of software impose no risk in development. Risk exists, but
>> it is related to management, marketing etc.
>
>If you have complete and unambiguous requirements before software development
>phase than yes, this development may be error-free. But this means only that
>you shifted all the risk to the requirements. If your analysts are much
>stronger than your programmers then that may be good tactics. But if not...
>you will possibly get a sound failure without any prior warnings/symptoms.

Have you seen MS-Word requirements? Has it any?

>> > And with the risk of eventual software error being
>> > pushed too down the cost will skyrocket. So users have a good reason to
>> > agree with some risks - because they need (or want) the functionality,
>> > provided by the product, but only for a certain price, and not higher.
>> > This is a user's choice - either to take a proposed risk, or not to buy
>> > the product.
>>
>> There is no such choice. You know it very well. This is why there are
>> regulations, to prevent you from buying rotten food in supermarkets.
>
>We have common understanding of what it means for a food to be rotten - for
>many centures. What comes relatively recently - it is just means (methods,
>devices) for quick and precise recognition of this state, while its general
>definition was commonly agreed long ago.

No difference. It is no rocket science to see if MS-Word crashes.

>> As I said before, you need not to look into the code. You have to look at
>> the procedure. Compare it with food regulations. Most of them tell that the
>> flesh shall be kept under some definite temperature, no longer than ...
>
>But new software product isn't a copy, you know, and there can't be exact and
>complete procedures for its development.

Should it mean that they are irrelevant?

>> > Being accesible and usable for large number of diverse people is one of
>> > the most essensial qualities for some kinds of software.
>>
>> Nonsense. This is not a quality to be paid for. It is MS's business. We
>> should pay for a text processor, not for an ability to swallow a market
>> segment.
>
>You are wrong here, and particularly in the case of MS Word. It is an
>important quality for this kind of text processor to be shared by very many
>users. Presence of this quality means (for a user) that documents can be
>shared, sent and received (note that this isn't just issue of file format,
>because different processors may print the same file format slightly
>differently, and this is significant for many documents); visual formats and
>styles can be more or less easily shared; and learning is much easier for
>beginners because very often there are neighbours who already mastered this
>text processor.

MS-Word supports several formats, so I do not know what you mean.

>> >> >> Again, there are issues essential to the existence of our
>> >> >> civilization.
>> >> > 
>> >> > You are so focusing on our civilization... don't you think that
>> >> > civilization is quite a complex thing, and it is not easy to determine
>> >> > what is essential for it? But at least you don't refer to the God's
>> >> > will, and this is good.
>> >> > 
>> >> >> Software development becomes one of them. Ada is just an indicator of
>> >> >> how things are going on.
>> >> > 
>> >> > Don't you see that these two your sentences contradict each other?
>> >> > Ada essentially defies the general notion of "software", Ada expects
>> >> > you to analyze each your problem deeply, with all its specifics, not
>> >> > relying upon some general "software" fashions and solutions. It does
>> >> > not mean that you should forget all your previous experience and it
>> >> > doesn not preclude any general computer science - you can use all that
>> >> > if it helps you, but you can't rely upon that, you can't get excuses
>> >> > from that.
>> >>
>> >> Where is any contradiction?
>> > 
>> > You said that software development - general process for general
>> > notion/issue - becomes critically important. Then you said that the things
>> > are going very badly in this respect. Then you hinted that the negligence
>> > to Ada is a symptom as the latter. But Ada essentially defies general
>> > notion of "software", so you logically should perceive the negative
>> > attitude towards Ada as a good symptom, that is, a symptom of widened
>> > understanding of importance of general notion of "software".
>>
>> Sorry, but I cannot follow you. How a negative attitude to something (Ada),
>> which defines X, could be a symptom of widened understanding of importance
>> of that X?
>
>A funny thing happened... Inadvertenly we created a good case - a proof of
>that even a clear and unambiguous sentence may be confused if it is not
>expected. Look, I wrote "defies" (from "defy"), not "defines"!
>
>I wrote it twice, and this was exactly what I meant, but nevertheless you
>either overlooked the absence of "n" in this word or decided that this were
>just typos, in both cases. After that you naturally had no chance to follow
>the logic of the text. And even after second iteration you appear unable
>either to recognize the meaning of that word or to believe that your opponent
>could say such a strange thing.
>
>Well, I agree that this was an accident - two perfectly legal sentences with
>very different, almost opposite meaning happened to be in dangerous lexical
>proximity; and the situation was aggravated by the fact that the language of
>dialogue was not native for both speakers involved.
>
>It is too hard to prevent *all* significant errors -;)

Sorry, I just could not imagine how Ada can defy general notion of
software.

>> What makes you to think that the current level of error-prevention is so
>> high that the next step would cost as much as the space-shuttle program? It
>> is just guessing, a far from reality one.
>
>Experience... not just my own experience, but experience of 20th century.
>When you are trying to increase the level of error-prevention in large scale
>then you have to worry very much about not increasing the level of
>progress-prevention and the level of diversity-prevention. In 20th century
>we have several examples - some very famous, some less known, but nevertheless
>quite substantial, where too strong attitude towards error-prevention (without
>worrying about side-effects) was a major contributing factor for sound
>catastrophes. That is, the achieved good level of error-prevention made the
>final catastrophes much more sound.

Stop, first you tell us that the experience of making the food
producers liable is not applicable for the software. Now you tell that
the experience in error-prevention as the major brake of the progress
(in avionics? paper-fasteners?) is. Isn't it a bit selective?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >If you have complete and unambiguous requirements before software development
> >phase than yes, this development may be error-free. But this means only that
> >you shifted all the risk to the requirements. If your analysts are much
> >stronger than your programmers then that may be good tactics. But if not...
> >you will possibly get a sound failure without any prior warnings/symptoms.
>
> Have you seen MS-Word requirements?

Obviously no. I never been affiliated with Microsoft in any way, and never
seen its internal documents.

> Has it any?

I think yes, but they may be in rather economical, ergonomical etc. than
software engineering terms. They may have more technical (and perhaps more
volatile) refinements for parts, components, modes etc. 

> >We have common understanding of what it means for a food to be rotten - for
> >many centures. What comes relatively recently - it is just means (methods,
> >devices) for quick and precise recognition of this state, while its general
> >definition was commonly agreed long ago.
>
> No difference. It is no rocket science to see if MS-Word crashes.

But there is a difference in consequences. If you swallow a rooten food then
you probably (although not certainly) will be poisoned and fall ill, maybe
severely ill and even may die. But MS Word crash, however unpleasant, very
rarely has serious consequences. Most probably it will just annoy you for
several minutes or, perhaps, spoil some of your time - perhaps one or two
hours at most. Cases when a document - and not just any document, but an
important document was irrecoverably lost by a crash of MS Word - are very
rare, even exotic.

Buy the way, I have not heard much about MS Word crashes... actually I can't
recall even single story of that - for me it means that this is quite rare
and/or unimportant event. Perhaps it depends on whether (and how heavily)
this MS Word is used in conjunction with other applications.

> >> As I said before, you need not to look into the code. You have to look at
> >> the procedure. Compare it with food regulations. Most of them tell that the
> >> flesh shall be kept under some definite temperature, no longer than ...
> >
> >But new software product isn't a copy, you know, and there can't be exact and
> >complete procedures for its development.
>
> Should it mean that they are irrelevant?

Not at all, I never said that they are irrelevant or unimportant. They are
certainly interesting and deserve attention. I only stated that they aren't 
generally and neccessary the fundamental and primary thing in development.
That may be so in some cases, but it isn't so in other cases. That is, those
procedures may be primary and determining thing in some cases, but they are 
secondary and dependent in other cases.

> >> > Being accesible and usable for large number of diverse people is one of
> >> > the most essensial qualities for some kinds of software.
> >>
> >> Nonsense. This is not a quality to be paid for. It is MS's business. We
> >> should pay for a text processor, not for an ability to swallow a market
> >> segment.
> >
> >You are wrong here, and particularly in the case of MS Word. It is an
> >important quality for this kind of text processor to be shared by very many
> >users. Presence of this quality means (for a user) that documents can be
> >shared, sent and received (note that this isn't just issue of file format,
> >because different processors may print the same file format slightly
> >differently, and this is significant for many documents); visual formats and
> >styles can be more or less easily shared; and learning is much easier for
> >beginners because very often there are neighbours who already mastered this
> >text processor.
>
> MS-Word supports several formats, so I do not know what you mean.

Well, if you want to share your MS Word documents with assorted parties then
I'd recommend RTF (Rich Text Format) vs. default DOC format because of the
issue of compatibility between various releases of MS Word (MS Office) - with
RTF you most probably will be safe, while with DOC some incompatibilities are
really possible if the releases of MS Word aren't the same.

> >A funny thing happened... Inadvertenly we created a good case - a proof of
> >that even a clear and unambiguous sentence may be confused if it is not
> >expected. Look, I wrote "defies" (from "defy"), not "defines"!
> >
> >I wrote it twice, and this was exactly what I meant, but nevertheless you
> >either overlooked the absence of "n" in this word or decided that this were
> >just typos, in both cases. After that you naturally had no chance to follow
> >the logic of the text. And even after second iteration you appear unable
> >either to recognize the meaning of that word or to believe that your opponent
> >could say such a strange thing.
> >
> >Well, I agree that this was an accident - two perfectly legal sentences with
> >very different, almost opposite meaning happened to be in dangerous lexical
> >proximity; and the situation was aggravated by the fact that the language of
> >dialogue was not native for both speakers involved.
> >
> >It is too hard to prevent *all* significant errors -;)
>
> Sorry, I just could not imagine how Ada can defy general notion of
> software.

But could you imagine how Ada can DEFINE general notion of software?
I must confess that this is unimaginable for me - how any programming language
can DEFINE general notion of software. Actually I think that you was ready
to tolerate DEFINE there simply because it has some positive character in the
context, that is, hints to some positive quality of Ada.

Well, I'll explain how Ada DEFIES general notion of software. Ada does that
in two ways:

First, Ada expects dealing with detailed specifics of the problem, and detests
generalized approaches that ignore that specifics without prior consideration.

Second, Ada does not recognize software as an application domain that has its
own specifics - domain-specific features, primitives and structures. (The fact
that Ada somehow recognizes several other languages is largely irrelevant to
the issue.)

This is current situation. The first "way of defying" is fundamental for Ada.
It can't be betrayed without committing suicide... or at least losing
personality. But the second one can be changed in some future.

> >> What makes you to think that the current level of error-prevention is so
> >> high that the next step would cost as much as the space-shuttle program? It
> >> is just guessing, a far from reality one.
> >
> >Experience... not just my own experience, but experience of 20th century.
> >When you are trying to increase the level of error-prevention in large scale
> >then you have to worry very much about not increasing the level of
> >progress-prevention and the level of diversity-prevention. In 20th century
> >we have several examples - some very famous, some less known, but nevertheless
> >quite substantial, where too strong attitude towards error-prevention (without
> >worrying about side-effects) was a major contributing factor for sound
> >catastrophes. That is, the achieved good level of error-prevention made the
> >final catastrophes much more sound.
>
> Stop, first you tell us that the experience of making the food
> producers liable is not applicable for the software. Now you tell that
> the experience in error-prevention as the major brake of the progress
> (in avionics? paper-fasteners?) is. Isn't it a bit selective?

Well, I already explained the first. As for the second, strong desire for
error-prevention can easily slide from prevention of actual or probable
causes of errors to prevention of possible causes of errors and then to
prevention of conditions that may generate possible causes of errors. This
is a way for preventing progress. And this is not just imagined way - this is
a real, many times (and in various scales) observed way. It does not follow
from that experience that we should not pursue error-prevention; that our 
experience tells us only that we should be aware of that danger and resist
attempts to give error-prevention machinery too much power.

As for "selective" - yes, certainly selective, with a reason for each case.
With all my admiration for Euclid, we do not live in Euclidian space, reality
is not governed by finite number of Euclidian axioms, so we shouldn't make
general and absolute statements about reality, and must be selective...
according to our abilities for that.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue, 20 Apr 2004 05:41:03 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> No difference. It is no rocket science to see if MS-Word crashes.
>
>But there is a difference in consequences. If you swallow a rooten food then
>you probably (although not certainly) will be poisoned and fall ill, maybe
>severely ill and even may die. But MS Word crash, however unpleasant, very
>rarely has serious consequences. Most probably it will just annoy you for
>several minutes or, perhaps, spoil some of your time - perhaps one or two
>hours at most. Cases when a document - and not just any document, but an
>important document was irrecoverably lost by a crash of MS Word - are very
>rare, even exotic.

It is up to law and judges to decide, that is the point.

>> >A funny thing happened... Inadvertenly we created a good case - a proof of
>> >that even a clear and unambiguous sentence may be confused if it is not
>> >expected. Look, I wrote "defies" (from "defy"), not "defines"!
>> >
>> >I wrote it twice, and this was exactly what I meant, but nevertheless you
>> >either overlooked the absence of "n" in this word or decided that this were
>> >just typos, in both cases. After that you naturally had no chance to follow
>> >the logic of the text. And even after second iteration you appear unable
>> >either to recognize the meaning of that word or to believe that your opponent
>> >could say such a strange thing.
>> >
>> >Well, I agree that this was an accident - two perfectly legal sentences with
>> >very different, almost opposite meaning happened to be in dangerous lexical
>> >proximity; and the situation was aggravated by the fact that the language of
>> >dialogue was not native for both speakers involved.
>> >
>> >It is too hard to prevent *all* significant errors -;)
>>
>> Sorry, I just could not imagine how Ada can defy general notion of
>> software.
>
>But could you imagine how Ada can DEFINE general notion of software?
>I must confess that this is unimaginable for me - how any programming language
>can DEFINE general notion of software.

Any language defines the subject of talking.

>Actually I think that you was ready
>to tolerate DEFINE there simply because it has some positive character in the
>context, that is, hints to some positive quality of Ada.

No, because any programming language, Ada, C++, etc define, form,
influence the notion of software.

>Well, I'll explain how Ada DEFIES general notion of software. Ada does that
>in two ways:
>
>First, Ada expects dealing with detailed specifics of the problem, and detests
>generalized approaches that ignore that specifics without prior consideration.

Please elaborate this. If you mean generic programming then Ada
supports it by having both generics and class-wides.

>Second, Ada does not recognize software as an application domain that has its
>own specifics - domain-specific features, primitives and structures. (The fact
>that Ada somehow recognizes several other languages is largely irrelevant to
>the issue.)

I don't understand this. Should it mean that, say, ClearCase cannot be
written in Ada?

>This is current situation. The first "way of defying" is fundamental for Ada.
>It can't be betrayed without committing suicide... or at least losing
>personality. But the second one can be changed in some future.
>
>> >> What makes you to think that the current level of error-prevention is so
>> >> high that the next step would cost as much as the space-shuttle program? It
>> >> is just guessing, a far from reality one.
>> >
>> >Experience... not just my own experience, but experience of 20th century.
>> >When you are trying to increase the level of error-prevention in large scale
>> >then you have to worry very much about not increasing the level of
>> >progress-prevention and the level of diversity-prevention. In 20th century
>> >we have several examples - some very famous, some less known, but nevertheless
>> >quite substantial, where too strong attitude towards error-prevention (without
>> >worrying about side-effects) was a major contributing factor for sound
>> >catastrophes. That is, the achieved good level of error-prevention made the
>> >final catastrophes much more sound.
>>
>> Stop, first you tell us that the experience of making the food
>> producers liable is not applicable for the software. Now you tell that
>> the experience in error-prevention as the major brake of the progress
>> (in avionics? paper-fasteners?) is. Isn't it a bit selective?
>
>As for "selective" - yes, certainly selective, with a reason for each case.
>With all my admiration for Euclid, we do not live in Euclidian space, reality
>is not governed by finite number of Euclidian axioms, so we shouldn't make
>general and absolute statements about reality, and must be selective...
>according to our abilities for that.

OK, I see, you would enjoy experimental software dealing with your
bank account, controlling the nuclear reactor 30 miles away, managing
the air bag in your car. I do not buy it. Sorry, but I do not see any
progress in real-time controllers sending and receiving E-mails (a
real story). 

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> OK, I see, you would enjoy experimental software dealing with your
> bank account,

You seem to think that this is not already the case?

> controlling the nuclear reactor 30 miles away

The nuclear industry has been destroyed exactly by this approach of
certifying safety.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> > there is a difference in consequences. If you swallow a rooten food then
> >you probably (although not certainly) will be poisoned and fall ill, maybe
> >severely ill and even may die. But MS Word crash, however unpleasant, very
> >rarely has serious consequences. Most probably it will just annoy you for
> >several minutes or, perhaps, spoil some of your time - perhaps one or two
> >hours at most. Cases when a document - and not just any document, but an
> >important document was irrecoverably lost by a crash of MS Word - are very
> >rare, even exotic.
>
> It is up to law and judges to decide, that is the point.

I don't know whether there are many unemployed judges and lawyers in Germany,
but I think that, for example, in USA it isn't so - they have enough problems
associated with software today, without embracing too closely the field of
liability that you pursue.

Not all problems, irregularities and disagreements are for the law and judges.
If you aren't in hardcore police state, of course... and I don't know enough
about the Sharia law, but I'll certainly quit programming if it will be
required by law to cut the right hand (or even a finger) of a programmer who
made an error, which remained in released product.

There is another kind of system which applies to software where it is
reasonable, and which does not involve law and judges into specifics and
details of software: certification. The law may require that some kinds of
software - used in specific categories of applications or in specific modes
or environments etc. - must be certified, that is, approved with provision of
appropriate documents, by organizations or persons that are appointed or
licensed for this purpose by designated government's agencies or
representative bodies.

If a certification system is established then the law and judges will only
control proper application of that system. And then it will be up to the
lawmakers of your country, whether they choose to pursue maximal local safety
by total certification or they will prefer some compromise; but at least the
judicial system will not be damaged this way.

> >> Sorry, I just could not imagine how Ada can defy general notion of
> >> software.
> >
> >But could you imagine how Ada can DEFINE general notion of software?
> >I must confess that this is unimaginable for me - how any programming language
> >can DEFINE general notion of software.
>
> Any language defines the subject of talking.

A loud shot, but a miss - because we don't (and can't) talk about general
notion of software in Ada.

> any programming language, Ada, C++, etc define, form,
> influence the notion of software.

It does not define or form, but at most contribute something to those notion.
And yes - it influences, but not much in most cases... yes, there were notable
exceptions - the languages, which substantially influences the matter - first
trio - Fortran, Algol, COBOL, then LISP, Basic, Simula-67, SmallTalk, then C
and Pascal, then C++ and Visual Basic. (This is not the list of my favorite
languages - for example, I certainly like APL much better that Basic, but I
think that for now Basic influences the general notion of software much more
than APL; and I do not speak here about theoretical understanding, therefore
I did not include, for example, CLU in this list; and this it the cut for the
current moment and not an outlook for the whole history - that's why I did not
include, for example, PL/I). If we lower the barrier then we should, perhaps,
include SNOBOL and/or Perl (or. perhaps, intermediate AWK) and possibly SQL.

> >Well, I'll explain how Ada DEFIES general notion of software. Ada does that
> >in two ways:
> >
> >First, Ada expects dealing with detailed specifics of the problem, and detests
> >generalized approaches that ignore that specifics without prior consideration.
>
> Please elaborate this. If you mean generic programming then Ada
> supports it by having both generics and class-wides.

Surely in Ada generalization constructs are present and perfectly usable -
Ada has nothing against reasonable generalization. But note that all these
constructs aren't too user-friendly, they never work automatically or
implicitly. You have to instantiate generics explicitly - you have to type
(and then read) an additional line, which is a burden. Not a big burden, but
nevertheless it works against careless generalizations. Similarly for 
class-wide programming - you have to type 'Class explicitly and then take
some consequences. Again. not a big burgen, but most programmers will take
even small, but systematic burden only for a good reason - so it works against
careless and unreasonable generalizations.

And the same goes all the way with Ada. Just try to increase your speed and
run carelessly with the banner "I'm creating software!" in your hand - you'll
immediatiately meet various obstacles and annoyances, which you'll never meet
in C and you'll never meet major part of them in C++.

While you are close to the problem domain and reflect it precisely in your
code, Ada do her best for you. But if you try to take a vague (carelessly
generalized) look to your problem then Ada frowns at you and makes you unhappy.

> >Second, Ada does not recognize software as an application domain that has its
> >own specifics - domain-specific features, primitives and structures. (The fact
> >that Ada somehow recognizes several other languages is largely irrelevant to
> >the issue.)
>
> I don't understand this. Should it mean that, say, ClearCase cannot be
> written in Ada?

I'm not familiar with ClearCase, I'm only vaguely aware of it, but I think
it doesn't matter here. Certainly, ClearCase as well as any other user-mode
program/system can be written in Ada. And it can be written in Perl or, say,
Visual Basic also. Are there Ada features that will help make the ClearCase
better (comparing with making it with C++ or Perl or Visual Basic)? Are there
particularly suitable notations, well-thought useful attributes or anything
else particularly good for this specific purpose? I think no, there aren't
such features in Ada.

Compare that with the situation when you are creating a numeric (that is,
purely computational) application or developing real-time controller. For
these application domains, which Ada fully recognizes, she has plently of
particularly good features.

That said, I must remark that I certainly don't think that the ClearCase is
a good representative for software as hypothetical application domain. And
don't ask me for better representative - I will not provide it, at least this
time (you may try yourself, of course). When I said that Ada does not
recognize software as an application domain I only stated a fact, and did not
imply that Ada designers are stupid or blind regarding this matter.

> I see, you would enjoy experimental software dealing with your
> bank account,

Although I have none (remember, I live in Russia, and I'm neither former
parteigenosse nor "new Russian" nor a bandit, and I'm not affiliated with
either kind, so this shouldn't be too surprising), nevertheless from time to
time I'm asked privately (by a friend who works for a bank here) for some
general advice regarding banking software - usually concerning problems with
either experimental software or migration to new version. Well, I do not
enjoy those stories, sometimes I even sighed after that - there are too much
stupidity, incompetence and indifference... and note that many "procedures"
are supposedly present, but they are too often either ignored or avoided or
distorted or simply aren't understood or aren't known by relevant personnel
or are blindly copied from foreign ones without necessary adaptation/customization.

> controlling the nuclear reactor 30 miles away,

Interesting, how far you think is the Sosnovyi Bor power plant with 4 big
nuclear reactors from south-east of Saint-Petersburg(Russia) where I live?
I can tell you that I still don't see too much danger from it - mostly because
there are still enough scientific power in nearby institutes. Certainly, that
scientific power and correspondily indirect control is gradually weaking in
some important aspects, but I think that former surplus was so large that we
still have enough. At the same time I believe that stopping that plant would
create a whole gallery of disasters caused directly or indirectly by deficit
of electricity.

> managing the air bag in your car.

I never had a car (and also never had driving license), so it shouldn't be
too surprizing that I don't know what is exactly an air bag. Perhaps I know
something about it - if it is something traditional and not relatively recent
invention (as I studied car construction in my childhood), but just don't know
that English term. So, not knowing what that air bag is and which is its role,
I can't estimate consequences of its malfunction.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Wed, 21 Apr 2004 06:51:00 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >> Sorry, I just could not imagine how Ada can defy general notion of
>> >> software.
>> >
>> >But could you imagine how Ada can DEFINE general notion of software?
>> >I must confess that this is unimaginable for me - how any programming language
>> >can DEFINE general notion of software.
>>
>> Any language defines the subject of talking.
>
>A loud shot, but a miss - because we don't (and can't) talk about general
>notion of software in Ada.

How so?

>> any programming language, Ada, C++, etc define, form,
>> influence the notion of software.
>
>It does not define or form, but at most contribute something to those notion.

I do not see any difference.

>And yes - it influences, but not much in most cases... yes, there were notable
>exceptions - the languages, which substantially influences the matter - first
>trio - Fortran, Algol, COBOL, then LISP, Basic, Simula-67, SmallTalk, then C
>and Pascal, then C++ and Visual Basic. (This is not the list of my favorite
>languages - for example, I certainly like APL much better that Basic, but I
>think that for now Basic influences the general notion of software much more
>than APL; and I do not speak here about theoretical understanding, therefore
>I did not include, for example, CLU in this list; and this it the cut for the
>current moment and not an outlook for the whole history - that's why I did not
>include, for example, PL/I). If we lower the barrier then we should, perhaps,
>include SNOBOL and/or Perl (or. perhaps, intermediate AWK) and possibly SQL.

You are mixing popularity, influencing, contribution, all goes into
one cauldron. 

>> >Well, I'll explain how Ada DEFIES general notion of software. Ada does that
>> >in two ways:
>> >
>> >First, Ada expects dealing with detailed specifics of the problem, and detests
>> >generalized approaches that ignore that specifics without prior consideration.
>>
>> Please elaborate this. If you mean generic programming then Ada
>> supports it by having both generics and class-wides.
>
>Surely in Ada generalization constructs are present and perfectly usable -
>Ada has nothing against reasonable generalization. But note that all these
>constructs aren't too user-friendly, they never work automatically or
>implicitly. You have to instantiate generics explicitly - you have to type
>(and then read) an additional line, which is a burden. Not a big burden, but
>nevertheless it works against careless generalizations.

For a good reason so. Generics are itself user-unfriendly and should
be considered as a temporal work-around, until better generic
programming gears will mature.

>Similarly for 
>class-wide programming - you have to type 'Class explicitly and then take
>some consequences.

Yes, because T and T'Class are different types. Messing with that
makes no good.

>Again. not a big burgen, but most programmers will take
>even small, but systematic burden only for a good reason - so it works against
>careless and unreasonable generalizations.
>
>And the same goes all the way with Ada. Just try to increase your speed and
>run carelessly with the banner "I'm creating software!" in your hand - you'll
>immediatiately meet various obstacles and annoyances, which you'll never meet
>in C and you'll never meet major part of them in C++.

You will, just at some later stage of development. You can easily
write templates in C++, but it is very difficult to understand and use
them.

Actually all your arguments are against the modern notion of software
which is more concentrated on re-use, than new design. For very
obvious reasons of course, there are not enough people on earth to
program all that will be needed in the following 50 years, if things
will go as they do.

>While you are close to the problem domain and reflect it precisely in your
>code, Ada do her best for you. But if you try to take a vague (carelessly
>generalized) look to your problem then Ada frowns at you and makes you unhappy.
>
>> >Second, Ada does not recognize software as an application domain that has its
>> >own specifics - domain-specific features, primitives and structures. (The fact
>> >that Ada somehow recognizes several other languages is largely irrelevant to
>> >the issue.)
>>
>> I don't understand this. Should it mean that, say, ClearCase cannot be
>> written in Ada?
>
>I'm not familiar with ClearCase, I'm only vaguely aware of it, but I think
>it doesn't matter here. Certainly, ClearCase as well as any other user-mode
>program/system can be written in Ada. And it can be written in Perl or, say,
>Visual Basic also. Are there Ada features that will help make the ClearCase
>better (comparing with making it with C++ or Perl or Visual Basic)? Are there
>particularly suitable notations, well-thought useful attributes or anything
>else particularly good for this specific purpose? I think no, there aren't
>such features in Ada.

Did you participate a medium-sized project in C++ or Basic?

>> I see, you would enjoy experimental software dealing with your
>> bank account,
>
>Although I have none (remember, I live in Russia, and I'm neither former
>parteigenosse nor "new Russian" nor a bandit, and I'm not affiliated with
>either kind, so this shouldn't be too surprising), nevertheless from time to
>time I'm asked privately (by a friend who works for a bank here) for some
>general advice regarding banking software - usually concerning problems with
>either experimental software or migration to new version. Well, I do not
>enjoy those stories, sometimes I even sighed after that - there are too much
>stupidity, incompetence and indifference... and note that many "procedures"
>are supposedly present, but they are too often either ignored or avoided or
>distorted or simply aren't understood or aren't known by relevant personnel
>or are blindly copied from foreign ones without necessary adaptation/customization.
>
>> controlling the nuclear reactor 30 miles away,
>
>Interesting, how far you think is the Sosnovyi Bor power plant with 4 big
>nuclear reactors from south-east of Saint-Petersburg(Russia) where I live?

Not much far, right?

>I can tell you that I still don't see too much danger from it - mostly because
>there are still enough scientific power in nearby institutes.

Because it is not directly controlled by software. Yet.

>Certainly, that
>scientific power and correspondily indirect control is gradually weaking in
>some important aspects, but I think that former surplus was so large that we
>still have enough. At the same time I believe that stopping that plant would
>create a whole gallery of disasters caused directly or indirectly by deficit
>of electricity.

And you will appreciate somebody who will write a program for it. In a
language of great influence on the notion of software, surely, under
Windows XP, so that latest bug fixes could be downloaded directly from
Internet, while personnel could savour the cutting edge of technology
surfing in Internet. I believe that the reactor will enjoy it too!

>> managing the air bag in your car.
>
>I never had a car (and also never had driving license), so it shouldn't be
>too surprizing that I don't know what is exactly an air bag. Perhaps I know
>something about it - if it is something traditional and not relatively recent
>invention (as I studied car construction in my childhood), but just don't know
>that English term. So, not knowing what that air bag is and which is its role,
>I can't estimate consequences of its malfunction.

It is a plastic pillow inflated when car collides with an obstacle. It
is around for many years. A recent idea is to replace its simple
sensor by a computer controlled system which will detect crashes
before they happen. In the effect air bags will be inflated by
software. There are also other interesting innovations: brake-by-wire,
stir-by-wire, which names need not to be explained. Enjoy!

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marius Amado Alves]

On Wednesday 21 April 2004 10:29, Dmitry A.Kazakov wrote:
> ... air bags will be inflated by
> software. There are also other interesting innovations: brake-by-wire,
> stir-by-wire, which names need not to be explained. Enjoy!

(Getting off topic.)

My wife had a nasty experience with our Citroen Xsara Picasso. Doing a curve 
she turned the driving wheel but the damn machine didn't respond until the 
last split second before hitting the road side barrier (she didn't hit). 
Maybe the driving wheel is sending emails! We're still driving the same car 
thou. Maybe we should know better and change. But to what? Is there an 100% 
Ada car out there?

The travel computer also goes beserk often with simple things (the radio does 
not turn on, or off, etc.) We have to stop, turn off the engine, with 15 
secs, and turn it on again! This used to be a joke a couple of years back, 
now it's real!

And I'm always expecting the 4 or 6 or 8 airbags to inflate some day for no 
reason, as it has been reported to happen.

And the user interface really sucks.

/* I feel a bit more safer and confortable driving our little Fiat Punto. And 
before I had a Hunday Atos, a Fiat Panda, a Citroen AX, a Renault 5, a Ford 
can't-remember-the-modelname, a Fiat 600, and a Fiat 850 sport coupe. All 
really nice, except the AX which had unreliable electric windows. You'd like 
to keep it simple. But unfortunately you have to 'upgrade' to escape rising 
maintance costs. An then you have to buy and live with all the stupid 
innovations. */

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-04-21, Marius Amado Alves <maa@liacc.up.pt> wrote:
> My wife had a nasty experience with our Citroen Xsara Picasso. Doing a curve 
> she turned the driving wheel but the damn machine didn't respond until the 
> last split second before hitting the road side barrier (she didn't hit). 
> Maybe the driving wheel is sending emails! We're still driving the same car 
> thou. Maybe we should know better and change. But to what? Is there an 100% 
> Ada car out there?

Isn't the steering mechanical? 


-- 
Preben Randhol -------- http://www.pvv.org/~randhol/

()  "Violence is the last refuge of the incompetent"
/\                                   - Isaac Asimov

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marius Amado Alves]

On Wednesday 21 April 2004 12:50, Preben Randhol wrote:
> On 2004-04-21, Marius Amado Alves <maa@liacc.up.pt> wrote:
> > My wife had a nasty experience with our Citroen Xsara Picasso. Doing a
> > curve she turned the driving wheel but the damn machine didn't respond
> > until the last split second before hitting the road side barrier (she
> > didn't hit). Maybe the driving wheel is sending emails! We're still
> > driving the same car thou. Maybe we should know better and change. But to
> > what? Is there an 100% Ada car out there?
>
> Isn't the steering mechanical?

The steering wheel, the interface, is a normal steering wheel, but that may be 
an atavism from the old days when everything was mechanical i.e. I don't know 
if the communication to the real wheels is mechanical. I know it is 
"assisted" i.e. there is some kind (mechanical, possibly hidraulical) of 
augmentation of the human driver's force--a standard feature in all modern 
cars.

(Personally I'd prefer a joystick or a touch screen or something like that if 
the communication is not mechanical, but that's a clever innovation and thus 
it's going to take a long time to happen because stupid innovations are first 
and the designers and perhaps the market seem to like stupid atavisms. Like 
the driving wheel, also the current form of the gear, accelerator, and break 
controls are atavisms. And windows, radio, etc. A rational modern car would 
have *all* controls on a touch screen in front of the driver. Ok, maybe leave 
something for the feet, to free your hands a little.

Incidently, at least in Portugal it is very hard to find an automatic gear 
model. People seem to like exercizing their left leg to exaustion and having 
their rigth hand occupied all time during traffic jams.)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-04-21, Marius Amado Alves <maa@liacc.up.pt> wrote:

> The steering wheel, the interface, is a normal steering wheel, but
> that may be an atavism from the old days when everything was
> mechanical i.e. I don't know if the communication to the real wheels
> is mechanical. I know it is "assisted" i.e. there is some kind
> (mechanical, possibly hidraulical) of augmentation of the human
> driver's force--a standard feature in all modern cars.

If I remember correctly it is not allowed to have a steeringsystem in a
car in Norway that isn't mechanical. I mean servo-steering is allowed,
but you cannot put a joystick in your car and use this to steer with if
you understand what I mean.

> (Personally I'd prefer a joystick or a touch screen or something like
> that if the communication is not mechanical, but that's a clever

I would never want this as I bet the cars would have a C/C++/Java
steering system. And of course : "All electronic equipment such as mobile
telephone, radio transmitters and receivers must be turned off
during this drive ..."

> A rational modern car would have *all* controls on a touch screen in
> front of the driver. Ok, maybe leave something for the feet, to free
> your hands a little.

Let us hope for your sake that the battery doesn't malfunction. It is
not for nothing that modern cars with electric windows is equipped with
a small hammer so you can break the glass and get out in case you
crash/drive into a lake and cannot get the window open due to
the electricity failing...

-- 
Preben Randhol -------- http://www.pvv.org/~randhol/

()  "Violence is the last refuge of the incompetent"
/\                                   - Isaac Asimov

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marius Amado Alves]

> ... it is not allowed to have a steeringsystem in a
> car in Norway that isn't mechanical. I mean servo-steering is allowed...

Curiously enough, servo also introduced problems. I know first hand of an 
accident caused by a person used to servobreaks but that was driving an 
nonservo and failed to push the pedal hard enough. Just a story.

> ... Let us hope for your sake that the battery doesn't malfunction...

Of course the all 'virtual' control system would include reliability features. 
Cannot be just a laptop sending emails to the breaks. There are lots of 
feasible ways to attain a reliable system. SPARK comes to mind. For the 
energy an array of redundant small batteries with capacity for say 1 minute 
upon failure of one of them or of the big one(s). The time enough to stop the 
car. Everything else would be redundant too. Etc. Mechanical systems fail 
too. And these are more hard to make redundant. Well, just my expectations of 
where the car industry should be now, or at least driving at.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Wed, 21 Apr 2004 16:30:23 +0100, Marius Amado Alves
<maa@liacc.up.pt> wrote:

>Of course the all 'virtual' control system would include reliability features.

It is not required by law, so it will not happen.

>Cannot be just a laptop sending emails to the breaks. There are lots of 
>feasible ways to attain a reliable system.

Yes

>SPARK comes to mind.

I have talks with some people in charge. Those (overwhelming minority)
who knows, are against Ada. (To be honest, they are also against C++.)
The majority is against any kind static analysis.

>For the 
>energy an array of redundant small batteries with capacity for say 1 minute 
>upon failure of one of them or of the big one(s). The time enough to stop the 
>car. Everything else would be redundant too. Etc. Mechanical systems fail 
>too. And these are more hard to make redundant. Well, just my expectations of 
>where the car industry should be now, or at least driving at.

My impression is that the reality is. Each penny to spare will be. The
least important issue is considered to be software. Software is
already used and will continue to be for patching hardware problems.

Legally, if you make a crash due to software malfunction, it will be
technically almost impossible to prove that in court. So you will be
responsible.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Frank J. Lhota]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnc8co0d.25m.randhol+valid_for_reply_from_news@rong.nt.ntnu.no...
> Isn't the steering mechanical?

Possibly not. But imagine the stress of finding your steering wheel
inoperable as your instrument panel displays a message about an unhandled
exception!

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Marius Amado Alves <maa@liacc.up.pt> wrote:

: An then you have to buy and live with all the stupid 
: innovations.

Help the software industry :-) Have you ever watched
"Trafic" by Jaques Tati (1971)?


Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> You will, just at some later stage of development. You can easily
> write templates in C++, but it is very difficult to understand and use
> them.

You just don't like generics. C++ templates are neither difficult
to understand nor to use, any more than Ada is. Just like Ada, it
helps if you learn about them correctly.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Hyman Rosen wrote:

>C++ templates are neither difficult
>to understand nor to use, any more than Ada is.

Yes, both aren't difficult to use, but both are quite difficult to understand
and to use properly in even slightly non-trivial cases.

> Just like Ada, it helps if you learn about them correctly.

And this is also true, but it is not easy to learn about them correctly.
In fact, I think that majority of working programmers aren't able to do so.
And those who are able to learn are, as a rule, deprived from a condensed
explanation of the essentials, short explanation of the fundamental approach.

Personally, Ada generics were murky for me before I read one message from
Bob Duff (I think it was in Ada-Comment) where the essential (for me) truth
was said explicitly and in short words. Similarly, C++ templates were murky
for me until just about one or two weeks ago, before I read here in c.l.a.
your (yes, yours -:) short explanation on that matter.

I'm not saying that in both cases the needed explanations are missing in the
well-known books - I don't know that, perhaps they are there. But anyway it is
too hard to find and recognize their importance in those thick books, even if
they are present there.

And I'm not saying that these short explanations are enough, not at all, the
books still must be read, but with those prior explanations this reading will
be (mostly) guided unfolding and refinement, and not a mining followed by
attempts to construct something usable from obtained pieces.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Hyman Rosen]

Alexander E. Kopilovich wrote:
> And this is also true, but it is not easy to learn about them correctly.
> In fact, I think that majority of working programmers aren't able to do so.
> And those who are able to learn are, as a rule, deprived from a condensed
> explanation of the essentials, short explanation of the fundamental approach.

I remember back when I was in college and first learning C,
it took me quite a while before I "got" pointers. Then all
of a sudden something just snapped and it all made sense.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-04-22, Hyman Rosen <hyrosen@mail.com> wrote:
> I remember back when I was in college and first learning C,
> it took me quite a while before I "got" pointers. Then all
> of a sudden something just snapped and it all made sense.

Or rather it all made non-sense ;-)

-- 
Preben Randhol -------- http://www.pvv.org/~randhol/

()  "Violence is the last refuge of the incompetent"
/\                                   - Isaac Asimov

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> >I must confess that this is unimaginable for me - how any programming language
> >> >can DEFINE general notion of software.
> >>
> >> Any language defines the subject of talking.
> >
> >A loud shot, but a miss - because we don't (and can't) talk about general
> >notion of software in Ada.
>
> How so?

Oh, I understand - you mean that we can say anything in Ada using Ada's String
literals. Yes, we can, but Ada this method does not establish any real
connection between Ada language and the contents of that talk.

> >> any programming language, Ada, C++, etc define, form,
> >> influence the notion of software.
> >
> >It does not define or form, but at most contribute something to those notion.
>
> I do not see any difference.

Well, does one person's will define or form the politics of the country?
I suppose you'll agree that this happen sometimes, but very rarely; and that
most common case is that persons contribute more to that, some less. and
most of citizens of the country contribute very little to that. Is it correct
to say that such a person, who contribute very little to that, defines or
forms politics of the country?

> You are mixing popularity, influencing, contribution, all goes into
> one cauldron. 

It is quite common and respectable methodology - to mix differences in X, Y
and Z coordinates of two objects in some mystical formula for obtaning the
distance between them, isn't it?

> >And the same goes all the way with Ada. Just try to increase your speed and
> >run carelessly with the banner "I'm creating software!" in your hand - you'll
> >immediatiately meet various obstacles and annoyances, which you'll never meet
> >in C and you'll never meet major part of them in C++.
>
> You will, just at some later stage of development.

This is very important - at some later stage. It may be very bad for the
project schedule and even for the released product, but still it is perceived
as a good thing by many programmers. And they have their reasons - it may be
simply intolerable to sit in the dark or desperately fighting with surrounding
hostile obstacles for too long; there is a need to move somewhere for taking
a breath. Not mentioning that "later" may never happen - either for the whole
project or for this particular individual.

> Actually all your arguments are against the modern notion of software
> which is more concentrated on re-use, than new design. For very
> obvious reasons of course, there are not enough people on earth to
> program all that will be needed in the following 50 years, if things
> will go as they do.

> Did you participate a medium-sized project in C++ or Basic?

I don't know what you mean by "medium-sized", but I think I was... I think
that happened twice. One time it was typical outsourcing, and it was an awful
mess. Another case was much better, but I can't say that I was really
"participating" there - my role in the project was very isolated and
temporary, and I had only one contact person. All other C+= projects in which
I participate(d) were (and are) rather small, although in some cases long
enough.

As for Basic - no, never, and I even can't imagine such a horrible thing -
a mid-sized project in Basic -;)

> >> controlling the nuclear reactor 30 miles away,
> >
> >Interesting, how far you think is the Sosnovyi Bor power plant with 4 big
> >nuclear reactors from south-east of Saint-Petersburg(Russia) where I live?
>
> Not much far, right?

Yes. Probably you can find a map in the Net, if you become interested in exact
distance.

> >I can tell you that I still don't see too much danger from it - mostly because
> >there are still enough scientific power in nearby institutes.
>
> Because it is not directly controlled by software. Yet.

Well, I hope that physists will maintain old principle of physics laboratories:
there are no computers, there are devices. All devices must work properly and
reliably, must be checked, maintained etc. There are relatively simple and
there are relatively complex devices, but all they are just devices, and no
one of them is sacred in any way. Workings of all devices must be understood
in full detail, there can't be any gaps, secrets or mystique.

Certainly, there always was and will be pressure for violating this principle.
So there always was and will be fighting for it, sometimes rather fierce
fighting. And morale of physists (as I always understood it, by inheritance...
at least morale Soviet physists of previous generations) permits and even
requires use of any methods, rigid or flexible, and any means, including
forgery, bribery etc. for the defense of this principle.

> >> managing the air bag in your car.
>
> It is a plastic pillow inflated when car collides with an obstacle. It
> is around for many years.

Well, I understand now. Whether it is funny or not, but I still never seen
that thing, although I remember that I was thinking about such thing in my
childhood.

> A recent idea is to replace its simple
> sensor by a computer controlled system which will detect crashes
> before they happen. In the effect air bags will be inflated by
> software. There are also other interesting innovations: brake-by-wire,
> stir-by-wire, which names need not to be explained. Enjoy!

Well, it isn't simple to estimate the balance of probable consequences of that
things, including a redistribution of negative consequences between guilty and
innocent parties.

By the way, I think that a free and open-source emulator of a generic car,
which, in particular, includes all those devices, would be very good thing.
And for those who seek so-called "killer application", I'd like to say that
within this application Ada can really shine.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Thu, 22 Apr 2004 07:15:44 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >> any programming language, Ada, C++, etc define, form,
>> >> influence the notion of software.
>> >
>> >It does not define or form, but at most contribute something to those notion.
>>
>> I do not see any difference.
>
>Well, does one person's will define or form the politics of the country?
>I suppose you'll agree that this happen sometimes, but very rarely; and that
>most common case is that persons contribute more to that, some less. and
>most of citizens of the country contribute very little to that. Is it correct
>to say that such a person, who contribute very little to that, defines or
>forms politics of the country?

You cannot estimate it. Unpopularity in science and art tells little
about influence. Do not mix "software pop-culture" with the notion of
software.

>> You are mixing popularity, influencing, contribution, all goes into
>> one cauldron. 
>
>It is quite common and respectable methodology - to mix differences in X, Y
>and Z coordinates of two objects in some mystical formula for obtaning the
>distance between them, isn't it?

There is no warranty that the distance would have any physical sense.

>> >And the same goes all the way with Ada. Just try to increase your speed and
>> >run carelessly with the banner "I'm creating software!" in your hand - you'll
>> >immediatiately meet various obstacles and annoyances, which you'll never meet
>> >in C and you'll never meet major part of them in C++.
>>
>> You will, just at some later stage of development.
>
>This is very important - at some later stage. It may be very bad for the
>project schedule and even for the released product, but still it is perceived
>as a good thing by many programmers.

But notion of software deals with all stages of its production and
use, I hope.

>And they have their reasons - it may be
>simply intolerable to sit in the dark or desperately fighting with surrounding
>hostile obstacles for too long; there is a need to move somewhere for taking
>a breath.

Managers could invite a strolling circus to entertain frustrated
programmers! (:-))

>Not mentioning that "later" may never happen - either for the whole
>project or for this particular individual.

Ah, that is the notion of software Ada defies. I see.

>> A recent idea is to replace its simple
>> sensor by a computer controlled system which will detect crashes
>> before they happen. In the effect air bags will be inflated by
>> software. There are also other interesting innovations: brake-by-wire,
>> stir-by-wire, which names need not to be explained. Enjoy!
>
>Well, it isn't simple to estimate the balance of probable consequences of that
>things, including a redistribution of negative consequences between guilty and
>innocent parties.

No, it is absolute clear. Customer (you) pays for all.

>By the way, I think that a free and open-source emulator of a generic car,
>which, in particular, includes all those devices, would be very good thing.

Come on. All specifications and all protocols are strict secret. The
system is absolutely unprotected. If you know the protocol and can
connect to a car field bus (the devices are free to buy), then you can
do everything with it. Starting from resetting your car mileage,
ending with taking control over the brake pedal. In a close future you
will need no device to do that. A cell phone could be sufficient to
break into.

>And for those who seek so-called "killer application", I'd like to say that
>within this application Ada can really shine.

Utopia

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >[...] Is it correct
> >to say that such a person, who contribute very little to that, defines or
> >forms [...] ?
>
> You cannot estimate it.

Interesting. So you can easily imagine a situation, in which a person who
contributes very little (in any way) to the whole nevertheless can define or
form that whole. This implies that you think that common definitions and forms
are terribly unstable.

> Unpopularity in science and art tells little about influence.

Well, not little, although certainly not too much, especially if you measure
(un)popularity in general audience that is not closely connected to the
influenced subject. Popularity is just one of the ways for influencing, among
other ways.

> Do not mix "software pop-culture" with the notion of software.

Well, I'd prefer the term "mid-culture" if I were going to mix the notion of
software with something.

> There is no warranty that the distance would have any physical sense.

You are so fixed on warranties that I wonder whether there is a warranty that
the warranties you already collected aren't false.

As for the physical sense of distance, I'd like to assure you that the
classical distance still has solid physical sense, although it is true that
you most probably can't win Nobel prize for pronouncing and defending this
thesis.

> But notion of software deals with all stages of its production and
> use, I hope.

This isn't so simple as it may seem. A person developed some software and
was paid for that. Then the same person uses another software, paying for
that. You can see that money intervene in the middle of the production-use
chain, and broke it for that person. Most often even programmers don't use
software for which they are paid. So, although from an external, theoretical
viewpoint the notion of software indeed deals with all stages of lifecycle,
from other viewpoints, including those of users and even of many programmers,
an outlook is quite different.

> >> A recent idea is to replace its simple
> >> sensor by a computer controlled system which will detect crashes
> >> before they happen. In the effect air bags will be inflated by
> >> software. There are also other interesting innovations: brake-by-wire,
> >> stir-by-wire, which names need not to be explained. Enjoy!
> >
> >Well, it isn't simple to estimate the balance of probable consequences of that
> >things, including a redistribution of negative consequences between guilty and
> >innocent parties.
>
>No, it is absolute clear. Customer (you) pays for all.

I think that not only customer, but a vendor (managers, shareholders, and
their relatives) also will participate in the payment - for example, as 
innocent party, being hit by a car produced by another vendor.

> >By the way, I think that a free and open-source emulator of a generic car,
> >which, in particular, includes all those devices, would be very good thing.
>
> Come on. All specifications and all protocols are strict secret.

It reminds me a secret military constant Pi. Note, though, that the exact
number of digits of Pi used in particular computation may be indeed a secret,
which is hard to obtain.

> The system is absolutely unprotected. If you know the protocol and can
> connect to a car field bus (the devices are free to buy), then you can
> do everything with it. Starting from resetting your car mileage,
> ending with taking control over the brake pedal. In a close future you
> will need no device to do that. A cell phone could be sufficient to
> break into.

You forgot to add that there will be no windows in a car - there will be
thin displays instead of them. These displays will show augmented reality -
using onboard external cameras, satellite TV and wireless broadband Internet
and mixing all that into combined picture (with ads, of course).

> >And for those who seek so-called "killer application", I'd like to say that
> >within this application Ada can really shine.
>
> Utopia

Perhaps. But not so wild as you may think of it. There are examples of
programs that seemed unrealistic for the similar reasons, but nevertheless
were created and worked brilliantly for many users. I know at least one such
example - Copilot, original PalmOS emulator. It was developed by a single
person (as far as I remember 2 or 3 persons joined at later stages of the
development), and released as freeware. (After it gained big popularity it
was taken by Palm, Inc for support and maintenance, but continue to be
freeware.) 



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Fri, 23 Apr 2004 06:30:02 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >[...] Is it correct
>> >to say that such a person, who contribute very little to that, defines or
>> >forms [...] ?
>>
>> You cannot estimate it.
>
>Interesting. So you can easily imagine a situation, in which a person who
>contributes very little (in any way) to the whole nevertheless can define or
>form that whole. This implies that you think that common definitions and forms
>are terribly unstable.

Yes. Many prominent figures contributed little or nothing. Similarly
many great scientists and artists were unknown at their time. Examples
are at your choice. 

>> There is no warranty that the distance would have any physical sense.
>
>You are so fixed on warranties that I wonder whether there is a warranty that
>the warranties you already collected aren't false.

Science deals with facts.

>As for the physical sense of distance, I'd like to assure you that the
>classical distance still has solid physical sense,

Your example was 1) to get *arbitrary* measures, 2) to combine them in
a vector, and finally 3) to apply (euclidean?) distance to it. I
assure you that it most cases the result has absolutely no sense, i.e.
shows nothing. It is a known problem in pattern recognition.

>although it is true that
>you most probably can't win Nobel prize for pronouncing and defending this
>thesis.
>
>> But notion of software deals with all stages of its production and
>> use, I hope.
>
>This isn't so simple as it may seem. A person developed some software and
>was paid for that. Then the same person uses another software, paying for
>that. You can see that money intervene in the middle of the production-use
>chain, and broke it for that person. Most often even programmers don't use
>software for which they are paid. So, although from an external, theoretical
>viewpoint the notion of software indeed deals with all stages of lifecycle,
>from other viewpoints, including those of users and even of many programmers,
>an outlook is quite different.

If you want to tell that there are problems with software in our
society, then yes, that was my original point.

In my view the whole model of selling software is wrong. Because
effectively you can only sell something, that cannot be copied with so
little efforts. It does not work. I think that software should be
considered rather as an insurance against its fault. That should be
sold, not a stream of bits. This is why I am promoting the idea of
liability.

>> >> A recent idea is to replace its simple
>> >> sensor by a computer controlled system which will detect crashes
>> >> before they happen. In the effect air bags will be inflated by
>> >> software. There are also other interesting innovations: brake-by-wire,
>> >> stir-by-wire, which names need not to be explained. Enjoy!
>> >
>> >Well, it isn't simple to estimate the balance of probable consequences of that
>> >things, including a redistribution of negative consequences between guilty and
>> >innocent parties.
>>
>>No, it is absolute clear. Customer (you) pays for all.
>
>I think that not only customer, but a vendor (managers, shareholders, and
>their relatives) also will participate in the payment - for example, as 
>innocent party, being hit by a car produced by another vendor.

Managers are on foot only when playing golf (:-))

>> >By the way, I think that a free and open-source emulator of a generic car,
>> >which, in particular, includes all those devices, would be very good thing.
>>
>> Come on. All specifications and all protocols are strict secret.
>
>It reminds me a secret military constant Pi. Note, though, that the exact
>number of digits of Pi used in particular computation may be indeed a secret,
>which is hard to obtain.

Beware, you could be punished for evaluation of Pi under DCMA law!

>> The system is absolutely unprotected. If you know the protocol and can
>> connect to a car field bus (the devices are free to buy), then you can
>> do everything with it. Starting from resetting your car mileage,
>> ending with taking control over the brake pedal. In a close future you
>> will need no device to do that. A cell phone could be sufficient to
>> break into.
>
>You forgot to add that there will be no windows in a car - there will be
>thin displays instead of them. These displays will show augmented reality -
>using onboard external cameras, satellite TV and wireless broadband Internet
>and mixing all that into combined picture (with ads, of course).

What I wrote about is not a joke. The navigation system, radio, CD
player etc, all that will be connected to the field bus. They will
also have Bluetooth and Internet connections. This will open wide
possibilities for attacks of all sorts.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >Interesting. So you can easily imagine a situation, in which a person who
> >contributes very little (in any way) to the whole nevertheless can define or
> >form that whole. This implies that you think that common definitions and forms
> >are terribly unstable.
>
> Yes. Many prominent figures contributed little or nothing.

So they did not define or form anything - except, perhaps, of their
biographies to which they surely contribute a lot, and the derivates of
those biographies.

> Similarly many great scientists and artists were unknown at their time.

They might be unknown personally but nevertheless their contribution might
have very significant immediate effect. In other cases they did not define or
form anything in their profession *in their time*, but their significant
contribution became relevant and effectuated and appreciated much later.

> Science deals with facts.

Science traditionally deals with observations, theories, notations and
methods of argumentation.

Modern science deals also with budgets, management, conferences, grants,
degrees and citations.

As for facts - yes, they may be observed and/or interpreted scientifically.

> >As for the physical sense of distance, I'd like to assure you that the
> >classical distance still has solid physical sense,
>
> Your example was 1) to get *arbitrary* measures,

Certainly not arbitrary. No one sane adult person (even no eccentric one)
tries to eat arbitrary things (for example - CD-ROMs). But tastes, care for
health and simply curiosity - certainly differs among the people.

> 2) to combine them in
> a vector, and finally 3) to apply (euclidean?) distance to it. I
> assure you that it most cases the result has absolutely no sense, i.e.
> shows nothing.

In physics (well, traditional physics) the result is subject of subsequent
checks, where various theoretical implications of that result are tested in
appropriate experiments. If the whole picture appears consistent then that
result is perceived as probably valid; and if it appears significantly useful
for structuring, refining or extending theories then it is usually declared
as having (physical) sense.

> It is a known problem in pattern recognition.

Always being deeply interested in the theme of pattern recognition, I
nevertheless do not think that there is any real link to it. Well, almost all
cognitive processes may be considered as a pattern recognition at one or
another or several levels. But such a viewpoint becomes fruitful relatively
rarely, because it isn't enough to pronounce magic words "Pattern Recognition".
We should be able to make conclusions ad/or refinements after that - and very
often it appears that we can't do that, because the theories and techniques
(of pattern recognition) at our disposal are too scattered and weak.

> In my view the whole model of selling software is wrong.

Well, it would be too wild for me to discuss models of selling software -
because I feel myself highly incompetent is selling anything. All software
that I sold *on open market* for now consists of several Delphi components,
and my total income (for about 5 years of selling) from that well compares
with my 1-month income from work for a customer.

By the way, just curious, did you sell *anything* *on open market* (shareware
or commercial product) ? I ask you about this because I know too well, that
many very good and skilled programmers never did that, and surprizingly, that
lack of either practical or theoretical experience in the matter do not
detract them proposing radical measures for the software market.

> Because
> effectively you can only sell something, that cannot be copied with so
> little efforts. It does not work.

Well, ACT sells support, and this thing can't be copied with so little efforts.

> I think that software should be
> considered rather as an insurance against its fault. That should be
> sold, not a stream of bits.

But the support - if it is real - is a form of insurance, a soft form, of
course (which sounds appropriate for *soft*ware -:). Actually, it is an
anticipation of possible need of support that sometimes pushes a user to buy 
the product, and not just copy it from elsewhere. But for that the support
must be real, it should not be restricted to the product itself, it should be
present, however informally, for the product's environment and usage also.

> This is why I am promoting the idea of liability.

I think that liability is actually in effect - not legal liability, but market
liability - not in the form of fines, but in the form of losses of income.
Yes, there are innocent parties that suffered from this form of liability
(usual argument of "anti-piracy" propaganda), but I think that most of those
innocent parties will be simply killed (as participants of the market) by
introducing an effective legal liability. Do you really want that New Order?

> >> >By the way, I think that a free and open-source emulator of a generic car,
> >> >which, in particular, includes all those devices, would be very good thing.
> >>
> >> Come on. All specifications and all protocols are strict secret.
> >
> >It reminds me a secret military constant Pi. Note, though, that the exact
> >number of digits of Pi used in particular computation may be indeed a secret,
> >which is hard to obtain.
>
> Beware, you could be punished for evaluation of Pi under DCMA law!

Hunters usualy do not pursue poisonous species (if the latter do not attack
them directly). I mean that I would not advice DCMA attack me - it will be
heavily intoxicated in such a case, I think.

> >> The system is absolutely unprotected. If you know the protocol and can
> >> connect to a car field bus (the devices are free to buy), then you can
> >> do everything with it. Starting from resetting your car mileage,
> >> ending with taking control over the brake pedal. In a close future you
> >> will need no device to do that. A cell phone could be sufficient to
> >> break into.
> >
> >You forgot to add that there will be no windows in a car - there will be
> >thin displays instead of them. These displays will show augmented reality -
> >using onboard external cameras, satellite TV and wireless broadband Internet
> >and mixing all that into combined picture (with ads, of course).
>
> What I wrote about is not a joke.

I fully understand that you are not joking, but I think you are too and
prematurely alarmed, and are taking some alarmist attitude. I believe that
being professionally alarmed we should think about what we personally and
realistically can do about the anticipated danger, and not just weep among
the friends and colleagues and not try to substitute professional alarmists.

> The navigation system, radio, CD
> player etc, all that will be connected to the field bus. They will
> also have Bluetooth and Internet connections. This will open wide
> possibilities for attacks of all sorts.

All that is quite obvious, and car vendors personnel (including their
software engineers) are neither preschool kids nor full idiots. After all,
probably they all have cars.

But nevertheless, I think that a free and open-source emulator of generic car
would be a good thing. And that Ada 2005 would be very appropriate programming
language for this purpose.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Sat, 24 Apr 2004 05:28:52 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> Science deals with facts.
>
>Science traditionally deals with observations, theories, notations and
>methods of argumentation.

... based on facts

>Modern science deals also with budgets, management, conferences, grants,
>degrees and citations.

that's scientific bureaucracy 

>By the way, just curious, did you sell *anything* *on open market* (shareware
>or commercial product)?

The firm I am working in, sells several commercial products.

> I ask you about this because I know too well, that
>many very good and skilled programmers never did that, and surprizingly, that
>lack of either practical or theoretical experience in the matter do not
>detract them proposing radical measures for the software market.

You need not to have any experience to see what is going on. Though it
is not clear what sort of experience you meant, because there is no
true science dealing with market economy. Well, there are many people,
who count themselves as scientists. Unfortunately all their theories
lack any prediction power.

>> Because
>> effectively you can only sell something, that cannot be copied with so
>> little efforts. It does not work.
>
>Well, ACT sells support, and this thing can't be copied with so little efforts.

Yes, I meant ACT model as an example of how things could work.

>> I think that software should be
>> considered rather as an insurance against its fault. That should be
>> sold, not a stream of bits.
>
>But the support - if it is real - is a form of insurance, a soft form, of
>course (which sounds appropriate for *soft*ware -:). Actually, it is an
>anticipation of possible need of support that sometimes pushes a user to buy 
>the product, and not just copy it from elsewhere. But for that the support
>must be real, it should not be restricted to the product itself, it should be
>present, however informally, for the product's environment and usage also.

I meant only the law, which should treat sold software as an insurance
contract rather than a "right to use". At least contract parties
should have equal rights.

>> This is why I am promoting the idea of liability.
>
>I think that liability is actually in effect - not legal liability, but market
>liability - not in the form of fines, but in the form of losses of income.

This does not work. Software market chooses the worst.

>Yes, there are innocent parties that suffered from this form of liability
>(usual argument of "anti-piracy" propaganda),

Not at all. In the "insurance" model, anybody should have a "born" to
right to use any software.

>but I think that most of those
>innocent parties will be simply killed (as participants of the market) by
>introducing an effective legal liability.

Insurance is one of the most profitable businesses.

>Do you really want that New Order?

I don't. So I don't want DCMA and Microsoft.

>> The navigation system, radio, CD
>> player etc, all that will be connected to the field bus. They will
>> also have Bluetooth and Internet connections. This will open wide
>> possibilities for attacks of all sorts.
>
>All that is quite obvious, and car vendors personnel (including their
>software engineers) are neither preschool kids nor full idiots. After all,
>probably they all have cars.

There is a overwhelming force of market overriding everything you have
mentioned. Add here incompetence in software design. So the result is
quite predictable. After all we have examples at hand - how reliable
is PC software?

>But nevertheless, I think that a free and open-source emulator of generic car
>would be a good thing.

What are you going to simulate? Again, the hard-/software is
expensive. A motor simulator is about $15000. A roller dynamometer is
about 5 mio. And, well, who will serve 25 years in jail for cracking
proprietary protocols?

>And that Ada 2005 would be very appropriate programming
>language for this purpose.

Ada 95 + SPARK (for some components) would be ideal. But I doubt it
will be even considered.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Wes Groleau]

Dmitry A. Kazakov wrote:
> On Sat, 24 Apr 2004 05:28:52 +0400 (MSD), "Alexander E. Kopilovich"
> <aek@VB1162.spb.edu> wrote:
> 
>>Dmitry A. Kazakov wrote:
>>>Science deals with facts.
>>
>>Science traditionally deals with observations, theories, notations and
>>methods of argumentation.
> 
> ... based on facts

No.  Good science deduces or induces opinions that are "probably
true" based on observations and measurements.

Bad science (and there is far too much of it) forms
an opinion and tries hard to collect observations
and measurements to persuade people that it's true.

Really bad science, instead of collecting observations
and measurements, invents them.  And sometimes accuses
the good science of being lies.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >Modern science deals also with budgets, management, conferences, grants,
> >degrees and citations.
>
> that's scientific bureaucracy 

Call it what you wish, but take into account that vast majority of scientists
do not oppose it anymore, but participate in all that stuff rather actively.
It is important that all those things influence significantly and sometimes
even effectively determine directions of scientific research. As a consequence
some paradigms take over others in scientific views just because some
scientific directions/fields were more supported recently and thus are better
developed than others.

> >By the way, just curious, did you sell *anything* *on open market* (shareware
> >or commercial product)?
>
> The firm I am working in, sells several commercial products.

There is a huge and principal difference between selling your products on open
market and working for a firm that do that. When you are an individual seller
you take decisions and see immediate results. You choose the price for your
product, and you income depends on whether your guess is right. But when you
work for a firm (not as a top manager, but as a software developer), you do
not take such decisions, and your salary does not immediately depend on the
particular results. Yes, it is possible that you may somehow influence your
firm's decisions regarding product prices and marketing policies in general,
but this is very far from taking decision yourself. If you try that once then
you'll see this acute difference.

> >lack of either practical or theoretical experience in the matter do not
> >detract them proposing radical measures for the software market.
>
>You need not to have any experience to see what is going on.

You may need not much experience to see that something is going wrong, but
you certainly need some experience to propose particular measures - because
without that experience your propositions probably will make things even worse.

> Though it
> is not clear what sort of experience you meant,

I meant practical experience - just create at least one software product and
sell it yourself - either as a invidividual or as a top manager of a firm,
regardless of the firm's size. After that you most probably will not be so
sure that liability for software products is a good thing.

I understand, though, that surrounding environment probably influences you.
Let me tell you briefly a real story. Several years ago I received a
proposition for a contract and it appeared that for that contract I must sign
NDA for 25 years (!) with huge fines in a case of violation. It was from
Germany. I think that any sane American will never propose such an unrealistic
NDA; but a perfectly sane man from Germany (nationality means little here)
will and indeed was. Naturally, I refused to sign that NDA. After that the NDA
was rewritten, it was made for 3 or 5 years and fines were reduced drastically
(after that they still were much higher that the amount of payment for the
work). Then I signed that NDA and the contract was succesfully completed.
This story shows one thing: in Germany the difference between 25-year NDA and
5-year NDA is not perceived as significant. And in this specific atmosphere
you may think that user of a software product will sue the vendor for a good
reason only, that is, when s/he discovers a defect in the product, and
moreover, a defect that actually harmed or annoyed the user.  In short words,
you suppose that a user will be, as a rule, perfectly honest and reasonably
literate.

> because there is no
> true science dealing with market economy. Well, there are many people,
> who count themselves as scientists. Unfortunately all their theories
> lack any prediction power.

I don't know whether there is true science dealing with market economy or not,
but certainly there can't be a science that will reliably predict where you
will find a bag of money waiting for you. There may be an art, which uses some
scientific theories and methods as some of its tools, but no more. Science
always is external to its subject, and money is practically omnipresent in a
market economy. But it does not mean that a science can't predict anything
significant in market economy; the limitation is simple: science can't predict
anything that will permit you to device a guaranteed (and legal!) way to 
wealth -;) .

Recall quantum mechanics - it is a science, and there are things, which it
can predict, but there are also severe limitations to its prediction power.

> I meant only the law, which should treat sold software as an insurance
> contract rather than a "right to use". At least contract parties
> should have equal rights.

I don't quite understand that: do you mean that some insurance company must
be always involved as a mandatory third party between a vendor and a user?
That is, every software product to be legally sold must be insured by some
insurance firm? Then who will be really (and legally) insured - vendor or 
user?

> >I think that liability is actually in effect - not legal liability, but market
> >liability - not in the form of fines, but in the form of losses of income.
>
> This does not work. Software market chooses the worst.

I don't think so. I don't think that millions of people must have the same
needs and tastes as I and my friends and colleagues have - regarding computers
and software. Even majority of software developers may have other needs,
tastes and priorities.

Note that market never chooses immediately and/or forever. It is a big and
substantially stochasic system, and moreover, it is a multi-dimensional
system. Sometimes we can see some clear and relatively stable preference and
we call it a choice (done by the market). I can't see what can it mean really
that "software market chooses the worst".

> >Do you really want that New Order?
>
> I don't. So I don't want DCMA and Microsoft.

There is a big difference between the Brave New World and the New Order.
Perhaps you are trying to escape from the road to the first one, but
effectively you are calling for the second - at least if you are proposing
direct liability.

> >> The navigation system, radio, CD
> >> player etc, all that will be connected to the field bus. They will
> >> also have Bluetooth and Internet connections. This will open wide
> >> possibilities for attacks of all sorts.
> >
> >All that is quite obvious, and car vendors personnel (including their
> >software engineers) are neither preschool kids nor full idiots. After all,
> >probably they all have cars.
>
> There is a overwhelming force of market overriding everything you have
> mentioned.

How do you know the direction of this force, and whether that direction will
be stable in near future? You just said that there is no science that can
predict market economy.

How do you think, if some car vendors will produce fully computerized cars
that will be obviously unreliable, and at the same time some other car
vendors decided to wait and continue production of not-so-computerized cars,
what will the market choose?

> After all we have examples at hand - how reliable is PC software?

Well, I think that for all reasonable definitions of reliability it is quite
reliable these times = for its diversity, purposes and prices.

For example, I think that in last year Windows 2000 on my PC crashed less
times than electricity in my flat (actually in the whole 14-storey building)
failed. At least I'm sure that these numbers are near each other. So, the
perception of reliability may depend on your country of residence.

> >But nevertheless, I think that a free and open-source emulator of generic car
> >would be a good thing.
>
> What are you going to simulate?

Spaces. Physical spaces - geometry, electricity etc. etc.; informational
spaces; driver spaces and passenger spaces; external spaces - local external
circumstances space, local traffic space etc.

Then came real-world objects, which are collections of their representatives
in various spaces and sets of logical/computational connections between those
their representatives.

> And, well, who will serve 25 years in jail for cracking
> proprietary protocols?

There is absolutely no need to crack anything. First, there probably will not
be anything interesting enough to crack. Second, all those protocols can be
easily imagined - well, they certainly will not be the same as in real cars,
but so what? Those parties who will think that the difference is significant
for them will point on it and provide an information, which will be sufficient
for adjustment or generalization. We simply should not care about the distant
sources of that information, it will be sufficient that information is 
provided publicly, and it need not be exact information - it may be just a
hint.

Although certainly it would be better if the sources of actual car software
were published, as I said some time ago.

> >And that Ada 2005 would be very appropriate programming
> >language for this purpose.
>
> Ada 95 + SPARK (for some components) would be ideal.

Yes, I think that SPARK may be quite useful for some components.

> But I doubt it will be even considered.

Why not? We (or someone else) can consider it. Perhaps you mean car vendors
here, but why should we bother ourselves with *their* problems?



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue, 27 Apr 2004 07:26:01 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >Modern science deals also with budgets, management, conferences, grants,
>> >degrees and citations.
>>
>> that's scientific bureaucracy 
>
>Call it what you wish, but take into account that vast majority of scientists
>do not oppose it anymore, but participate in all that stuff rather actively.

As cynical as "people of Ethiopia do not oppose hunger, but actively
participate it".

>> >By the way, just curious, did you sell *anything* *on open market* (shareware
>> >or commercial product)?
>>
>> The firm I am working in, sells several commercial products.
>
>There is a huge and principal difference between selling your products on open
>market and working for a firm that do that. When you are an individual seller
>you take decisions and see immediate results.

Where you saw individual software sellers? The products we are
developing have weight of many man-years.

>You choose the price for your
>product, and you income depends on whether your guess is right. But when you
>work for a firm (not as a top manager, but as a software developer), you do
>not take such decisions, and your salary does not immediately depend on the
>particular results. Yes, it is possible that you may somehow influence your
>firm's decisions regarding product prices and marketing policies in general,
>but this is very far from taking decision yourself. If you try that once then
>you'll see this acute difference.

What's your point?

>> Though it
>> is not clear what sort of experience you meant,
>
>I meant practical experience - just create at least one software product and
>sell it yourself - either as a invidividual or as a top manager of a firm,
>regardless of the firm's size. After that you most probably will not be so
>sure that liability for software products is a good thing.

Strangely enough that they are sure for almost all other things...

>Recall quantum mechanics - it is a science, and there are things, which it
>can predict, but there are also severe limitations to its prediction power.

You are comparing limitations of something with nothing.

>> I meant only the law, which should treat sold software as an insurance
>> contract rather than a "right to use". At least contract parties
>> should have equal rights.
>
>I don't quite understand that: do you mean that some insurance company must
>be always involved as a mandatory third party between a vendor and a user?
>That is, every software product to be legally sold must be insured by some
>insurance firm? Then who will be really (and legally) insured - vendor or 
>user?

No, a vendor has to be liable to the software product it sells.
Because software products are not "consumed" as normal products are,
there seems to be only choice between "right of use" and "insurance"
models. "Right of use" model is what we have now. Its disadvantages
are quite clear:

1. It works against quality products;
2. It effectively stops any significant progress by suppressing
competition;
3. It gives customers no protection from fraud;
4. It imposes real threat to basic human rights (see DCMA)

>Note that market never chooses immediately and/or forever. It is a big and
>substantially stochasic system, and moreover, it is a multi-dimensional
>system. Sometimes we can see some clear and relatively stable preference and
>we call it a choice (done by the market).

It is about game rules, which state should impose.

>I can't see what can it mean really
>that "software market chooses the worst".

Sorry for that.

>> >> The navigation system, radio, CD
>> >> player etc, all that will be connected to the field bus. They will
>> >> also have Bluetooth and Internet connections. This will open wide
>> >> possibilities for attacks of all sorts.
>> >
>> >All that is quite obvious, and car vendors personnel (including their
>> >software engineers) are neither preschool kids nor full idiots. After all,
>> >probably they all have cars.
>>
>> There is a overwhelming force of market overriding everything you have
>> mentioned.
>
>How do you know the direction of this force, and whether that direction will
>be stable in near future? You just said that there is no science that can
>predict market economy.

Exactly, this is why your talks about good-will of managers,
engineers, programmers are absolutely irrelevant.

>How do you think, if some car vendors will produce fully computerized cars
>that will be obviously unreliable, and at the same time some other car
>vendors decided to wait and continue production of not-so-computerized cars,
>what will the market choose?

Market already chose. There will be no not-computerized cars. Further
the question is not which features of cars market will choose. It is
about how reliable cars will be. And also, whether our society is
ready to tolerate unreliable cars. So far it was not. Now the real New
Order (=software mess) starts to threat our live in areas we
accustomed to see unconnected to software. This or that way we will
react.

>> And, well, who will serve 25 years in jail for cracking
>> proprietary protocols?
>
>There is absolutely no need to crack anything. First, there probably will not
>be anything interesting enough to crack. Second, all those protocols can be
>easily imagined - well, they certainly will not be the same as in real cars,
>but so what? Those parties who will think that the difference is significant
>for them will point on it and provide an information, which will be sufficient
>for adjustment or generalization. We simply should not care about the distant
>sources of that information, it will be sufficient that information is 
>provided publicly, and it need not be exact information - it may be just a
>hint.

You are mistaken. (I am working with some of these protocols)

>Although certainly it would be better if the sources of actual car software
>were published, as I said some time ago.
>
>> >And that Ada 2005 would be very appropriate programming
>> >language for this purpose.
>>
>> Ada 95 + SPARK (for some components) would be ideal.
>
>Yes, I think that SPARK may be quite useful for some components.
>
>> But I doubt it will be even considered.
>
>Why not? We (or someone else) can consider it. Perhaps you mean car vendors
>here, but why should we bother ourselves with *their* problems?

Because they decide.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 27 Apr 2004 07:26:01 +0400 (MSD), "Alexander E. Kopilovich"

:>Call it what you wish, but take into account that vast majority of scientists
:>do not oppose it anymore, but participate in all that stuff rather actively.
 
: As cynical as "people of Ethiopia do not oppose hunger, but actively
: participate it".

I'd call it observation, not cynism. Things like these have
been published in book form, and have been known for ages.  The
instances controlling the current fashion emplying various forms of
normative forces may have shifted from an explicit institution like
the Holy Inquisition to a "democratic" ruling crowd.

And being mainstream does not necessarily mean being right or wrong
or useless. See Ada.

-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> >Modern science deals also with budgets, management, conferences, grants,
> >> >degrees and citations.
> >>
> >> that's scientific bureaucracy 
> >
> >Call it what you wish, but take into account that vast majority of scientists
> >do not oppose it anymore, but participate in all that stuff rather actively.
>
> As cynical as "people of Ethiopia do not oppose hunger, but actively
> participate it".

Excellent argument for a live debate - thundery, breathtakingly annoying for
the opponent, and distant enough (thus forcing the opponent to extend his
logic to an unanticipated area). But for a slow discussion in a mostly
technical newsgroup these features aren't very important and therefore the
whole argument isn't good here.

It will be too trivial to observe that the scientists who participate in
conferences, earn degrees and obtain grants aren't too hungry, as a rule;
also there are neither signs of prolonged famine in science nor destruction
and exhaustion caused by recent wars. But what isn't so trivial and what is
actually essential, is that more hungry people (more active participants in
hunger, as you put it) in Ethiopia do not hold higher social status, they 
aren't considered more successful, and do not manage, rule and control other
(less hungry) people.

> >There is a huge and principal difference between selling your products on open
> >market and working for a firm that do that. When you are an individual seller
> >you take decisions and see immediate results.
>
> Where you saw individual software sellers?

I'm quite surprised by this question - don't you know, for example, that many
authours of shareware products are individual sellers? Don't you know that
sufficiently many of those shareware products have significant customer base?

> The products we are
> developing have weight of many man-years.

So what? You are very proud of that, aren't you? You think that only those
products that have weight of many man-years have a right to live and/or to be
sold? Well, I'd like to remind you that those Microsoft products, which you
apparently dislike, most probably have weight of many man-years also.

> >You choose the price for your
> >product, and you income depends on whether your guess is right. But when you
> >work for a firm (not as a top manager, but as a software developer), you do
> >not take such decisions, and your salary does not immediately depend on the
> >particular results. Yes, it is possible that you may somehow influence your
> >firm's decisions regarding product prices and marketing policies in general,
> >but this is very far from taking decision yourself. If you try that once then
> >you'll see this acute difference.
>
> What's your point?

My point here is that when you take general and final decision about your
product, you have to take into account much more factors than if you just
influence the decision (note, that multiplicity of factors often precludes
high precision and comprehensive analysis). And when you are taking the
decision you know that you'll deal with possible consequences.

For example, if you product faulted and the user has right to sue for that
then s/he will sue *you*. And then you'll spend time in court, you'll spend
money for lawyers, and even if you win the case, you still may be ruined. And
your competitor can relatively easily provide 10 doubtful cases for you -
just to keep you detracted from your business for some time and as a
consequence - ruined.

> >just create at least one software product and
> >sell it yourself - either as a invidividual or as a top manager of a firm,
> >regardless of the firm's size. After that you most probably will not be so
> >sure that liability for software products is a good thing.
>
> Strangely enough that they are sure for almost all other things...

Nothing strange - they are sure for the things in which they aren't competent
and/or experienced, but the sales is exactly the thing for which they have
to be somehow competent and experienced (otherwise they went bankrupt too 
soon).

> > quantum mechanics - it is a science, and there are things, which it
> >can predict, but there are also severe limitations to its prediction power.
>
> You are comparing limitations of something with nothing.

Something - only for those who knows/understands something, and nothing - for
those who knows and understands nothing except of mass-media presentations of
the subject. I guess that you have read and understand something, however
introductory and scattered, relevant to quantum mechanics in some textbooks,
but at the same time I guess that you totally neglected economical sciences,
permitting newspapers and TV to educate you in that domain.

> >> I meant only the law, which should treat sold software as an insurance
> >> contract rather than a "right to use". At least contract parties
> >> should have equal rights.
> >
> >I don't quite understand that: do you mean that some insurance company must
> >be always involved as a mandatory third party between a vendor and a user?
> >That is, every software product to be legally sold must be insured by some
> >insurance firm? Then who will be really (and legally) insured - vendor or 
> >user?
>
> No, a vendor has to be liable to the software product it sells.
> Because software products are not "consumed" as normal products are,
> there seems to be only choice between "right of use" and "insurance"
> models.

I still can't get why you use term "insurance" here. Vendor and/or seller may
or may not provide a warranty, but "insurance" is typically associated with
third parties, it is a separate business.

> "Right of use" model is what we have now. Its disadvantages
> are quite clear:
>
> 1. It works against quality products;

I think you mean that it permits relatively cheap products of some
not-the-best quality to appear on the market and compete with costly products
of superior quality.

> 2. It effectively stops any significant progress by suppressing
> competition;

What I see in reality is quite rapid progress. One may clain that the progress
might be more rapid and more comprehensive if some other rules were in effect.
But this is just a supposition, rather unfounded. Yes, some things might went
better with other rules, but at the same time some other things (which are 
tolerable with current rules) might went much worse.

> 3. It gives customers no protection from fraud;

But that gives vendors protection from dishonest or simply ignorant suits.

> 4. It imposes real threat to basic human rights (see DCMA)

I can't see how introduction of liability of vendor will prevent or destroy
DCMA and alike.

Generally, I don't see how can your "insurance" (or liability) decrease or
suppress "right of use". I think that you propose to add that liability to
"right of use".

> >Note that market never chooses immediately and/or forever. It is a big and
> >substantially stochasic system, and moreover, it is a multi-dimensional
> >system. Sometimes we can see some clear and relatively stable preference and
> >we call it a choice (done by the market).
>
> It is about game rules, which state should impose.

Do you think that those rules should make the game well-predictable?

> Now the real New Order (=software mess)

I repeat that you dangerously (I hope not intentionally) confuse Brave New
World with New Order.

> >> And, well, who will serve 25 years in jail for cracking
> >> proprietary protocols?
> >
> >There is absolutely no need to crack anything. First, there probably will not
> >be anything interesting enough to crack. Second, all those protocols can be
> >easily imagined - well, they certainly will not be the same as in real cars,
> >but so what? Those parties who will think that the difference is significant
> >for them will point on it and provide an information, which will be sufficient
> >for adjustment or generalization. We simply should not care about the distant
> >sources of that information, it will be sufficient that information is 
> >provided publicly, and it need not be exact information - it may be just a
> >hint.
>
> You are mistaken.

Perhaps. But you are so sure, aren't you?.

> (I am working with some of these protocols)

So you are in difficult position regarding this matter. Some things are too
near to you, distorting the general perspective, and even about those things
you can't speak clearly because of NDAs.

> >Perhaps you mean car vendors
> >here, but why should we bother ourselves with *their* problems?
>
> Because they decide.

They will decide about *their* problems, very well. But they can't effectively
decide about the things that aren't in their control or even influence (so
far).



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Wed, 28 Apr 2004 06:03:22 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >> >Modern science deals also with budgets, management, conferences, grants,
>> >> >degrees and citations.
>> >>
>> >> that's scientific bureaucracy 
>> >
>> >Call it what you wish, but take into account that vast majority of scientists
>> >do not oppose it anymore, but participate in all that stuff rather actively.
>>
>> As cynical as "people of Ethiopia do not oppose hunger, but actively
>> participate it".
>
>Excellent argument for a live debate - thundery, breathtakingly annoying for
>the opponent, and distant enough (thus forcing the opponent to extend his
>logic to an unanticipated area).

Thanks! (:-))

> But for a slow discussion in a mostly
>technical newsgroup these features aren't very important and therefore the
>whole argument isn't good here.

Our off-topic is far from being technical. (:-))

>It will be too trivial to observe that the scientists who participate in
>conferences, earn degrees and obtain grants aren't too hungry, as a rule;
>also there are neither signs of prolonged famine in science nor destruction
>and exhaustion caused by recent wars. But what isn't so trivial and what is
>actually essential, is that more hungry people (more active participants in
>hunger, as you put it) in Ethiopia do not hold higher social status, they 
>aren't considered more successful, and do not manage, rule and control other
>(less hungry) people.

No, the point was that scientists do not willingly anticipate all that
bureaucratic dances, you wrote about. No more than Ethiopians do
hunger. It is merely the price scientists should pay for having an
ability to do science.

>> >There is a huge and principal difference between selling your products on open
>> >market and working for a firm that do that. When you are an individual seller
>> >you take decisions and see immediate results.
>>
>> Where you saw individual software sellers?
>
>I'm quite surprised by this question - don't you know, for example, that many
>authours of shareware products are individual sellers? Don't you know that
>sufficiently many of those shareware products have significant customer base?

Shareware products are irrelevant for the software market. They get
probably less than 0.1% of its volume. They are also irrelevant for
software development as a phenomenon. Because, it is clear that
software cannot be produced by individuals, at least at the current
level of technology. So shareware gives no answer to the question, how
humankind should organize software development.

>> The products we are
>> developing have weight of many man-years.
>
>So what? You are very proud of that, aren't you?

I won't tell you! (:-))

>You think that only those
>products that have weight of many man-years have a right to live and/or to be
>sold?

This is the problem. To solve real problems, you have to deal with
products of mid- and large size. This size switches you from so to say
laws of "quantum mechanics" to the laws of "macro" world. They are
quite different.

>Well, I'd like to remind you that those Microsoft products, which you
>apparently dislike, most probably have weight of many man-years also.

Yes. And not surprisingly quality of a product is inversely
proportional to its size.

>> >You choose the price for your
>> >product, and you income depends on whether your guess is right. But when you
>> >work for a firm (not as a top manager, but as a software developer), you do
>> >not take such decisions, and your salary does not immediately depend on the
>> >particular results. Yes, it is possible that you may somehow influence your
>> >firm's decisions regarding product prices and marketing policies in general,
>> >but this is very far from taking decision yourself. If you try that once then
>> >you'll see this acute difference.
>>
>> What's your point?
>
>My point here is that when you take general and final decision about your
>product, you have to take into account much more factors than if you just
>influence the decision (note, that multiplicity of factors often precludes
>high precision and comprehensive analysis). And when you are taking the
>decision you know that you'll deal with possible consequences.
>
>For example, if you product faulted and the user has right to sue for that
>then s/he will sue *you*. And then you'll spend time in court, you'll spend
>money for lawyers, and even if you win the case, you still may be ruined. And
>your competitor can relatively easily provide 10 doubtful cases for you -
>just to keep you detracted from your business for some time and as a
>consequence - ruined.

Why this does not happen (or very limited) in 90% of all other areas
of business activity, where one can sue? What is so special about
software, which forces us to treat it otherwise?

>> > quantum mechanics - it is a science, and there are things, which it
>> >can predict, but there are also severe limitations to its prediction power.
>>
>> You are comparing limitations of something with nothing.
>
>Something - only for those who knows/understands something, and nothing - for
>those who knows and understands nothing except of mass-media presentations of
>the subject. I guess that you have read and understand something, however
>introductory and scattered, relevant to quantum mechanics in some textbooks,
>but at the same time I guess that you totally neglected economical sciences,
>permitting newspapers and TV to educate you in that domain.

I read Microsoft license. Did you? If yes, then tell me what kind of
knowledge one have to possess to really understand all the secrets of
words "NO WARRANTY"?

>> >> I meant only the law, which should treat sold software as an insurance
>> >> contract rather than a "right to use". At least contract parties
>> >> should have equal rights.
>> >
>> >I don't quite understand that: do you mean that some insurance company must
>> >be always involved as a mandatory third party between a vendor and a user?
>> >That is, every software product to be legally sold must be insured by some
>> >insurance firm? Then who will be really (and legally) insured - vendor or 
>> >user?
>>
>> No, a vendor has to be liable to the software product it sells.
>> Because software products are not "consumed" as normal products are,
>> there seems to be only choice between "right of use" and "insurance"
>> models.
>
>I still can't get why you use term "insurance" here. Vendor and/or seller may
>or may not provide a warranty, but "insurance" is typically associated with
>third parties, it is a separate business.

Read above. Call it "obligatory support", if you do not like the word
"insurance".

>> "Right of use" model is what we have now. Its disadvantages
>> are quite clear:
>>
>> 2. It effectively stops any significant progress by suppressing
>> competition;
>
>What I see in reality is quite rapid progress. One may clain that the progress
>might be more rapid and more comprehensive if some other rules were in effect.

So far the only "rapid progress" you have specified was the number of
users. It is irrelevant.

>> 3. It gives customers no protection from fraud;
>
>But that gives vendors protection from dishonest or simply ignorant suits.

The legal system. It has been worked so far, so I don't see why it
should collapse because of software. (A car might well do, I know it
for sure.) Anyway, if you think it would, then prove it.

>> 4. It imposes real threat to basic human rights (see DCMA)
>
>I can't see how introduction of liability of vendor will prevent or destroy
>DCMA and alike.

Because you will not need "right of software use" to get money from.
This would eliminate software piracy, and with it all those helpless,
but dangerous attempts to prevent it.

>Generally, I don't see how can your "insurance" (or liability) decrease or
>suppress "right of use". I think that you propose to add that liability to
>"right of use".

I propose that bare "right of use" licenses shall be made void. If
Microsoft writes "NO WARRANTY", then it automatically loses its right
of *any* legal protection against piracy.

The state should protect copyrights and surpress piracy only in the
areas, where there is no other way to reward contributors.

>> >Note that market never chooses immediately and/or forever. It is a big and
>> >substantially stochasic system, and moreover, it is a multi-dimensional
>> >system. Sometimes we can see some clear and relatively stable preference and
>> >we call it a choice (done by the market).
>>
>> It is about game rules, which state should impose.
>
>Do you think that those rules should make the game well-predictable?

They are. Everybody knows that the copyright protection laws work much
less efficiently and have much more nasty side effects than ones
regulating product quality.

>> >Perhaps you mean car vendors
>> >here, but why should we bother ourselves with *their* problems?
>>
>> Because they decide.
>
>They will decide about *their* problems, very well. But they can't effectively
>decide about the things that aren't in their control or even influence (so
>far).

Oh, yes, that's right. I would only enjoy and much appreciate, if EU
and USA would wake up and require, that any software running in a car
has to be written in Ada. This was the starting point of the
discussion: enough is enough, the state should intervene.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> >> >Modern science deals also with budgets, management, conferences, grants,
> >> >> >degrees and citations.
>
> the point was that scientists do not willingly anticipate all that
> bureaucratic dances, you wrote about. No more than Ethiopians do
> hunger.

You use too old information. Yes, just a century ago there was little of those
things, and vast majority of scientists despised them. Even later, before WW2,
most scientists still despised those (already growing) things. But after WW2
the situation started to change rapidly. As it was said once "the Science
engaged in strong interaction with Government" (and then with big businesses
and general bureacracy as well). In 1970th it became clear that those things
entrenched firmly in science, and that most of dislike that (marjority of)
professional scientists show for them is just a display for outsiders and,
perhaps, partly a homage to the tradition. Characteristically, that these
times the more a scientist is honest and frank - the less s/he frowns at all
those things (which is quite opposite to that was, say, 50 years ago).

> It is merely the price scientists should pay for having an
> ability to do science.

No, these days majority of professional scientists recognize all that not as
the price, but as the elements of more or less natural collaborative
environment. Althought you certainly may say (as some others do) that there
is no contradiction, as this collaborative environment is exactly the price
for having an ability to do science. And that is the key - "to do science".
If you want TO DO SCIENCE then this is The Way. When the primary goal changes
from "to know" and "to understand" to "to do" then the natural form of
cooperation changes accordingly.

> >> Where you saw individual software sellers?
> >
> >I'm quite surprised by this question - don't you know, for example, that many
> >authours of shareware products are individual sellers? Don't you know that
> >sufficiently many of those shareware products have significant customer base?
>
> Shareware products are irrelevant for the software market. They get
> probably less than 0.1% of its volume.

You are surprizing me again - you are looking at the current proportion only,
that is, at the proportion of current shareware products in the whole current
software market. But you seem not interested in how many commercial software
products or their parts started as shareware products, and not interested in
how many shareware products are used internally in software development, that
is, as tools and components used in a development of commercial products.

One real little example of that kind: several years ago one software company
bought my shareware Delphi component for use in its commecial product - some
sort of banking software. A year of so ago my friend who works for a bank
told me that she saw exactly that component in new system, which her bank
recently bought.

Other little examples - of another kind: there is a populat text editor
UltraEdit and a popular visual diff tool Araxis Merge (both for Windows) -
both shareware. I know that among regular users of these tool are software
engineers working for big and well-known vendors, so these tools actually
participate in development of quite expensive commercial products.

The point here is that you can't recognize use of shareware tools and
components in commercial products (as well as shareware products as prototypes
for a functionality) by external observation.

Although it is true that in Ada world a shareware product is unseen or almost
unseen - and I see that as symptom of weakness of this world (note carefully
- not a cause, but just a symptom).

> They are also irrelevant for software development as a phenomenon.

Phenomenon? Is accounting a phenomenon? Is scientific or engineering
computation a phenomenon? By the way, the WordNet tells me that:

phenomenon -- (any state or process known through the senses rather than by
intuition or reasoning)

Do you really think that software development is known through the senses
rather than by intuition or reasoning ?

> Because, it is clear that
> software cannot be produced by individuals,

It is not clear for me. Can an individual produce a novel? Well, a big novel,
in several volumes? Of course not - because a paper must be produced (even
for original writing) then the book must be printed in several thousand
copies, than these books must be sold to thousands people. Certainly an
individual can't do all that job. So why we still speak about the so-called
"authors" as creators of novels?

> at least at the current level of technology.

Individuals are very different in their abilities, software is very different
in its various scales, and current level of technology is a mythical thing
along with man-year (do you remember man-month?).

> So shareware gives no answer to the question, how
> humankind should organize software development.

Humankind organizing software development... it's impressive. Worldwide
Softlag Archipelago, I suppose?

> >For example, if you product faulted and the user has right to sue for that
> >then s/he will sue *you*. And then you'll spend time in court, you'll spend
> >money for lawyers, and even if you win the case, you still may be ruined. And
> >your competitor can relatively easily provide 10 doubtful cases for you -
> >just to keep you detracted from your business for some time and as a
> >consequence - ruined.
>
> Why this does not happen (or very limited) in 90% of all other areas
> of business activity, where one can sue? What is so special about
> software, which forces us to treat it otherwise?

This does not happen (or almost does not happen) in traditional areas where
stable experience is present - for example, there is commom understanding
that you can sue for a rotten food, but you can't sue if you dislike the food
because it does not correspond to your taste. Also you can sue if a little
rain destroys your shoe immediatealy after you bought it, but you can't sue
if it appeared that you bought a shoe of wrong size and it does not fit your
foot.

But there is no such traditional common understanding regarding software
products - not only because software is too young (about two decades of more
or less wide public use), but also because software is too generic notion.
Look at computer games - is it software? If yes than what can be a valid
cause for a suit? The game annoys me? The game damaged eyes of my child?
The game attracted my child too strong? Then look at text editors (not 
necessarily MS Word). Can I sue the vendor of my text editor for passing my
typo (well, very unplesant typo) into important printed document?

> I read Microsoft license. Did you?

I never read licences - they are so boring (I was told), and I have no
intention to sue software vendors.

> If yes, then tell me what kind of
> knowledge one have to possess to really understand all the secrets of
> words "NO WARRANTY"?

The WordNet tells me that:

guarantee, warrant, warranty -- (a written assurance that some product or
service will be provided or will meet certain specifications)

So "NO WARRANTY" in the context of a license for some product should mean
that there is "NO WRITTEN ASSURANCE THAT THIS PRODUCT WILL MEET CERTAIN
SPECIFICATIONS".

Quite clear, I think. In short: "You can't sue".

> >What I see in reality is quite rapid progress. One may clain that the progress
> >might be more rapid and more comprehensive if some other rules were in effect.
>
> So far the only "rapid progress" you have specified was the number of
> users. It is irrelevant.

Not just number of users, but many new categories of users and many new
sorts of applications.

> >> 3. It gives customers no protection from fraud;
> >
> >But that gives vendors protection from dishonest or simply ignorant suits.
>
> The legal system. It has been worked so far, so I don't see why it
> should collapse because of software.

You mean suits about software or use of software tools within the legal
system? Or the problem of how court, being a user of software will sue the
software vendor?

> Anyway, if you think it would, then prove it.

Quite strange "then". Are we already in court, where I must prove all my
statements? Anyway, there is nothing to prove.

> >> 4. It imposes real threat to basic human rights (see DCMA)
> >
> >I can't see how introduction of liability of vendor will prevent or destroy
> >DCMA and alike.
>
> Because you will not need "right of software use" to get money from.

So you suppose that software vendors will happily give away their source of
income and endorse the new one, which you propose, however murky and
unexplored it is? Or you think that the State will go forward and suppress
their resistance? Well, possibly there are states that indeed are ready to do
so, but those countries do not determine the software market, at least
currently, and probably they will not determine it in near future.

> >Generally, I don't see how can your "insurance" (or liability) decrease or
> >suppress "right of use". I think that you propose to add that liability to
> >"right of use".
>
> I propose that bare "right of use" licenses shall be made void. If
> Microsoft writes "NO WARRANTY", then it automatically loses its right
> of *any* legal protection against piracy.

So you indeed propose to add liabiality of vendors to the "rights of use"
for users. The worst of both worlds in a single bottle. Made in State.

> Everybody knows that the copyright protection laws work much
> less efficiently and have much more nasty side effects than ones
> regulating product quality.

Not everybody. For example, I suppose that most authors - both in literature
and in science - do not know that. I think that they will not be happy if
their copyrights were linked with their liability so that every dissatisfied
reader could sue them. And I doubt that the quality of literature and science
will advance with introduction of that liability. 



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Thu, 29 Apr 2004 07:41:12 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> It is merely the price scientists should pay for having an
>> ability to do science.
>
>No, these days majority of professional scientists recognize all that not as
>the price, but as the elements of more or less natural collaborative
>environment. Althought you certainly may say (as some others do) that there
>is no contradiction, as this collaborative environment is exactly the price
>for having an ability to do science. And that is the key - "to do science".
>If you want TO DO SCIENCE then this is The Way.

Who defined The Way?
Why is it the only way now?
Is there any better way?

>When the primary goal changes
>from "to know" and "to understand" to "to do" then the natural form of
>cooperation changes accordingly.

It seems that you are considering all aspects of human activity as
something God-given. Our science, law, market, highway striping and of
course not to forget, MS-Word are as they are. If so then there is no
basis for any discussion.

>> >> Where you saw individual software sellers?
>> >
>> >I'm quite surprised by this question - don't you know, for example, that many
>> >authours of shareware products are individual sellers? Don't you know that
>> >sufficiently many of those shareware products have significant customer base?
>>
>> Shareware products are irrelevant for the software market. They get
>> probably less than 0.1% of its volume.
>
>You are surprizing me again - you are looking at the current proportion only,
>that is, at the proportion of current shareware products in the whole current
>software market. But you seem not interested in how many commercial software
>products or their parts started as shareware products, and not interested in
>how many shareware products are used internally in software development, that
>is, as tools and components used in a development of commercial products.

I do not care how a commertial software started.

>> They are also irrelevant for software development as a phenomenon.
>
>Phenomenon? Is accounting a phenomenon? Is scientific or engineering
>computation a phenomenon? By the way, the WordNet tells me that:
>
>phenomenon -- (any state or process known through the senses rather than by
>intuition or reasoning)

They distinguish intuition from senses, which IMO difficult to do
(intuition is just an n-th sense), but otherwise it is OK.

>Do you really think that software development is known through the senses
>rather than by intuition or reasoning ?

Exactly. It is useless to reason about software development. If you do
not believe me, reread our discussion. It is a perfect example of what
happens when people start to talk about software developing in
general.

>> Because, it is clear that
>> software cannot be produced by individuals,
>
>It is not clear for me. Can an individual produce a novel? Well, a big novel,
>in several volumes? Of course not - because a paper must be produced (even
>for original writing) then the book must be printed in several thousand
>copies, than these books must be sold to thousands people.

To clarify things, I did not mean neither network administrators nor
those who are attaching labels on CDs.

>Certainly an
>individual can't do all that job. So why we still speak about the so-called
>"authors" as creators of novels?

I meant exclusively the software creators: the software architects,
project managers, programmers, testers, technical writers. That's for
software dealing with solely software. For an application,
entertainment software we need to add hundreds of other professions.

>> at least at the current level of technology.
>
>Individuals are very different in their abilities, software is very different
>in its various scales, and current level of technology is a mythical thing
>along with man-year (do you remember man-month?).

I do. Note, even that time software development was already not a
craft.

>> So shareware gives no answer to the question, how
>> humankind should organize software development.
>
>Humankind organizing software development... it's impressive. Worldwide
>Softlag Archipelago, I suppose?

Come on. There is UN, WTO and thousands of other worldwide
organizations trying to influence one or another aspect of human
activity. Most of these activities are far less important than
software development. Because, again, it will influence everything,
and in a very short period of time.

>> >For example, if you product faulted and the user has right to sue for that
>> >then s/he will sue *you*. And then you'll spend time in court, you'll spend
>> >money for lawyers, and even if you win the case, you still may be ruined. And
>> >your competitor can relatively easily provide 10 doubtful cases for you -
>> >just to keep you detracted from your business for some time and as a
>> >consequence - ruined.
>>
>> Why this does not happen (or very limited) in 90% of all other areas
>> of business activity, where one can sue? What is so special about
>> software, which forces us to treat it otherwise?
>
>This does not happen (or almost does not happen) in traditional areas where
>stable experience is present - for example, there is commom understanding
>that you can sue for a rotten food, but you can't sue if you dislike the food
>because it does not correspond to your taste. Also you can sue if a little
>rain destroys your shoe immediatealy after you bought it, but you can't sue
>if it appeared that you bought a shoe of wrong size and it does not fit your
>foot.

It is not experience, it is case law. You cannot have it before suit.
Remember the suits against tobacco industry and McDonalds.

>But there is no such traditional common understanding regarding software
>products - not only because software is too young (about two decades of more
>or less wide public use), but also because software is too generic notion.
>Look at computer games - is it software? If yes than what can be a valid
>cause for a suit? The game annoys me?

This is an unrelated case to what I wrote about. BTW, it is the most
difficult case. Anything heavily related to arts is a huge problem for
"market order". There is no good model to reward creators. The only
known way is copyright and patent law. This model works very poor. I
propose no changes here, for I have no idea how we (humans) could get
out this mess.

>The game damaged eyes of my child?
>The game attracted my child too strong?

These could be valid cases even now.

>Then look at text editors (not 
>necessarily MS Word). Can I sue the vendor of my text editor for passing my
>typo (well, very unplesant typo) into important printed document?

No. As with other products you can sue only if there is a serios
damage.

But what I actually meant, is that if there is a serious defect (such
as periodic crash, data corruption etc), the customer should have
right to get money back (during a definite period of time). There
could be other models. For example the vendor could provide a newer
version with the bug removed and an extended warranty time etc.

Again, all there measures are well known for a long period of time. Of
course no vendor there is happy with these rules. However they should
be, because in medieval Luebeck, they would be placed in a cage
exhibited to public until they die.

>> If yes, then tell me what kind of
>> knowledge one have to possess to really understand all the secrets of
>> words "NO WARRANTY"?
>
>The WordNet tells me that:
>
>guarantee, warrant, warranty -- (a written assurance that some product or
>service will be provided or will meet certain specifications)
>
>So "NO WARRANTY" in the context of a license for some product should mean
>that there is "NO WRITTEN ASSURANCE THAT THIS PRODUCT WILL MEET CERTAIN
>SPECIFICATIONS".
>
>Quite clear, I think. In short: "You can't sue".

See, you need not to be a lawyer.

>> >What I see in reality is quite rapid progress. One may clain that the progress
>> >might be more rapid and more comprehensive if some other rules were in effect.
>>
>> So far the only "rapid progress" you have specified was the number of
>> users. It is irrelevant.
>
>Not just number of users, but many new categories of users and many new
>sorts of applications.

Again this is not progress. It is a law of market which fills all
holes. This would happen anyway. For example Germany (and EU) keep
trying to stop practical use of genetics. They will fail. You cannot
prevent, though you can regulate (a bit).

And note, that legislation usually follows the market. So if a really
new application area appears, it is usually not covered by any law.
For good or bad.

>> >> 3. It gives customers no protection from fraud;
>> >
>> >But that gives vendors protection from dishonest or simply ignorant suits.
>>
>> The legal system. It has been worked so far, so I don't see why it
>> should collapse because of software.
>
>You mean suits about software or use of software tools within the legal
>system? Or the problem of how court, being a user of software will sue the
>software vendor?

The first.

>> Anyway, if you think it would, then prove it.
>
>Quite strange "then". Are we already in court, where I must prove all my
>statements? Anyway, there is nothing to prove.

No, your point seems to be: "there is something very specific in
software products which expulses them from juridical system." This is
a strong statement, so a proof, please.

>> >> 4. It imposes real threat to basic human rights (see DCMA)
>> >
>> >I can't see how introduction of liability of vendor will prevent or destroy
>> >DCMA and alike.
>>
>> Because you will not need "right of software use" to get money from.
>
>So you suppose that software vendors will happily give away their source

I do not care about their happiness! It is not my business, there are
psychoanalysts, gurus, astrologers at their service.

>of
>income and endorse the new one, which you propose, however murky and
>unexplored it is?

It is explored.

>Or you think that the State will go forward and suppress
>their resistance?

Yes. It goes after laughable removal IE from Windows. It goes after
reverse engineering etc. They should find a better occupation for our
taxes!

>Well, possibly there are states that indeed are ready to do
>so, but those countries do not determine the software market, at least
>currently, and probably they will not determine it in near future.

Nonsense.

>> >Generally, I don't see how can your "insurance" (or liability) decrease or
>> >suppress "right of use". I think that you propose to add that liability to
>> >"right of use".
>>
>> I propose that bare "right of use" licenses shall be made void. If
>> Microsoft writes "NO WARRANTY", then it automatically loses its right
>> of *any* legal protection against piracy.
>
>So you indeed propose to add liabiality of vendors to the "rights of use"
>for users. The worst of both worlds in a single bottle. Made in State.

As the first step, for those who are so obsessed with copyright
issues. Later when market will be freed from monopolies it will clean
itself from the "use right of a sequence of 0s and 1s" nonsense.

>> Everybody knows that the copyright protection laws work much
>> less efficiently and have much more nasty side effects than ones
>> regulating product quality.
>
>Not everybody. For example, I suppose that most authors - both in literature
>and in science - do not know that.

I answered that. Software conrolling a car is not literature neither
it is a science, which BTW practically knows no copyright.

>I think that they will not be happy if
>their copyrights were linked with their liability so that every dissatisfied
>reader could sue them. And I doubt that the quality of literature and science
>will advance with introduction of that liability. 

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

: Anything heavily related to arts is a huge problem for
: "market order".

(Market order doesn't have problems, it is a theory.
There are only those trying to compensate for some things supposed to
be market effects.  I guess you meant this?)

: There is no good model to reward creators. The only
: known way is copyright and patent law.

It has little to do with law I think, except for plagiarism.
Law is not a known way for painters etc., because the market
works in a special way, and it ever has.
Music market is without ways of rewarding artists?
Writers cannot in general publish anything without being rewarded
in some countries.
What else. Software artists? How do the various creators
of software artefacts get their money? For patented software?
Does Joe Programmer own the copyright of his produce?

: I answered that. Software conrolling a car is not literature neither
: it is a science, which BTW practically knows no copyright.

Huh? Science practically knows no copyright?
You cannot be referring to anything that has to do with
scientists.


Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Thu, 29 Apr 2004 15:49:18 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>: Anything heavily related to arts is a huge problem for
>: "market order".
>
>(Market order doesn't have problems, it is a theory.
>There are only those trying to compensate for some things supposed to
>be market effects.  I guess you meant this?)
>
>: There is no good model to reward creators. The only
>: known way is copyright and patent law.
>
>It has little to do with law I think, except for plagiarism.
>Law is not a known way for painters etc., because the market
>works in a special way, and it ever has.

Technically painters sell their signatures. I remember a CNN reportage
about a picture, which price sky-rocketed from $100 to 1 mio, when
somebody suggested that it was painted by a renown painter. Nobody
seemed to care whether the painting was good.

Forging signatures is punished by law.

>Music market is without ways of rewarding artists?

Should it be a market? What sells a violinist of an orchestra?

>Writers cannot in general publish anything without being rewarded
>in some countries.

Is quality of modern literature good, as compared to 50, 100, 150
years back? Can someone yearn his bread by writting novels? (I do not
count exceptions like "Harry Potter").

>What else. Software artists? How do the various creators
>of software artefacts get their money?
>For patented software?
>Does Joe Programmer own the copyright of his produce?

No, everything he does, belongs to his employer. 

>: I answered that. Software conrolling a car is not literature neither
>: it is a science, which BTW practically knows no copyright.
>
>Huh? Science practically knows no copyright?
>You cannot be referring to anything that has to do with
>scientists.

Who owns copyright on Newton laws?

Well, there are ongoing attempts to patent genomes, though I do not
believe that such things would stand in court.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Thu, 29 Apr 2004 15:49:18 +0000 (UTC), Georg Bauhaus
: <sb463ba@l1-hrz.uni-duisburg.de> wrote:

: Technically painters sell their signatures.

Some painters sell their signatures. Some pictures are sold
signed by artists no longer alive. Many pictures are sold
by painters you and I don't know.


:>Music market is without ways of rewarding artists?
: 
: Should it be a market? What sells a violinist of an orchestra?

Different question.  Another different question is, should we
have just one solution, that is market or not a market?

 
:>Writers cannot in general publish anything without being rewarded
:>in some countries.
: 
: Is quality of modern literature good,

Whatever it is, this doesn't change the rewarding facts.

: (I do not count exceptions ...)

Hm. Is this about scientifically oriented approaches to reality?

 
:>Does Joe Programmer own the copyright of his produce?
: 
: No, everything he does, belongs to his employer. 

Right, though not necessarily.


: Who owns copyright on Newton laws?

Who owns the copyright on the Feynman Lectures?

 
Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Fri, 30 Apr 2004 15:29:19 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Thu, 29 Apr 2004 15:49:18 +0000 (UTC), Georg Bauhaus
>: <sb463ba@l1-hrz.uni-duisburg.de> wrote:
>
>:>Music market is without ways of rewarding artists?
>: 
>: Should it be a market? What sells a violinist of an orchestra?
>
>Different question.  Another different question is, should we
>have just one solution, that is market or not a market?

Of course, there could be a "market" of solutions. (:-)) The point was
that the current system of rewarding works unsatisfactory.
 
>:>Writers cannot in general publish anything without being rewarded
>:>in some countries.
>: 
>: Is quality of modern literature good,
>
>Whatever it is, this doesn't change the rewarding facts.

But what is the goal of rewarding?

>: (I do not count exceptions ...)
>
>Hm. Is this about scientifically oriented approaches to reality?

Yes, it is called mathematical statistics! (:-))
 
>: Who owns copyright on Newton laws?
>
>Who owns the copyright on the Feynman Lectures?

Lectures and the ideas there are different thing. Gave Feynman his
course of lectures for money? I think if he did then to only a minor
extent. Even if I am wrong, then well, how the copyright on his
lectures can reward a dead man?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> It is merely the price scientists should pay for having an
> >> ability to do science.
> >
> >No, these days majority of professional scientists recognize all that not as
> >the price, but as the elements of more or less natural collaborative
> >environment. Althought you certainly may say (as some others do) that there
> >is no contradiction, as this collaborative environment is exactly the price
> >for having an ability to do science. And that is the key - "to do science".
> >If you want TO DO SCIENCE then this is The Way.
>
> Who defined The Way?
> Why is it the only way now?
> Is there any better way?

You seem to be very accustomed to language exercises - "please, ask several
questions concerning the topic of the phrase". I can't imagine another cause
for this your triplet of questions.

> >When the primary goal changes
> >from "to know" and "to understand" to "to do" then the natural form of
> >cooperation changes accordingly.
>
> It seems that you are considering all aspects of human activity as
> something God-given.

Well, I indeed consider all aspects of (collective or statistically visible)
human activity as heavily influenced and largely determined by the history
and current circumstances - natural, technological and social.

Whether that can or should be called "God-given" probably depend on particular
flavor of faith and on particular language tradition.

> Our science, law, market, highway striping and of
> course not to forget, MS-Word are as they are.

But they indeed are as they are, at least we see them that way.

But note that there are always alternatives - you may choose astrology instead
of astronomy, you may choose a criminal way instead of law-abiding way, you
may avoid highways by staying home or travelling on foot or by helicopter,
and of course not to forget you may choose StarOffice or Lotus Notes instead
of MS Word.

Actually there are many substantially different variants of almost any kind
of things at your disposal. You may choose a particular law by choosing the
country of residence - for example, you may lawfully use drugs or have several
wives around you. And even within a given flavor of the thing we often have
sub-variants - for example, for MS Word you can really choose between 97,
2000, 2002 and 2003 depending on your priorities and circumstances.

So what is really "given" is a diversity. Certainly there are mainstreams and
marginals at any given moment, but that should not distract us from sensing
diversity.

> If so then there is no basis for any discussion.

I don't know whether there is a basis for discussion, and if it is then what
is it.

But I'd like to note here that traditionally (until relatively recently)
science was about acquiring stable knowledge and understanding, and not about
redoing the world.

Returning to the word "God-given", I'd like to note that many of great
scientists (Newton, for an excellent example, and there are many others)
were very faithful in their religion, and for all signs they were true
believers in God, in Creator. And that did not contradict their scientific
investigations in any way. On the contrary, they seemed to think that it is
a God's will for humans to pursue understanding of God's laws and God's
workings; perhaps some of them also believe that this way they become somehow
nearer to God.

> I do not care how a commertial software started.

Well, it is your choice, and perhaps it is a good choice for professional
employee. But I do care for that - because it is a valuable part of software
product's lifecycle.

> >> Because, it is clear that
> >> software cannot be produced by individuals,
> >
> >It is not clear for me. Can an individual produce a novel? Well, a big novel,
> >in several volumes? Of course not - because a paper must be produced (even
> >for original writing) then the book must be printed in several thousand
> >copies, than these books must be sold to thousands people.
>
> To clarify things, I did not mean neither network administrators nor
> those who are attaching labels on CDs.

How about various editors, proofreaders, sometimes illustrators, 
"alpha-testers" - friends to whom the author read parts of unfinished book ?
I think that without those people quality of the book would suffer very much -
so much that it might provoke you to propose author's liability for that.

> There is UN, WTO and thousands of other worldwide
> organizations trying to influence one or another aspect of human
> activity.  Most of these activities are far less important than
> software development. Because, again, it will influence everything,
> and in a very short period of time.

But there are international organizations and national organization in various
countries (some of then actually are international - like ACM and IEEE)
dealing with software as well. What else you want? Are you participating in
at least one of those organizations?

> But what I actually meant, is that if there is a serious defect (such
> as periodic crash, data corruption etc),

But if that periodic crash is caused by irregular malfunction of some hardware
(preferably the motherboard) or underlying OS or combination of both? How
court will investigate such cases? If those crashes are caused by unique
ability of the user to type too fast? If that data corruption happens after
power failures only? Or after the user ignored an error/warning message from
OS?

Being an appointed investigator and arbiter for such murky cases during 6
years (although with now ancient hardware and software) I can easily imagine
a whole gallery of doubtful and at the same time realistic cases.

But the real problem and real danger of that liability is that the vendor,
fearing suits, will reduce risk. There are many situations where programmer
can decide whether to take a risk - in interests of almost all users - or not
to do that because in a case of bad luck the user will suffer, however
probably slightly, but nevertheless s/he will be annoyed and perhaps will sue.
And even there will be no real unhappy users, there may be "research firm"
that lurkes around for such holes and probably will find it - and then provoke
a suit.

> >So "NO WARRANTY" in the context of a license for some product should mean
> >that there is "NO WRITTEN ASSURANCE THAT THIS PRODUCT WILL MEET CERTAIN
> >SPECIFICATIONS".
> >
> >Quite clear, I think. In short: "You can't sue".
>
> See, you need not to be a lawyer.

Yes, those *current* licenses were designed mostly for common people, not for
lawyers. But if liability will be introduced then those licences will be fully
rewritten and will become documents for lawyers only.

> >> >What I see in reality is quite rapid progress. One may clain that the progress
> >> >might be more rapid and more comprehensive if some other rules were in effect.
> >>
> >> So far the only "rapid progress" you have specified was the number of
> >> users. It is irrelevant.
> >
> >Not just number of users, but many new categories of users and many new
> >sorts of applications.
>
> Again this is not progress. It is a law of market which fills all
> holes.

But who create those holes?

> your point seems to be: "there is something very specific in
> software products which expulses them from juridical system." This is
> a strong statement, so a proof, please.

You said that many times yourself - that software is very specific - in its
omnipresence (in very near future), in its unversality, and even in its
potential danger. And I do not dispute that, generally.

What expulses it from juridical system? Exactly some of those features -
mostly its universality, but also its omnipresence: software as a general
notion is bigger and more powerful (however vague) than any legal system.

I am not generally against vendor's liability for particular software
products. I am against liability for software. Liability should be based
on intended use of the product and it should not relate to popular notions
regarding the product's construction. And it certainly should not be based
on those popular notions. In other words, liability should not mention
software at all - at least before the legal definition of the term "software"
will be approved (and when such a definition will be available it will be
possible, and probably easy, to move the product outside of this definition).




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Fri, 30 Apr 2004 05:47:13 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>But I'd like to note here that traditionally (until relatively recently)
>science was about acquiring stable knowledge and understanding, and not about
>redoing the world.

That's not science yet. A true science begins when it gives birth to
engineering.

>> >> Because, it is clear that
>> >> software cannot be produced by individuals,
>> >
>> >It is not clear for me. Can an individual produce a novel? Well, a big novel,
>> >in several volumes? Of course not - because a paper must be produced (even
>> >for original writing) then the book must be printed in several thousand
>> >copies, than these books must be sold to thousands people.
>>
>> To clarify things, I did not mean neither network administrators nor
>> those who are attaching labels on CDs.
>
>How about various editors, proofreaders, sometimes illustrators, 
>"alpha-testers" - friends to whom the author read parts of unfinished book ?
>I think that without those people quality of the book would suffer very much -
>so much that it might provoke you to propose author's liability for that.

No, the book you refer is just a carrier of something more valuable
than cellulose. So far there was no need to distinguish them because
to reproduce the artifact was difficult, if possible. This way one
could sell books, for example. With the software, this mechanics does
not work anymore. As a result we have piracy, born by this insufficent
model. The piracy is not God-given, as you are trying to convince me.
It is just a result.

>> There is UN, WTO and thousands of other worldwide
>> organizations trying to influence one or another aspect of human
>> activity.  Most of these activities are far less important than
>> software development. Because, again, it will influence everything,
>> and in a very short period of time.
>
>But there are international organizations and national organization in various
>countries (some of then actually are international - like ACM and IEEE)
>dealing with software as well. What else you want? Are you participating in
>at least one of those organizations?

Can you remember the last time CNN mentioned IEEE in its news block?
UN-bureaucrats are aired each day.

>> But what I actually meant, is that if there is a serious defect (such
>> as periodic crash, data corruption etc),
>
>But if that periodic crash is caused by irregular malfunction of some hardware
>(preferably the motherboard) or underlying OS or combination of both? How
>court will investigate such cases?

Vendors are liable. They can sue other vendor.

>But the real problem and real danger of that liability is that the vendor,
>fearing suits, will reduce risk. There are many situations where programmer
>can decide whether to take a risk - in interests of almost all users - or not
>to do that because in a case of bad luck the user will suffer, however
>probably slightly, but nevertheless s/he will be annoyed and perhaps will sue.

I do not want MS taking risk by developing a new branch of Windows
each year.

>And even there will be no real unhappy users, there may be "research firm"
>that lurkes around for such holes and probably will find it - and then provoke
>a suit.

It would be very useful. BTW I would make software cracking legal, as
long as it does not damage something. It could much help in improving
software safety and reliability.

>> >> >What I see in reality is quite rapid progress. One may clain that the progress
>> >> >might be more rapid and more comprehensive if some other rules were in effect.
>> >>
>> >> So far the only "rapid progress" you have specified was the number of
>> >> users. It is irrelevant.
>> >
>> >Not just number of users, but many new categories of users and many new
>> >sorts of applications.
>>
>> Again this is not progress. It is a law of market which fills all
>> holes.
>
>But who create those holes?

Life

>> your point seems to be: "there is something very specific in
>> software products which expulses them from juridical system." This is
>> a strong statement, so a proof, please.
>
>You said that many times yourself - that software is very specific - in its
>omnipresence (in very near future), in its unversality, and even in its
>potential danger. And I do not dispute that, generally.

OK

>What expulses it from juridical system? Exactly some of those features -
>mostly its universality,

I do not see why. There are lots of other universal things being
regulated.

>but also its omnipresence: software as a general
>notion is bigger and more powerful (however vague) than any legal system.

Human beings are even bigger and powerful. Neither software nor legal
system can even emerge without humans. Yet criminal law exists.

>I am not generally against vendor's liability for particular software
>products.

Excellent

>I am against liability for software. Liability should be based
>on intended use of the product

That's my point

>and it should not relate to popular notions
>regarding the product's construction.

Depending on application area, the state has right to require definite
procedures to be applied for software construction. This is a common
practice. There is no reason to reinvent wheel here.

>And it certainly should not be based
>on those popular notions.

Those are not notions, but knowledge. It is *known* that bridges shall
not be built without analysis of statics etc. Again, there is no
reason, why it should be otherwise in case of software.

If you say that software cannot be designed in a safe way, then it is
another story. In such cases it has to be forbidden in this area.
Remeber, we are talking about special application areas threatening
human life. It is also a common practice. For instance, any
dynamometer shall have an [electro]mechanical emergency stop
capability.

>In other words, liability should not mention
>software at all - at least before the legal definition of the term "software"
>will be approved (and when such a definition will be available it will be
>possible, and probably easy, to move the product outside of this definition).

This is absolutely wrong. If software determines functionality of
product to say 90%, how one can avoid mentioning it?

Consider a bed-side monitoring system for resuscitation departments.
Should a patient die because of software crash, who would be liable?
Let me be a vendor. I would make a box and let it be certified for
medical use. Then I would contract a third party company of hackers to
write some funky Web-based application for it. Next I would sell the
box and a CD with it. Now, I suppose, the market should select
patients choosing hospitals, that do not buy my system. Right?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Fri, 30 Apr 2004 05:47:13 +0400 (MSD), "Alexander E. Kopilovich"
: <aek@VB1162.spb.edu> wrote:
: 
:>Dmitry A. Kazakov wrote:
:>
:>But I'd like to note here that traditionally (until relatively recently)
:>science was about acquiring stable knowledge and understanding, and not about
:>redoing the world.
: 
: That's not science yet. A true science begins when it gives birth to
: engineering.

Work in the small, i.e. not oriented towards "the world", is complex
and full of imponderabilities.  Science cannot even say exactly
how a windshield is affecting a car's route. Science, engineering,
all we can say is that it sometimes works!

Humans give birth, not science and the wombs of ideas (including
engineering ideas) are certainly subject to factors other than
scientific ones, if known factors at all.

And please no engineered history. Please let me die before this
is attempted again.
And I don't take it for granted that medicine will be more successful
as soon as it is praticed by body engineers.


Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Fri, 30 Apr 2004 15:44:27 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Fri, 30 Apr 2004 05:47:13 +0400 (MSD), "Alexander E. Kopilovich"
>: <aek@VB1162.spb.edu> wrote:
>: 
>:>Dmitry A. Kazakov wrote:
>:>
>:>But I'd like to note here that traditionally (until relatively recently)
>:>science was about acquiring stable knowledge and understanding, and not about
>:>redoing the world.
>: 
>: That's not science yet. A true science begins when it gives birth to
>: engineering.
>
>Work in the small, i.e. not oriented towards "the world", is complex
>and full of imponderabilities.  Science cannot even say exactly
>how a windshield is affecting a car's route. Science, engineering,
>all we can say is that it sometimes works!

But we can build cars, so physics and chemistry are indeed sciences.

>Humans give birth, not science and the wombs of ideas (including
>engineering ideas) are certainly subject to factors other than
>scientific ones, if known factors at all.
>
>And please no engineered history. Please let me die before this
>is attempted again.

The result of that experiment shown that Marxism is not a science. But
if you think that this will stop humans from trying to engineer the
society, then you are wrong. Be prepared to worse things.

>And I don't take it for granted that medicine will be more successful
>as soon as it is praticed by body engineers.

Are body shamans any better?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
: But we can build cars, so physics and chemistry are indeed sciences.

But some people feel better after visiting an astrologer, so
astrology is indeed science?

 
: The result of that experiment shown that Marxism is not a science.

If existing societies claiming to be "Marxist" show that socalled
Marxism is science, what definition of science is that?
Even with simple formal methods you face the HALTing problem, among
other obstacles. Hybris aside.
Formal science only deals with formal abstractions.

Are you saying that a "successful" building of a political framework
for a society is an indication of "science" in political reasoning?

David Gries has written "The Science of Programming". The book
is not about everything that a scientist might consider
important in a scientific study of programming, is it?
So given software engineering, which you seem to think is an
indication of software science, what exactly is the subject
of that science?

:>And I don't take it for granted that medicine will be more successful
:>as soon as it is praticed by body engineers.
: 
: Are body shamans any better?

AFAICT, neither of them restrict the background of their techniques
to nothing but scientific engineering, or to nothing but "spirituality".
What's more, a western doctor may treat a patient more, the same,
or less successful than a shaman, in any single case. They might even
work together.


-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Mon, 3 May 2004 11:46:27 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>: But we can build cars, so physics and chemistry are indeed sciences.
>
>But some people feel better after visiting an astrologer, so
>astrology is indeed science?

No because, there is no astrological engineering. On the contrary, it
is well *known* how to build an average car. 

>: The result of that experiment shown that Marxism is not a science.
>
>If existing societies claiming to be "Marxist" show that socalled
>Marxism is science, what definition of science is that?

a Marxist's one (:-))

>Even with simple formal methods you face the HALTing problem, among
>other obstacles. Hybris aside.
>Formal science only deals with formal abstractions.

You cannot prove that a theory is right, but you can disprove it, if
it allows that. "Good" sciences allow such experiments, which in turn
leads to engineering. "Bad" sciences are not verifiable, those are not
sciences at all, but merely religions.

>Are you saying that a "successful" building of a political framework
>for a society is an indication of "science" in political reasoning?

Yes, if "political science" tells how to do that. Then, well, we could
take say, Iraq, and engineer it to be a decent country. So far we
cannot.

>David Gries has written "The Science of Programming".

An excellent book, BTW.

>The book
>is not about everything that a scientist might consider
>important in a scientific study of programming, is it?

Yes, but things Gries mention are fundamental for would-be computer
science.

>So given software engineering, which you seem to think is an
>indication of software science, what exactly is the subject
>of that science?

It should be. The problem is that both this "science" and this
"engineering" are in disarray. Programmers despise CS, academics laugh
at programmers while business ignores both.

>:>And I don't take it for granted that medicine will be more successful
>:>as soon as it is praticed by body engineers.
>: 
>: Are body shamans any better?
>
>AFAICT, neither of them restrict the background of their techniques
>to nothing but scientific engineering, or to nothing but "spirituality".
>What's more, a western doctor may treat a patient more, the same,
>or less successful than a shaman, in any single case. They might even
>work together.

Medicine is far from being a "good" science. Yet, it is lightyears
away from shamanism. Instead of speculating on single cases we should
consider objective statistics of national health care in *any* western
country. Note the word "any", which explains why medicine becomes a
science.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov write:

> >But I'd like to note here that traditionally (until relatively recently)
> >science was about acquiring stable knowledge and understanding, and not about
> >redoing the world.
>
> That's not science yet. A true science begins when it gives birth to
> engineering.

You should not write "true science" there, you should write "my science"
instead. And then you could add "tomorrow belongs to me".

As for traditional science, it was entirely separate activity from
engineering. They often went in parallel, and very often helped each other
in various ways. For example, science helped engineering with basic laws
of physics, and engineering helped science with various tools and with
artificial objects that were suitable for scientific observations.

> The piracy is not God-given, as you are trying to convince me.
> It is just a result.

If you depend on use of religion-related terminology then you'd better to know
more about relations between God's actions, causes and results in classical
monotheistic theologies.

> > there are international organizations and national organization in various
> >countries (some of then actually are international - like ACM and IEEE)
> >dealing with software as well. What else you want? Are you participating in
> >at least one of those organizations?
>
> Can you remember the last time CNN mentioned IEEE in its news block?
> UN-bureaucrats are aired each day.

So your understanding of democracy implies that any substantial influence,
even in complex scientific/technical matters, can be performed only by bodies,
of which general public is well aware through mass-media?

> >> But what I actually meant, is that if there is a serious defect (such
> >> as periodic crash, data corruption etc),
> >
> >But if that periodic crash is caused by irregular malfunction of some hardware
> >(preferably the motherboard) or underlying OS or combination of both? How
> >court will investigate such cases?
>
> Vendors are liable. They can sue other vendor.

Lawyers Chorus: Very good, one more suit.

> >but also its omnipresence: software as a general
> >notion is bigger and more powerful (however vague) than any legal system.
>
> Human beings are even bigger and powerful.

No. Software accumulates human knowledge, decision abilities and experience
- over very different professionals and over time. Generally, it can be much
easily targetted on a particular problem than a human collective.

> Neither software nor legal
> system can even emerge without humans. Yet criminal law exists.

Airplanes could not emerge without humans, but they are much faster than
humans, and they can fly. Trains also could not emerge without humans, and
they also are much faster than humans, but trains can't fly and airplanes
are much faster than trains.

> >I am against liability for software. Liability should be based
> >on intended use of the product
>
> That's my point

I'm not sure of that - because I think that only a small minority of intended
uses deserve liability for vendors.

> Depending on application area, the state has right to require definite
> procedures to be applied for software construction. This is a common
> practice. There is no reason to reinvent wheel here.

That may be true for some application domains, but only for small minority of
them.

> >And it certainly should not be based
> >on those popular notions.
>
> Those are not notions, but knowledge. It is *known* that bridges shall
> not be built without analysis of statics etc. Again, there is no
> reason, why it should be otherwise in case of software.

It is quite obvious (and was said many times by various people) that humans
have built bridges for many centures, but they have built software for several
decades only. Do you perceive significant difference between many centures
and several decades of experience?

>If you say that software cannot be designed in a safe way, then it is
>another story. In such cases it has to be forbidden in this area.
>Remeber, we are talking about special application areas threatening
>human life.

It is new turn for me - I did not suppose that we are talking specifically
about those special application areas. Why so we *both* mentioned MS Word?
Is its application area threatening human life?

Actually there are plenty application domains where vendor's liability is
justfified - not only those that can directly threaten human life; but it is
still a small minority of already established set of specific (vs. broad)
application domains.

> >In other words, liability should not mention
> >software at all - at least before the legal definition of the term "software"
> >will be approved (and when such a definition will be available it will be
> >possible, and probably easy, to move the product outside of this definition).
>
> This is absolutely wrong. If software determines functionality of
> product to say 90%, how one can avoid mentioning it?
>
> Consider a bed-side monitoring system for resuscitation departments.
> Should a patient die because of software crash, who would be liable?

I can't see a difference (for a user, that is either the patient or hospital)
between a software crash or hardware malfunction in that system.

> Let me be a vendor. I would make a box and let it be certified for
> medical use. Then I would contract a third party company of hackers to
> write some funky Web-based application for it. Next I would sell the
> box and a CD with it. Now, I suppose, the market should select
> patients choosing hospitals, that do not buy my system. Right?

My answer for that is very simple: hospitals and physicians must understand
their tools. And I hope they do, as a rule. Probably they will not buy a
lancet that is boxed with radio-set for use them simultaneously. In that
your example I'd sue the hospital, which uses that system - for incompetency
with the tools it employs.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Sat,  1 May 2004 06:38:08 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov write:
>
>> >But I'd like to note here that traditionally (until relatively recently)
>> >science was about acquiring stable knowledge and understanding, and not about
>> >redoing the world.
>>
>> That's not science yet. A true science begins when it gives birth to
>> engineering.
>
>You should not write "true science" there, you should write "my science"
>instead. And then you could add "tomorrow belongs to me".
>
>As for traditional science, it was entirely separate activity from
>engineering.

Like numerology

>They often went in parallel, and very often helped each other
>in various ways. For example, science helped engineering with basic laws
>of physics,

Engineering is a product of science. Without science it is called
craftsmanship.

>and engineering helped science with various tools and with
>artificial objects that were suitable for scientific observations.

>> > there are international organizations and national organization in various
>> >countries (some of then actually are international - like ACM and IEEE)
>> >dealing with software as well. What else you want? Are you participating in
>> >at least one of those organizations?
>>
>> Can you remember the last time CNN mentioned IEEE in its news block?
>> UN-bureaucrats are aired each day.
>
>So your understanding of democracy implies that any substantial influence,
>even in complex scientific/technical matters, can be performed only by bodies,
>of which general public is well aware through mass-media?

Absolutely. To be prepared for concessions (science is an expensive
thing) public has to be aware of what's going on.

>> Neither software nor legal
>> system can even emerge without humans. Yet criminal law exists.
>
>Airplanes could not emerge without humans, but they are much faster than
>humans, and they can fly.

Thus according to your logic they should be excluded from legal
system. [Presumably a judge could not catch an object flying at great
speed]

>> >I am against liability for software. Liability should be based
>> >on intended use of the product
>>
>> That's my point
>
>I'm not sure of that - because I think that only a small minority of intended
>uses deserve liability for vendors.

Deserve? First vendors should deserve a right to have users!

>> Depending on application area, the state has right to require definite
>> procedures to be applied for software construction. This is a common
>> practice. There is no reason to reinvent wheel here.
>
>That may be true for some application domains, but only for small minority of
>them.

This would be vast majority, and very soon.

>> >And it certainly should not be based
>> >on those popular notions.
>>
>> Those are not notions, but knowledge. It is *known* that bridges shall
>> not be built without analysis of statics etc. Again, there is no
>> reason, why it should be otherwise in case of software.
>
>It is quite obvious (and was said many times by various people) that humans
>have built bridges for many centures,

Yes, and in ancient Rome, the engineer should stand under his bridge
during first tests.

>but they have built software for several
>decades only. Do you perceive significant difference between many centures
>and several decades of experience?

I see no difference. Do not build bridges if you cannot. If you
believe that you can, be liable for the result. If you know that you
cannot, but pretend that you can, then your place is in jail.

>>If you say that software cannot be designed in a safe way, then it is
>>another story. In such cases it has to be forbidden in this area.
>>Remeber, we are talking about special application areas threatening
>>human life.
>
>It is new turn for me - I did not suppose that we are talking specifically
>about those special application areas. Why so we *both* mentioned MS Word?
>Is its application area threatening human life?

No. I was talked about the cases where procedures has to be specified
by law. In case of MS Word it would be enough to require a minimal
level of liability, limited by the price of the product (in normal
cases.)

>> >In other words, liability should not mention
>> >software at all - at least before the legal definition of the term "software"
>> >will be approved (and when such a definition will be available it will be
>> >possible, and probably easy, to move the product outside of this definition).
>>
>> This is absolutely wrong. If software determines functionality of
>> product to say 90%, how one can avoid mentioning it?
>>
>> Consider a bed-side monitoring system for resuscitation departments.
>> Should a patient die because of software crash, who would be liable?
>
>I can't see a difference (for a user, that is either the patient or hospital)
>between a software crash or hardware malfunction in that system.

The difference is that next time, other firm would pay more attention
to quality. As you probably know, the most important goal of
punishment is prevention of crime.

>> Let me be a vendor. I would make a box and let it be certified for
>> medical use. Then I would contract a third party company of hackers to
>> write some funky Web-based application for it. Next I would sell the
>> box and a CD with it. Now, I suppose, the market should select
>> patients choosing hospitals, that do not buy my system. Right?
>
>My answer for that is very simple: hospitals and physicians must understand
>their tools.

Nonsense. They are incompetent in software and need not to be
competent. It is like to require them to be electricians and check
insulation of all devices they use and be responsible if they fail to.

>And I hope they do, as a rule. Probably they will not buy a
>lancet that is boxed with radio-set for use them simultaneously.

They will, because it is cheaper.

>In that
>your example I'd sue the hospital, which uses that system - for incompetency
>with the tools it employs.

The judge will answer you that according to your theory, it is solely
you who was incompetent in choosing a hospital employing tools
developed by incompetent vendors.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Sat,  1 May 2004 06:38:08 +0400 (MSD), "Alexander E. Kopilovich"
: <aek@VB1162.spb.edu> wrote:

: Engineering is a product of science. Without science it is called
: craftsmanship.
 
You are free to make this distinction, and I am free to call it stuck-up.


:>So your understanding of democracy implies that any substantial influence,
:>even in complex scientific/technical matters, can be performed only by bodies,
:>of which general public is well aware through mass-media?
: 
: Absolutely. To be prepared for concessions (science is an expensive
: thing) public has to be aware of what's going on.

That's funny. There are some very illuminating books about
who is helping whom to get this or that on the way, including
scientific endeavors that might never be accepted by the general
public.

What makes you think that a lobby cannot be supportive in science,
only everywhere else?

 
: The difference is that next time, other firm would pay more attention
: to quality.

Good joke ;-)
In general, a big company will be offered new contracts no matter
how high the percentage of failed projects is, so malfunctioning
software is just one of the factors that might influence future
negotiations and choices of contractors.

:>My answer for that is very simple: hospitals and physicians must understand
:>their tools.
:
:> Probably they will not buy a
:>lancet that is boxed with radio-set for use them simultaneously.
: 
: They will, because it is cheaper.

Not my experience.



-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Mon, 3 May 2004 12:06:40 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Sat,  1 May 2004 06:38:08 +0400 (MSD), "Alexander E. Kopilovich"
>: <aek@VB1162.spb.edu> wrote:
>
>: Engineering is a product of science. Without science it is called
>: craftsmanship.
> 
>You are free to make this distinction, and I am free to call it stuck-up.

I do not want to undermine engineering.

>:>So your understanding of democracy implies that any substantial influence,
>:>even in complex scientific/technical matters, can be performed only by bodies,
>:>of which general public is well aware through mass-media?
>: 
>: Absolutely. To be prepared for concessions (science is an expensive
>: thing) public has to be aware of what's going on.
>
>That's funny. There are some very illuminating books about
>who is helping whom to get this or that on the way, including
>scientific endeavors that might never be accepted by the general
>public.

Ah, here we return to the starting point. Something is badly wrong
with how we are dealing with creators.

>What makes you think that a lobby cannot be supportive in science,
>only everywhere else?

It can, but why should everything depend on lobbying? More generally,
why everytime and everywhere "technical issues are irrelewant". Even
more general: are we damned or just stupid?

>: The difference is that next time, other firm would pay more attention
>: to quality.
>
>Good joke ;-)
>In general, a big company will be offered new contracts no matter
>how high the percentage of failed projects is, so malfunctioning
>software is just one of the factors that might influence future
>negotiations and choices of contractors.

Right, if solely money involved. This is why I said that the state
should intervene and tune the game rules.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Mon, 3 May 2004 12:06:40 +0000 (UTC), Georg Bauhaus
: <sb463ba@l1-hrz.uni-duisburg.de> wrote:

:>: Engineering is a product of science. Without science it is called
:>: craftsmanship.
:> 
:>You are free to make this distinction, and I am free to call it stuck-up.
: 
: I do not want to undermine engineering.

I do not want to undermine craftsmanship. Sometimes engineers work
as craftspeople and vice versa. Sometimes craftspeople have domain
knowledge superior to engineers', and vice versa. Sometimes both
know much/little about related sciences that might even be unkown
to the scientists.


: Ah, here we return to the starting point. Something is badly wrong
: with how we are dealing with creators.

It works for many. You have to explain to them and to us what
exactly is wrong.

 
: It can, but why should everything depend on lobbying?

It shouldn't. Can you name an alternative?


:  This is why I said that the state
: should intervene and tune the game rules.

But those who intervene to find a solution to the problem
of tuning the game rules play another game doing so, which has its
own set of rules, so we'd need another crowd tuning the rules
of that game, which needs to be controlled by a third crowd tuning
the rules of the second game, and...

(As a matter of fact, tuning the rules does take place, but
consider how it takes place.)

If you cannot name an absolute point of reference, this leads to
a classical problem.  Justifying politics is lost in recursion
because there are no scientific axioms to stop it.
 Enter Ideology, enter Belief, enter Knot-Cutting-Sword.


-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Mon, 3 May 2004 15:10:47 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Mon, 3 May 2004 12:06:40 +0000 (UTC), Georg Bauhaus
>: <sb463ba@l1-hrz.uni-duisburg.de> wrote:
>
>:>: Engineering is a product of science. Without science it is called
>:>: craftsmanship.
>:> 
>:>You are free to make this distinction, and I am free to call it stuck-up.
>: 
>: I do not want to undermine engineering.
>
>I do not want to undermine craftsmanship. Sometimes engineers work
>as craftspeople and vice versa. Sometimes craftspeople have domain
>knowledge superior to engineers', and vice versa. Sometimes both
>know much/little about related sciences that might even be unkown
>to the scientists.

No engineer cannot know more than a scientist, because any engineer is
a scientist when he/she *knows* something.

Craftspeople may only have practical experience, be trained etc, but
not know. When alchemists started to know, they became chemists.

>: Ah, here we return to the starting point. Something is badly wrong
>: with how we are dealing with creators.
>
>It works for many. You have to explain to them and to us what
>exactly is wrong.

Science and arts are stagnating and highly unpopular. The first jet
aircraft was built about 1945, less than in 20 years we were in space.
In ten years we were on the Moon.
 
>: It can, but why should everything depend on lobbying?
>
>It shouldn't. Can you name an alternative?

No. But if someone could, would you be ready to accept any?

>:  This is why I said that the state
>: should intervene and tune the game rules.
>
>But those who intervene to find a solution to the problem
>of tuning the game rules play another game doing so, which has its
>own set of rules, so we'd need another crowd tuning the rules
>of that game, which needs to be controlled by a third crowd tuning
>the rules of the second game, and...

Yes.

>(As a matter of fact, tuning the rules does take place, but
>consider how it takes place.)
>
>If you cannot name an absolute point of reference, this leads to
>a classical problem.  Justifying politics is lost in recursion
>because there are no scientific axioms to stop it.
> Enter Ideology, enter Belief, enter Knot-Cutting-Sword.

Yes.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>I do not want to undermine craftsmanship. Sometimes engineers work
:>as craftspeople and vice versa. Sometimes craftspeople have domain
:>knowledge superior to engineers', and vice versa. Sometimes both
:>know much/little about related sciences that might even be unkown
:>to the scientists.
: 
: No engineer cannot know more than a scientist, because any engineer is
: a scientist when he/she *knows* something.
: 
: Craftspeople may only have practical experience, be trained etc, but
: not know. When alchemists started to know, they became chemists.

If I understand the rules of your rhetorics game correctly,
a craftsperson becomes a scientist as soon as he or she knows
something? Or do they become engineers?
Like the stone carvers and master masons in the late middle ages
who had learned geometry, languages, etc., and did experiments?

What good is there in calling a craftsman an engineer because
he happens to be a craftsman who knows something? He might
take pride in being a craftsman *and* in knowing something.
He might not want to be called an engineer.

: Science and arts are stagnating and highly unpopular.

How do you measure this? I find it hard to believe that
you measure evolving science by the number of years it
takes to invent an improved vehicle.

 
:>: It can, but why should everything depend on lobbying?
:>
:>It shouldn't. Can you name an alternative?
: 
: No. But if someone could, would you be ready to accept any?

Any in the sense of just about any no matter what?
It is of no importance what I would accept. If people
see an alternative to lobbying, it is likely that some will
adopt it if it seems rewarding.

 
-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue, 4 May 2004 12:21:39 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:>I do not want to undermine craftsmanship. Sometimes engineers work
>:>as craftspeople and vice versa. Sometimes craftspeople have domain
>:>knowledge superior to engineers', and vice versa. Sometimes both
>:>know much/little about related sciences that might even be unkown
>:>to the scientists.
>: 
>: No engineer cannot know more than a scientist, because any engineer is
>: a scientist when he/she *knows* something.
>: 
>: Craftspeople may only have practical experience, be trained etc, but
>: not know. When alchemists started to know, they became chemists.
>
>If I understand the rules of your rhetorics game correctly,
>a craftsperson becomes a scientist as soon as he or she knows
>something? Or do they become engineers?

Scientists' beer is paid by taxpayers, while engineers should first
earn it, if you don't mind my "rhetorics game". (:-))

>Like the stone carvers and master masons in the late middle ages
>who had learned geometry, languages, etc., and did experiments?

Yes, though masons practiced in humanitarian "sciences", where
learning geometry is rather an obstacle. (:-))

>What good is there in calling a craftsman an engineer because
>he happens to be a craftsman who knows something? He might
>take pride in being a craftsman *and* in knowing something.
>He might not want to be called an engineer.

Are things now so bad that it became a swear-word?

>: Science and arts are stagnating and highly unpopular.
>
>How do you measure this? I find it hard to believe that
>you measure evolving science by the number of years it
>takes to invent an improved vehicle.

I do not measure it, I just observe it.

>:>: It can, but why should everything depend on lobbying?
>:>
>:>It shouldn't. Can you name an alternative?
>: 
>: No. But if someone could, would you be ready to accept any?
>
>Any in the sense of just about any no matter what?
>It is of no importance what I would accept. If people
>see an alternative to lobbying, it is likely that some will
>adopt it if it seems rewarding.

You are an incorrigible idealist! Didn't people saw alternatives to
x86, Windows, C++? Don't they see that all people are brethren? Would
you ask me now how I measure their blindness?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
:>He might not want to be called an engineer.
: 
: Are things now so bad that it became a swear-word?

I haven't said that this is the general case.

 
:>It is of no importance what I would accept. If people
:>see an alternative to lobbying, it is likely that some will
:>adopt it if it seems rewarding.
 
: You are an incorrigible idealist!

I'm just observing. GNU/Linux together with additional software
has become an option for individuals, for sellers, for companies,
and for organisations. It does seem rewarding to use the system in
various settings.
And this is not just an immediate consequence of the technical
merits of old Unix, i.e. a consequence of technical superiority
or inferiority.
Neither is it just a consequence of the existence of some Linux lobby.
People find it useful, there are peer groups, there is support
at all levels, it is visible at big companies. What else is needed?
An Ada compiler and good source code editing software... No, wait,
it's already there! :-)

: Didn't people saw alternatives to
: x86, Windows, C++? Don't they see that all people are brethren? Would
: you ask me now how I measure their blindness?

Why? Many have seen the alternatives, including sellers. Norms, values,
and in particular their expectations of norms and values (and returns)
might have hindered adoption of OS/2, ARM machines, transputers, ....
So we won't have to measure blindness, but risk-taking in the face
of commonly held beliefs about the viability of an alternative. It
does happen.


-- Georg

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:iehe905bhe24oeenoj7vrccahlrrd8b2tc@4ax.com...
> Science and arts are stagnating and highly unpopular. The first jet
> aircraft was built about 1945, less than in 20 years we were in space.
> In ten years we were on the Moon.

Now you really have me confused. First you say that Science is stagnating.
The rest of the paragraph indicates that Science is moving at a rather rapid
clip!

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue, 04 May 2004 13:56:43 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:iehe905bhe24oeenoj7vrccahlrrd8b2tc@4ax.com...
>> Science and arts are stagnating and highly unpopular. The first jet
>> aircraft was built about 1945, less than in 20 years we were in space.
>> In ten years we were on the Moon.
>
>Now you really have me confused. First you say that Science is stagnating.
>The rest of the paragraph indicates that Science is moving at a rather rapid
>clip!

Have I missed news reports about our astronauts landing on Mars? The
last thing I mentioned was almost 40 years ago!

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> Engineering is a product of science. Without science it is called
> craftsmanship.

With the same logic and in the same sense one can say that science (at least
natural science) is a product of engineering: physics is practically
indistinguishable from philosophy without engineered tools, as well as
chemistry from alchemy. Social sciences were also just a branches/aspects
of philosophy before they employed engineered tools (data processing tools).

Actually one can consider science (at least modern science) as an engineering
in common mental space.

And all that said, science and engineering are still entirely different
activities.

> >> > there are international organizations and national organization in various
> >> >countries (some of then actually are international - like ACM and IEEE)
> >> >dealing with software as well. What else you want? Are you participating in
> >> >at least one of those organizations?
> >>
> >> Can you remember the last time CNN mentioned IEEE in its news block?
> >> UN-bureaucrats are aired each day.
> >
> >So your understanding of democracy implies that any substantial influence,
> >even in complex scientific/technical matters, can be performed only by bodies,
> >of which general public is well aware through mass-media?
>
> Absolutely. To be prepared for concessions (science is an expensive
> thing) public has to be aware of what's going on.

Great. Do you think that general public (in USA) was well aware of RAND
Corporation in 60th? Do you think those battalions of think tanks, which
emerge in recent decades either do not influence anything significantly or
are well-known to general public?

> >> Neither software nor legal
> >> system can even emerge without humans. Yet criminal law exists.
> >
> >Airplanes could not emerge without humans, but they are much faster than
> >humans, and they can fly.
>
> Thus according to your logic they should be excluded from legal
> system.

Hm, but they are indeed excluded. For example, as far as I understand, in USA
they are practically excluded from the legal system by the method of
delegation, that is, the law designates a professional (non-legal) body,
and then requires that all dealing with airplanes must comply with the rules
(mostly non-legal rules in their essence) established by that body (FAA, I
think). And that exclusion is provided for an area where threat to human lives
is severe and constant.

But I note that you used a metaphor for jumping off-off-topic. Perhaps you
are just dancing.

> >> Depending on application area, the state has right to require definite
> >> procedures to be applied for software construction. This is a common
> >> practice. There is no reason to reinvent wheel here.
> >
> >That may be true for some application domains, but only for small minority of
> >them.
>
> This would be vast majority, and very soon.

Is a smart dust your favorite nightmare?

> >> Those are not notions, but knowledge. It is *known* that bridges shall
> >> not be built without analysis of statics etc. Again, there is no
> >> reason, why it should be otherwise in case of software.
> >
> >It is quite obvious (and was said many times by various people) that humans
> >have built bridges for many centures,
>
> Yes, and in ancient Rome, the engineer should stand under his bridge
> during first tests.

Yes, legends said that. But it never was said they those poor Roman engineers
should stand under their bridges all the time while those bridges are used,
or even once per week for a hour.

> >but they have built software for several
> >decades only. Do you perceive significant difference between many centures
> >and several decades of experience?
>
> I see no difference. Do not build bridges if you cannot.

Well, OK, we'll have much less bridges. We'll swim and sometimes drown. 

> If you
> believe that you can, be liable for the result. If you know that you
> cannot, but pretend that you can, then your place is in jail.

I don't want to be in jail - I prefer that you'll be drowned trying to cross
a river without a bridge. 

> >> Consider a bed-side monitoring system for resuscitation departments.
> >> Should a patient die because of software crash, who would be liable?
> >
> >I can't see a difference (for a user, that is either the patient or hospital)
> >between a software crash or hardware malfunction in that system.
>
> The difference is that next time, other firm would pay more attention
> to quality. As you probably know, the most important goal of
> punishment is prevention of crime.

I still can't see a difference between in this example between software crash
and hardware malfunction in the system. The quality is equally involved in
both cases.

> >In that
> >your example I'd sue the hospital, which uses that system - for incompetency
> >with the tools it employs.
>
>The judge will answer you that according to your theory, it is solely
> you who was incompetent in choosing a hospital employing tools
> developed by incompetent vendors.

It is quite possible, at least in American courts, as far as I understand.
If the judge decided that my expectations were unreasonable, that I did not
exercise enough efforts for ensure that those my expectations will be met
by this particular hospital, then the judge probably will answer something
like that. But if the judge decided that according to common sense my
expectations were reasonable and that (again, according to common sense)
I made appropriate inquiries and received confirmations (of if I was deprived
from an opprtunity to get the necessary information) - then the judge probably
will found the hospital guilty.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue,  4 May 2004 07:11:21 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> Engineering is a product of science. Without science it is called
>> craftsmanship.
>
>With the same logic and in the same sense one can say that science (at least
>natural science) is a product of engineering:

Absolutely

>physics is practically
>indistinguishable from philosophy without engineered tools, as well as
>chemistry from alchemy. Social sciences were also just a branches/aspects
>of philosophy before they employed engineered tools (data processing tools).
>
>Actually one can consider science (at least modern science) as an engineering
>in common mental space.
>
>And all that said, science and engineering are still entirely different
>activities.

Science is consciousness of engineering.

>> >> > there are international organizations and national organization in various
>> >> >countries (some of then actually are international - like ACM and IEEE)
>> >> >dealing with software as well. What else you want? Are you participating in
>> >> >at least one of those organizations?
>> >>
>> >> Can you remember the last time CNN mentioned IEEE in its news block?
>> >> UN-bureaucrats are aired each day.
>> >
>> >So your understanding of democracy implies that any substantial influence,
>> >even in complex scientific/technical matters, can be performed only by bodies,
>> >of which general public is well aware through mass-media?
>>
>> Absolutely. To be prepared for concessions (science is an expensive
>> thing) public has to be aware of what's going on.
>
>Great. Do you think that general public (in USA) was well aware of RAND
>Corporation in 60th? Do you think those battalions of think tanks, which
>emerge in recent decades either do not influence anything significantly or
>are well-known to general public?

Are you disagree with me? Do you think that science should be a secret
sect?

>> >> Neither software nor legal
>> >> system can even emerge without humans. Yet criminal law exists.
>> >
>> >Airplanes could not emerge without humans, but they are much faster than
>> >humans, and they can fly.
>>
>> Thus according to your logic they should be excluded from legal
>> system.
>
>Hm, but they are indeed excluded. For example, as far as I understand, in USA
>they are practically excluded from the legal system by the method of
>delegation, that is, the law designates a professional (non-legal) body,
                                    ^^^^
>> >> Those are not notions, but knowledge. It is *known* that bridges shall
>> >> not be built without analysis of statics etc. Again, there is no
>> >> reason, why it should be otherwise in case of software.
>> >
>> >It is quite obvious (and was said many times by various people) that humans
>> >have built bridges for many centures,
>>
>> Yes, and in ancient Rome, the engineer should stand under his bridge
>> during first tests.
>
>Yes, legends said that. But it never was said they those poor Roman engineers
>should stand under their bridges all the time while those bridges are used,
>or even once per week for a hour.

Probably because these bridges keep standing for thousand years. Can
you promise that for MS-Word?

>> >but they have built software for several
>> >decades only. Do you perceive significant difference between many centures
>> >and several decades of experience?
>>
>> I see no difference. Do not build bridges if you cannot.
>
>Well, OK, we'll have much less bridges. We'll swim and sometimes drown. 
>
>> If you
>> believe that you can, be liable for the result. If you know that you
>> cannot, but pretend that you can, then your place is in jail.
>
>I don't want to be in jail - I prefer that you'll be drowned trying to cross
>a river without a bridge. 

There always will be people who will challenge any problem. You should
only protect them from those who would make money by selling us
air-cushions made of paper.

>> >> Consider a bed-side monitoring system for resuscitation departments.
>> >> Should a patient die because of software crash, who would be liable?
>> >
>> >I can't see a difference (for a user, that is either the patient or hospital)
>> >between a software crash or hardware malfunction in that system.
>>
>> The difference is that next time, other firm would pay more attention
>> to quality. As you probably know, the most important goal of
>> punishment is prevention of crime.
>
>I still can't see a difference between in this example between software crash
>and hardware malfunction in the system. The quality is equally involved in
>both cases.

So why are you for hardware certification and against software one?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >And all that said, science and engineering are still entirely different
> >activities.
>
> Science is consciousness of engineering.

This is just a slogan - you may use it where appropriate, but don't rely upon
it too much.

Science, or more precisely, a part (not major part) of well-established
(vs. vanguard), often almost fossilized science is a part - and what is
important - not leading part, but rather supportive part of consciousness
of engineering. There are other, major parts of consciousness of engineering,
which have leading roles: utility for a customer and public and safety for
a customer and public.

> >> >> > there are international organizations and national organization in various
> >> >> >countries (some of then actually are international - like ACM and IEEE)
> >> >> >dealing with software as well. What else you want? Are you participating in
> >> >> >at least one of those organizations?
> >> >>
> >> >> Can you remember the last time CNN mentioned IEEE in its news block?
> >> >> UN-bureaucrats are aired each day.
> >> >
> >> >So your understanding of democracy implies that any substantial influence,
> >> >even in complex scientific/technical matters, can be performed only by bodies,
> >> >of which general public is well aware through mass-media?
> >>
> >> Absolutely. To be prepared for concessions (science is an expensive
> >> thing) public has to be aware of what's going on.
> >
> >Great. Do you think that general public (in USA) was well aware of RAND
> >Corporation in 60th? Do you think those battalions of think tanks, which
> >emerge in recent decades either do not influence anything significantly or
> >are well-known to general public?
>
> Are you disagree with me?

Yes, I believe that your viewpoint is way too simple and therefore inadequate.
Recall the notions of "visibility", "information hiding" and "encapsulation",
apply them metaphorically to public informational structure of society - and
you'll see some opportunities, and perhaps even necessities.

> Do you think that science should be a secret sect?

No, there is relatively little (at any given moment) in science to be kept
in secret.

My point is that if you are not just a citizen, but also an established
professional, and if you care about impact of your profession onto society,
then you should pay attention not only for the leading public institutions
of the whole society but also for leading public institutions of your
profession. In the areas of programming and software engineering the latter
are (as far as I understand) ACM and IEEE.

> >it never was said they those poor Roman engineers
> >should stand under their bridges all the time while those bridges are used,
> >or even once per week for a hour.
>
> Probably because these bridges keep standing for thousand years.

That could't be guessed in advance, so that couldn't be a reason for
discharging the engineers from the duty of standing under those bridges.

> Can you promise that for MS-Word?

Can you promise that for any currently standing bridge? As for MS-Word, it is
standing (yes, with substantial maintenance/upgrading) more than a decade, I
think - not a small period in software age.

> >> >but they have built software for several
> >> >decades only. Do you perceive significant difference between many centures
> >> >and several decades of experience?
> >>
> >> I see no difference. Do not build bridges if you cannot.
> >
> >Well, OK, we'll have much less bridges. We'll swim and sometimes drown. 
> >
> >> If you
> >> believe that you can, be liable for the result. If you know that you
> >> cannot, but pretend that you can, then your place is in jail.
> >
> >I don't want to be in jail - I prefer that you'll be drowned trying to cross
> >a river without a bridge. 
>
> There always will be people who will challenge any problem.

You mean that there always will be enough people who will challenge any
problem, including a liability and a threat of jail? Well, possibly it is so,
but how can you know that and rely upon that, not being one of those people,
and not having many friends of this kind around you?

> >> >> Consider a bed-side monitoring system for resuscitation departments.
> >> >> Should a patient die because of software crash, who would be liable?
> >> >
> >> >I can't see a difference (for a user, that is either the patient or hospital)
> >> >between a software crash or hardware malfunction in that system.
> >>
> >> The difference is that next time, other firm would pay more attention
> >> to quality. As you probably know, the most important goal of
> >> punishment is prevention of crime.
> >
> >I still can't see a difference between in this example between software crash
> >and hardware malfunction in the system. The quality is equally involved in
> >both cases.
>
> So why are you for hardware certification and against software one?

I am against differentiation software from hardware in a single device from
viewpoint of law. Law may require certification of device, certification or
licensing of particular use of the device, liability for vendor or liability
for user, but it should not separate software from hardware in that device.
Even if law needed to speak differently about the fixed part of the device
and replaceable part of it, it should speak exactly about fixed and
replaceable parts, and not about hardware and software - even if the
replacement of the replaceable part can be done over the Internet.

Note that your fears about unreliable downloading of software (or downloading
an unverifyed software) into device have some analogy in hardware - if one
would use unprotected external cables for a device then various sources of
electromagnetic fields would induce a lot of noise into the cables.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Wed,  5 May 2004 00:34:05 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >> >> > there are international organizations and national organization in various
>> >> >> >countries (some of then actually are international - like ACM and IEEE)
>> >> >> >dealing with software as well. What else you want? Are you participating in
>> >> >> >at least one of those organizations?
>> >> >>
>> >> >> Can you remember the last time CNN mentioned IEEE in its news block?
>> >> >> UN-bureaucrats are aired each day.
>> >> >
>> >> >So your understanding of democracy implies that any substantial influence,
>> >> >even in complex scientific/technical matters, can be performed only by bodies,
>> >> >of which general public is well aware through mass-media?
>> >>
>> >> Absolutely. To be prepared for concessions (science is an expensive
>> >> thing) public has to be aware of what's going on.
>> >
>> >Great. Do you think that general public (in USA) was well aware of RAND
>> >Corporation in 60th? Do you think those battalions of think tanks, which
>> >emerge in recent decades either do not influence anything significantly or
>> >are well-known to general public?
>>
>> Are you disagree with me?
>
>Yes, I believe that your viewpoint is way too simple and therefore inadequate.

It is not a viewpoint. It is a statement: "public should know".

>Recall the notions of "visibility", "information hiding" and "encapsulation",
>apply them metaphorically to public informational structure of society - and
>you'll see some opportunities, and perhaps even necessities.

These principles tell that irrelevant, non-essential information has
to be hidden from user/decision maker. So what follows from your, now
viewpoint, is as simple as "science is irrelevant". Well it is quite
adequate to the common mood. You accept it, I don't.

>My point is that if you are not just a citizen, but also an established
>professional, and if you care about impact of your profession onto society,
>then you should pay attention not only for the leading public institutions
>of the whole society but also for leading public institutions of your
>profession. In the areas of programming and software engineering the latter
>are (as far as I understand) ACM and IEEE.

This is an ultimately wrong point. Things I talked about require
political decisions. The worst ever thing, which might happen is when
such decisions would be made in technical circles.

>> Can you promise that for MS-Word?
>
>Can you promise that for any currently standing bridge?

One can do it for any given number of years with a very high
probability.

>As for MS-Word, it is
>standing (yes, with substantial maintenance/upgrading) more than a decade,

MS dropped product upgrade model. And what is called "upgrade" in this
case, has nothing to do with upgrading material things.

>You mean that there always will be enough people who will challenge any
>problem, including a liability and a threat of jail? Well, possibly it is so,
>but how can you know that and rely upon that, not being one of those people,
>and not having many friends of this kind around you?

So far people keep on crossing roads at great risk of liability if
someone would die in accident. Moreover they themselves may be run
over. And look, they do it for free! Strange people!

>> >> >> Consider a bed-side monitoring system for resuscitation departments.
>> >> >> Should a patient die because of software crash, who would be liable?
>> >> >
>> >> >I can't see a difference (for a user, that is either the patient or hospital)
>> >> >between a software crash or hardware malfunction in that system.
>> >>
>> >> The difference is that next time, other firm would pay more attention
>> >> to quality. As you probably know, the most important goal of
>> >> punishment is prevention of crime.
>> >
>> >I still can't see a difference between in this example between software crash
>> >and hardware malfunction in the system. The quality is equally involved in
>> >both cases.
>>
>> So why are you for hardware certification and against software one?
>
>I am against differentiation software from hardware in a single device from
>viewpoint of law. Law may require certification of device, certification or
>licensing of particular use of the device, liability for vendor or liability
>for user, but it should not separate software from hardware in that device.
>Even if law needed to speak differently about the fixed part of the device
>and replaceable part of it, it should speak exactly about fixed and
>replaceable parts, and not about hardware and software - even if the
>replacement of the replaceable part can be done over the Internet.

LOL. Do you seriously belive that no components are certified until
being packed into a car?

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> >> >> >So your understanding of democracy implies that any substantial influence,
> >> >> >even in complex scientific/technical matters, can be performed only by bodies,
> >> >> >of which general public is well aware through mass-media?
> >> >>
> >> >> Absolutely. To be prepared for concessions (science is an expensive
>> >> thing) public has to be aware of what's going on.
>[...]
>I believe that your viewpoint is way too simple and therefore inadequate.
>
>It is not a viewpoint. It is a statement: "public should know".

General public can't know that anyway. Perhaps you mean that public must be
told something particular on that matter - just to fill the gap.

> >Recall the notions of "visibility", "information hiding" and "encapsulation",
> >apply them metaphorically to public informational structure of society - and
> >you'll see some opportunities, and perhaps even necessities.
>
> These principles tell that irrelevant, non-essential information has
> to be hidden from user/decision maker.

I'd put it in other words: these notions permit us to tell explicitly that
particular information must be treated as irrelevant to or non-essential for
particular considerations.

> So what follows from your, now
> viewpoint, is as simple as "science is irrelevant".

Science, at least much of relatively modern science, is indeed irrelevant
to current events (except of that it takes money, creates jobs and mentally
trains people for other occupations). That science may or may not be relevant
to more or less distant future, but general public never (and rightfully,
I think) cares much about that foggy future.

> Well it is quite
> adequate to the common mood. You accept it, I don't.

It isn't about the moods, it is about the nature of science. It is not always
a good idea to convert a good school teacher into a successful director/owner
of escort girl agency.

> >My point is that if you are not just a citizen, but also an established
> >professional, and if you care about impact of your profession onto society,
> >then you should pay attention not only for the leading public institutions
> >of the whole society but also for leading public institutions of your
> >profession. In the areas of programming and software engineering the latter
> >are (as far as I understand) ACM and IEEE.
>
> This is an ultimately wrong point. Things I talked about require
> political decisions. The worst ever thing, which might happen is when
> such decisions would be made in technical circles.

I hope you know that decision-makers usually consult their advisors, including
scientific advisors, before taking decisions. And those advisors often consult
various experts. Then, after decision was taken, it must be somehow
implemented, and very often there are many ways to push or to block that
decision at lower levels of administrative hierarchy, when dealing with
technical issues.

So, certainly, political decisions should not be taken in technical circles;
but those circles inevitably participate in preparation of those decisions
and in their implementation. With this participation in the stages they
effectively participate in the whole decision itself - in its real result.
Should they ignore that fact? This a matter of responsibility - that is, how
those technical circles understand their responsibility.

> >Can you promise that for any currently standing bridge?
>
> One can do it for any given number of years with a very high
> probability.

You certainly forgot about terrorists. And perhaps you are totally unaware
about problems with bridges during wars - I recommend you classical film
"Bridge on the River Kwai" for an introduction.

> MS dropped product upgrade model. And what is called "upgrade" in this
> case, has nothing to do with upgrading material things.

Hm, do you know so much about upgrading material things? There are so many
different material things, and they certainly can't have single common way
for upgrading.

> >> So why are you for hardware certification and against software one?
> >
> >I am against differentiation software from hardware in a single device from
> >viewpoint of law. Law may require certification of device, certification or
> >licensing of particular use of the device, liability for vendor or liability
> >for user, but it should not separate software from hardware in that device.
> >Even if law needed to speak differently about the fixed part of the device
> >and replaceable part of it, it should speak exactly about fixed and
> >replaceable parts, and not about hardware and software - even if the
> >replacement of the replaceable part can be done over the Internet.
>
> LOL. Do you seriously belive that no components are certified until
> being packed into a car?

I don't know rules of car industry, but I think that probably some of
components are certified. Perhaps even some materials are certified - at least
I think that in aviation industry it is so.

But this does not matter for the point, because my point is that software
is not a component of a car. Software may participate in various components
of a car, but it is not a component itself.

Look at the example of aviation industry. There are plenty of software in
big airliners, but they do not call those actual components "software", and
they do not separate software from hardware in those components. As far as I
understand, they call that area "avionics", and they certify avionics, not
"software". Perhaps the car industry needs the similar notion. It may be
called "neuronics", for example -:) .



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:c5itve$25vpm$3@ID-77047.news.uni-berlin.de...
> Then you should probably know that OS/2 was better than Windows. How your
> theory would explain its fault?

I worked on a project using OS/2 1.1. Granted, this was before the PM, but
one could not help but be impressed with some of the features of OS/2,
including:

-    True multi-tasking (i. e. not the kind that depended on applications
periodically calling Yield);
-    Multi-threading (not supported in Windows until NT / 95 ); and
-    File system that supported longer file names (not just the DOS 8+3
convention).

One could easily argue that OS/2 with PM is technically superior to the DOS
with Windows 3.x. The problem with OS/2 is that it had a few crucial faults
which prevented it from gaining wider acceptance.

The original versions were buggy. I certainly had my share of problems with
version 1.1, although things were more stable in version 1.2 and 1.3.
Unfortunately, it can be very hard to overcome a bad first impression.

As noted many times before, the memory requirements were a deal killer for
many potential customers. At the time of its release, memory was several
magnitudes more expensive than it is today. An organization moving to OS/2
would not only have to buy a license for the OS for each machine; they would
also have to spend several times that amount for adding a memory card to
each upgraded system. You would have to prove big productivity gains to make
the case for this upgrade.

To support legacy applications, OS/2 offered a DOS compatibility box.  If
you did the INT 21H call to get the DOS version, the compatibility box would
return version 10.0! There were some popular DOS applications, however, that
did not run in the OS/2 DOS box. This made the migration to OS/2 even less
appealing. Upgraders ran the risk that they could not continue using their
current applications, and hence would have to buy new software, train their
personnel on the use of the new software, and deal with revising old data
files to be processed by the new software - not to mention any data
compatibility problems that would arise if you wanted to NOT upgrade the OS
on some of your systems. Not an appealing proposition.

A big mistake that MS and IBM made at the time is that they did not do
enough to encourage third-part application development. They charged a
bloody fortune for the OS/2 SDK, causing many developers to take a "wait and
see" approach to doing an OS/2 project. The OS debuted with few native
applications, and a good portion of them were not very good. (There was,
however, a very nice OS/2 version of the Brief editor. It is a pity that
Software Solutions did not profit from this). There was a similar issue with
the DDK, and for a long time OS/2 lacked printer drivers for some of the
more popular printers. I knew of OS/2 shops that actually set up their
machines in dual boot mode, so they could edit their work in OS/2, then
reboot to DOS when they needed to print!

Let's face it: most users do not want an OS. They want to run applications,
and they get an OS as a means for doing this. Between the problems with the
DOS box and the lack of native applications and drivers, OS/2 was a hard
sell, in spite of the fact that it was technically superior to DOS / Win
3.x.

Bringing this back to Ada, it is not sufficient for Ada to be a technically
superior language. There are certain, practical requirements for Ada to be
an appealing tool for new development. Ada 0x needs to address these
requirements, for otherwise Ada could suffer the same tragic fate as OS/2.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Alexander E. Kopilovich <aek@vb1162.spb.edu> wrote:
:>requirement being that the product fufill some (but not necessarily all) of
:>its promises.
: 
:
:
: professional traitorousness among CS teachers in American universities.

What are the requirements in the minds of CS teachers?
- A university job is not enough gratifying per se, so they need
  to feel close to the software industry?
- Do they think they should produce Off the Shelf Students?
- Do they submit themselves to the students who think they will
  be qualified iff they know The Current Language? (Are the students
  right?)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:c4tpu9$sqq$1@a1-hrz.uni-duisburg.de...
> Alexander E. Kopilovich <aek@vb1162.spb.edu> wrote:
> :>requirement being that the product fufill some (but not necessarily all)
of
> :>its promises.
> :
> :
> :
> : professional traitorousness among CS teachers in American universities.
>
> What are the requirements in the minds of CS teachers?
> - A university job is not enough gratifying per se, so they need
>   to feel close to the software industry?

For the past several years, I have been teaching in a university where
Ada was originally a required subject.   When I first began teaching
at this institution, my classes were well-attended and students were
enjoying the opportunity to learn Ada.   The requirement for Ada was
eliminated a couple of years ago and attendance in the Ada classes
plummeted.

Many of the other faculty members have expressed a distaste for Ada,
some suggesting that the sooner it disappears forever, the better. When
I recommend that a student use Ada for a thesis project, unless I am the
thesis advisor, the student is told that Ada is not appropriate for serious
thesis work.  "Use Java or C++, but not Ada."

My school is not unique.   Throughout academia, Ada is falling victim
to a widespead misunderstanding of its value and capabilities.  One
might think that well-educated faculty members would know better,
but that seems not to be the case.

As long as industry is not using Ada, it is difficult to persuade academics
to promote it.   As long as academia fails to include Ada in the curriculum,
it is difficult to persuade, it is difficult to persuade industry of its
viability. We
have something of a stand-off between industy and academia.  It does not
help that some of our graduate students are bragging about how they are
"ripping out all that old Ada code" in this or that system and replacing it
with C++.

Some of the largest military contractors have decided to abandon Ada even
as they commend its value over competing technologies.  "We just cannot
hire experienced Ada programmers, and the universities don't teach it
anymore."    In their view it is cheaper and easier to find C++ programmers.
While this is a shortsigthed, perhaps even irresponsible management
decision,
for weapon systems development, the fact that the Pentagon has abandoned
all support for Ada gives those contractors good reason to go a different
direction.  From their view, the DoD is actually opposed to the use of Ada.
It is a wrong point-of-view, but it is widespread.

We need a statement from someone of influence in the U.S. DoD establishment
that affirms the value of Ada.  Unfortunately, no one will do this.  It is
not
politically expedient.  Furthermore, there may not be anyone left in the
Pentagon
that actually understands the importance of this issue.   As a consequence,
we
are likely to see, over the next decade, a series of software systems,
written in
C++ that are expensive to create, difficult to maintain, and highly
profitable for
military contractors.  It is an example, in the case of the U.S. DoD, of
"grabbing
defeat from the jaws of victory."   Ada could have been a powerful force for
software superiority.  Instead, they are allowing contractors to choose
whatever
technology is expedient, and, I fear, at the expense of long-term software
quality.

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Richard  Riehle <adaworks@earthlink.net> wrote:
: As long as industry is not using Ada, it is difficult to persuade academics
: to promote it.   As long as academia fails to include Ada in the curriculum,
: it is difficult to persuade, it is difficult to persuade industry of its
: viability. We
: have something of a stand-off between industy and academia.

Maybe things are slightly different in Europe? A few hints make me
think that use of Ada in universities is at least a "moving
distribution".
Does someone use Ada for car electronics?

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Chad R. Meiners]

"Richard Riehle" <adaworks@earthlink.net> wrote in message
news:VD_fc.13510$k05.6011@newsread2.news.pas.earthlink.net...
> unless I am the
> thesis advisor, the student is told that Ada is not appropriate for
serious
> thesis work.  "Use Java or C++, but not Ada."

As a graduate student, I can't imagine what sort of rational advisors would
have in saying this.  What sort of serious thesis work would dictate the use
of Java or C++?

-CRM

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

"Chad R. Meiners" writes:
> "Richard Riehle" wrote in message
> > unless I am the thesis advisor, the student is told that Ada is
> > not appropriate for serious thesis work.  "Use Java or C++, but
> > not Ada."
> 
> As a graduate student, I can't imagine what sort of rational advisors would
> have in saying this.  What sort of serious thesis work would dictate the use
> of Java or C++?

Perhaps, C++ has so many little-understood fine points that
theoretical research is required to explain them all?

Perhaps it is necessary to do some in-depth research to improve the
performance and predictability of Java programs?

Ada is just too good for this; it is well understood and does not
suffer from inherent performance problems.

Or, perhaps there is no rationality at all in the advice given by
university professors; they just recommend a language they think they
can have fun with themselves.  Or they want to be part of the large
C++ or Java communities, and not feel isolated as a member of the
small Ada community.

Also, they have no need for a language that promotes code reuse or
maintainability; they do not reuse nor maintain code :(

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jeffrey Carter]

Richard Riehle wrote:

> As a consequence, we are likely to see, over the next decade, a
> series of software systems, written in C++ that are expensive to
> create, difficult to maintain, and highly profitable for military
> contractors.

This, of course, is the real problem. Engineering high quality software 
is less profitable than hacking crap. Until this changes, Ada and 
software engineers will be seen as liabilities, not advantages.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

You can't really mean that, can you? Luck is the only thing that makes 
anybody or anything successful? Babe Ruth was just lucky and it didn't 
have anything to do with skill & practice? Henry Ford just tripped over 
a car one day and got filthy rich without creativity and hard work? 
Thomas Edison's light bulb caught on & became popular because it was 
crap with a good marketing plan?

I'd seriously have to differ here. Yes, "Luck" can play a role in the 
success of anyone or anything - but you first have to do a lot of hard 
work and get a lot of things right so you can be in the right place at 
the right time for "Luck" to hit you.

Java provides an identifiable market with a toolset that fits their 
needs better than other available products. That market is pretty big. 
Java got "Lucky" because someone took the time to identify the market 
they wanted to address with Java and figured out what that market wanted 
& needed to get its job done.

Ada, OTOH, identified (and still does) a relatively *small* market niche 
- embedded/realtime & now large/long-lived/high-reliability systems. 
That market was rapidly changing at the time from a "go it alone" niche 
that took care of itself technologically to a "market follower" that 
would take its technology from the vastly larger segment of PC/User-apps 
market. Having identified the wrong market to address at the wrong time, 
Ada went off to tell that market "I'm much wiser than you are about what 
you need, so here's the way you're going to do it and you're required to 
do it *my* way..." rather than really finding what the market wanted & 
needed. Is that (bad) luck or just bad decisions?

To a large extent, Ada is *still* addressing the wrong market. The 
realtime/embedded/long-lived/high-reliability market cannot afford to go 
out and have its own language. It needs to be competitive and it needs 
lots of really sophisticated tools and it just isn't big enough to be 
able to afford to pay to get all that stuff on its own. Hence, it now 
relies on the things produced for the much larger market & then 
customizes them for their own needs. Its fundamentally cheaper than 
trying to build up your own little world. Yet Ada bemoans the fact that 
the market is "going with the crowd" as if its being run by a bunch of 
four star idiots, when in fact, these guys have run the numbers and come 
to the conclusion that their dollars are better spent using compilers & 
tools that are stamped out by the bajillions and sold/used all over the 
planet. Is that (bad) luck or a failure to pay attention to the customer 
and see what is driving his decisions?

So Ada can continue to persue that particular market nich or it could 
take a new direction. To persue that market niche, it needs to provide 
*everything* someone can get by going with C++ or Java and something 
extra to motivate swimming against the tide *plus* it will need to build 
the pool of available human resources that one can get when one 
advertises for C++ or Java programmers. Ada can do this and hope to get 
lucky or it could realize that is a losing proposition and go down 
another route.

If Ada were smart about it, it would go about trying to remake itself 
into a language that will address some much larger segment of the 
market. If it identified that larger (more profitable) segment and went 
about trying to satisfy that market by providing it with far more useful 
stuff than can be had with Java or C++, it just might find itself in a 
position to be "Lucky". If it got big there, then it might be a lot 
easier for someone in the realtime/embedded/long-lived/high-reliability 
market to go along for the ride.

If Ada were smart, the vendors would get together, figure out what the 
best new market would be, agree to go address it, find out what that 
market wants and then vigorously go and build for that market. If it 
offered something *new* and *exciting* to that market and did it better 
than anything else out there, it might get lucky and find that "Critical 
Mass" audience that would make it usable by the smaller niches it 
originally wanted. Will it do that or just sit back and complain that 
the market it wanted was just full of fools?


MDC



Randy Brukardt wrote:
> 
> The reason that Java got successful (like the reason that *anything* or
> *anyone* gets successful) was luck. Sun got what had been a widely ignored
> language/system tied to a skyrocket (the internet) by putting applet support
> into Netscape. That got the foot in the door where heavy promotion could
> make an effect.
> 
> Remember, it's a combination of luck and marketing that makes anyone or
> anything successful. Merit has very little to do with it - the only
> requirement being that the product fufill some (but not necessarily all) of
> its promises.
> 
> Most software is crap because you can sell crap as well as easily as
> gold-plated programs. Since most managers know this, why would they care if
> they use crap to develop it? It's the same reason that so many software jobs
> are being outsourced -- there it's any reason to get anything beyond an
> adequate job at the cheapest possible rate.
> 
> Those of us who would like something better are swimming upstream in the
> Niagara River; we're almost (but not certainly) doomed to fail.
> 
>                           Randy.
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:

: these guys have run the numbers and come 
: to the conclusion that their dollars are better spent using compilers & 
: tools that are stamped out by the bajillions and sold/used all over the 
: planet.

I think that is a bit optimistic. Sure some managers try to reason
before a decision, but this decision usually has lots of other factors
driving it than just an alledged cost & availability calculation?

Many decisions look like they are driven by a "critical revenue"
factor ("I can get by with xyz until next year..."),
not by the "optimizing" process that is still hypothesized in some
economy classes. Therefore, decisions need not involve engineering
principles or thinking of long term effects. With all its consequences...


 
: If Ada were smart, the vendors would get together, figure out what the 
: best new market would be, agree to go address it, find out what that 
: market wants and then vigorously go and build for that market.

I just noted that Aonix have released new JNI binding software
for ObjectAda. If you think of cell phones, isn't there a JVM
inside some of them?

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Georg Bauhaus wrote:
 >
 > I think that is a bit optimistic. Sure some managers try to reason
 > before a decision, but this decision usually has lots of other
 > factors driving it than just an alledged cost & availability
 > calculation?
 >
 > Many decisions look like they are driven by a "critical revenue"
 > factor ("I can get by with xyz until next year..."), not by the
 > "optimizing" process that is still hypothesized in some economy
 > classes. Therefore, decisions need not involve engineering principles
 > or thinking of long term effects. With all its consequences...
 >

Not all decisions are perfectly made, but ask this: Why would a bunch of
guys with an existing investment in Ada drop it like a hot potato the
instant they could? Possible answers:

1) They're stupid. (are they?)

2) They're filled with irrational hatred of Ada. (why?)

3) They're motivated by a desire for benefits that are not addressed by
Ada as well as they are by some other language.

Personally, I'd vote for "3" because it means I might be able to learn
what those desires are and try to better satisfy them with Ada. "1" and
"2" are pretty hopeless and defeatist. Believing that might satisfy my
ego ("Stupid people don't like my language and that's why it lost - not
because I did something wrong...") but it does nothing to change the
situation.


 >
 > I just noted that Aonix have released new JNI binding software for
 > ObjectAda. If you think of cell phones, isn't there a JVM inside some
 > of them?
 >
Cell phone apps are a prime opportunity in a growing field. I'm not sure
that I'd vote for that one because the number of end-users may be 
astronomical, but are the number of *developers* going to be that large? 
Unclear at this point.

But you've got the idea - find something with a potentially large number 
of developers who might benefit from a language plus lots of domain 
specific help. Give them what they want and maybe they come to Ada.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: Not all decisions are perfectly made, but ask this: Why would a bunch of
: guys with an existing investment in Ada drop it like a hot potato the
: instant they could? Possible answers:
 [...] 
: 3) They're motivated by a desire for benefits that are not addressed by
: Ada as well as they are by some other language.

So we'd have to change the perception of Ada. There are good
components available for building, e.g. small secure eShops.
WebSphere, big and rich as it is, doesn't seem to do too well,
PHP is used here and there, Java/Tomcat has tricky little
tasking/RPC/TCP/IP problems, so how about AWS?

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Not sure where you are going with that, but I'll say that I don't think 
it is simply a problem of *perception*. I think there is a lack of 
utility in comparison to other languages and a lack of what could 
generally be characterized as "Industry Support" (Trained personnel, 
support within popular tools & environments, etc.)

You can't really cure the latter without first addressing the former. 
For there to be "Industry Support", Ada has to have some large enough 
audience of users for people to want to learn it, companies to use it & 
build support into their toolsets for it. Its that chicken/egg problem. 
But if Ada has some immense leverage in some reasonably important 
problem domain, people in that domain will start *finding* ways to 
employ it without extensive "Industry Support". That starts building the 
base. Give some audience a 2x improvement in their productivity over 
their nearest competitor and you'll see it start to catch on.

MDC

Georg Bauhaus wrote:

> So we'd have to change the perception of Ada. There are good
> components available for building, e.g. small secure eShops.
> WebSphere, big and rich as it is, doesn't seem to do too well,
> PHP is used here and there, Java/Tomcat has tricky little
> tasking/RPC/TCP/IP problems, so how about AWS?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Marin David Condic wrote:

>Cell phone apps are a prime opportunity in a growing field. I'm not sure
>that I'd vote for that one because the number of end-users may be 
>astronomical, but are the number of *developers* going to be that large? 
>Unclear at this point.

Well, being somehow involved in that field (specifically, Symbian smartphones),
and therefore having glanced at various developers forums (such as Nokia and
SonyEricsson forums and some others) I can guess that there are perhaps
thousands or even (less likely) tens of thousands, but certainly not hundreds
of thousands developers of this kind; but what should be stressed about that
population of developers is that their average professional level isn't high,
as a rule - a competent programmer is a rare bird there. Then, this area is
highly monopolized: there are several giants (Nokia, Sony(/Ericsson) and
Motorola at first place) who practically determine all possibilities. This is
the current picture (as I see it -:) .



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

That's why I would have misgivings about persuing that market. Not 
necessarily that many developers and/or the whole development 
environment is going to be controlled by a handful of really large 
players that will dictate what you use.

But the general concept, I think, is sound: Go find some significant 
part of the market and try to encourage use of Ada there by providing 
that market what it needs. The alternative is to keep shuffling around 
the deck chairs & tidying up while the Titanic sinks.

MDC


Alexander E. Kopilovich wrote:
> 
> Well, being somehow involved in that field (specifically, Symbian smartphones),
> and therefore having glanced at various developers forums (such as Nokia and
> SonyEricsson forums and some others) I can guess that there are perhaps
> thousands or even (less likely) tens of thousands, but certainly not hundreds
> of thousands developers of this kind; but what should be stressed about that
> population of developers is that their average professional level isn't high,
> as a rule - a competent programmer is a rare bird there. Then, this area is
> highly monopolized: there are several giants (Nokia, Sony(/Ericsson) and
> Motorola at first place) who practically determine all possibilities. This is
> the current picture (as I see it -:) .
> 
> 
> 
> Alexander Kopilovich                      aek@vib.usr.pu.ru
> Saint-Petersburg
> Russia
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Hyman Rosen]

Marin David Condic wrote:
> persuing

Just so you know, it's "pursue".

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander E. Kopilovich]

Georg Bauhaus wrote:

>I just noted that Aonix have released new JNI binding software
>for ObjectAda. If you think of cell phones, isn't there a JVM
>inside some of them?
Surely JVM is present inside smartphones and even some cheaper phones, but
so what? Why on earth one will use this strange combination for a phone
application? There are enough "native" problems with C++ and Java in Symbian
smartphones, and I think that additional troubles aren't needed -;) .



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:40729B9D.30906@noplace.com...
> You can't really mean that, can you? Luck is the only thing that makes
> anybody or anything successful? Babe Ruth was just lucky and it didn't
> have anything to do with skill & practice? Henry Ford just tripped over
> a car one day and got filthy rich without creativity and hard work?
> Thomas Edison's light bulb caught on & became popular because it was
> crap with a good marketing plan?

Of course, hard work is needed as a pre-requisite. But success itself (the
sort of mass-market success that we're talking about here) is a matter of
luck. For every Babe Ruth, there's plenty of other players that never got
the right chance. Henry Ford was one out of several hundred automobile
manufacturers. I'm sure most of them worked very hard. And so on.
Supposedly, another inventor submitted a patent application for the
telephone 6 *hours* after Alexander Graham Bell's was submitted. I'm sure
both of them worked hard, but only one got any of the success.

There were thousands of people and companies who worked hard in the early PC
computer business. (I knew a number of them.) Only a few had any real
success. (I didn't know any of them. :-)

...
> Ada, OTOH, identified (and still does) a relatively *small* market niche
> - embedded/realtime & now large/long-lived/high-reliability systems.

Bullpucky. *Ada* (not some company or implementation) is a general-purpose
programming language. Nothing more and nothing less. Embedded systems were
never more that a few percent of RRS's revenues; we've always marketed to
general programming. "Ada" doesn't identify markets; it's simply a thick
book. Vendors do that, and no one can or should tell them what to do.

As far as the rest of your troll, your conclusion is that Ada needs a $100
million markover -- which is clearly not going to happen. So why do you
bother hanging out here and waste the rest of our time with it? You must do
it just to get attention - I'd suggest that kidnapping yourself would be
more effective (a la Audrey Seiler).

                    Randy.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

"Randy Brukardt" writes:
> As far as the rest of your troll, your conclusion is that Ada needs a $100
> million markover -- which is clearly not going to happen. So why do you
> bother hanging out here and waste the rest of our time with it? You must do
> it just to get attention - I'd suggest that kidnapping yourself would be
> more effective (a la Audrey Seiler).

Better - write free software in Ada.  Advertise that you can get good
software out the door quickly, thanks to Ada's superiority.  Show that
Ada programs are inherently safer and more maintainable than programs
in any other language.  Increase the awareness that there are lots of
good libraries out there that provide as much leverage as Java or C++.

GNU/Linux became popular because computer science students were
exposed to it.  It is time now to expose Ada to these people, who in
years to come will make decisions.  Make sure they at least know about
Ada and never choose XYZ out of sheer ignorance.

You may think that writing proprietary software helps spread the word.
It doesn't.  Even high-profile proprietary apps do very little to
advertise the tools they use.  The more Ada is used in life-critical
apps, the more the crows thinks Ada is a special-purpose language. By
writing free, general-purpose software for PCs and Macs, you can
dispel this myth.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Randy Brukardt wrote:
 >
 > Bullpucky. *Ada* (not some company or implementation) is a
 > general-purpose programming language. Nothing more and nothing less.
 > Embedded systems were never more that a few percent of RRS's
 > revenues; we've always marketed to general programming. "Ada" doesn't
 > identify markets; it's simply a thick book. Vendors do that, and no
 > one can or should tell them what to do.
 >
Not exactly true. Ada has always had a "Focus" if you will and the stuff
that grew up around it was aimed at a specific type of user. Sure, its
"General Purpose" and as such could be used for any type of app you
want. But if the "Focus" isn't on some arena, the folks in that arena
aren't going to see what they want and/or need to do their job. Java put
a focus on web-based apps with GUI interfaces. They built a bunch of
stuff around Java to make that sort of thing easy. There are a lot of
folks doing it and they picked Java over Ada (and other stuff) because
Java helped them get there job done better. Couldn't Ada do the same in
some other arena?



 > As far as the rest of your troll, your conclusion is that Ada needs a
 > $100 million markover -- which is clearly not going to happen. So why
 > do you bother hanging out here and waste the rest of our time with
 > it? You must do it just to get attention - I'd suggest that
 > kidnapping yourself would be more effective (a la Audrey Seiler).
 >
You can call it a troll if you like. You can put me in your kill-file if
you like. Its a free internet. But I'm not suggesting a $100m makeover, 
nor am I here because I want to waste your time. I'm one of the few 
remaining *customers* of Ada here providing a *customer's* view of what 
is right &/or wrong with the direction the language takes. I do it 
because I *like* Ada and wish it would succeed in a much larger market. 
I think refocusing on some new market or creating soem new leverage 
would stand a chance of getting the language a fresh look from other 
customers and a fresh start at building a market share. I think that 
*listening* to the (potential) customer and trying to provide what he 
wants is key to making it work.

But if you want to ascribe all sorts of motives to me that I don't have, 
go right ahead. Its your time to waste thinking about it and being angry 
about it. I've got better things to do with my time than be offended by 
it, so go believe what you want to believe.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Tue, 06 Apr 2004 14:07:36 -0500, Randy Brukardt wrote:

> Bullpucky. *Ada* (not some company or implementation) is a general-purpose
> programming language. Nothing more and nothing less.

Let's say I want to write a dict server - RFC 2229. I can go with C, and
get POSIX-standardized networking code, but a ill-defined, clumsy system
for handling international text that may or may not support UTF-8. I could
go with Perl or Python or Java and get networking code and strong support
for UTF-8 in the basic package. 

Or I could go with Ada. There's no standard networking code, and no way
to input UTF-8 - I can't even input it into the basic character type and
process it, not and stay within the standard. (Of course, that's what
everyone does.) Worse yet, there's no standard or even existing libraries
(IIRC) that will normalize Unicode text or sort it in a language dependent
manner.

It may be general-purpose, but it doesn't fit this purpose. Given that
a lot of programs need to access the net and handle the world's languages,
that's pretty bad.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Wes Groleau]

David Starner wrote:n
> Or I could go with Ada. There's no standard networking code, and no way
> to input UTF-8 - I can't even input it into the basic character type and
> process it, not and stay within the standard. (Of course, that's what
> everyone does.) Worse yet, there's no standard or even existing libraries
> (IIRC) that will normalize Unicode text or sort it in a language dependent
> manner.
> 
> It may be general-purpose, but it doesn't fit this purpose. Given that
> a lot of programs need to access the net and handle the world's languages,
> that's pretty bad.

Maybe that's one of the opportunities Marin has been harping on.

-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Wes Groleau wrote:
> 
> Maybe that's one of the opportunities Marin has been harping on.
> 

Well, yeah. Pick some reasonably large domain of computer programming 
and see what you can do to make life there just duck soup provided one 
uses Ada. Like, for example, networking apps. Could Ada say "Let's focus 
in on people who blip bits up and down a wire and give them everything 
and anything that they need to make their job 10 times easier than if 
they used any other language?" Like start by providing some library 
support for stuff like TCP & UDP? But don't stop there because people 
can get that just about anywhere. Give them stuff like multi-language 
support, common internet protocols, web page support, etc. Remake Ada 
into "The Internet Language" - not by changing the language but by 
changing what you package with it and how you talk about its future 
direction.

Or we could conduct business as usual and rearrange a little syntax and 
semantics and keep doing what took Ada from being a widespread language 
that had the eyes of lots of major corporations and thousands of 
developers and turned it into a niche language that "also ran" in the 
computer language marketplace. That's been working real well for us, 
hasn't it?

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

David Starner wrote:

> On Tue, 06 Apr 2004 14:07:36 -0500, Randy Brukardt wrote:
> 
>> Bullpucky. *Ada* (not some company or implementation) is a
>> general-purpose programming language. Nothing more and nothing less.
> 
> Let's say I want to write a dict server - RFC 2229. I can go with C, and
> get POSIX-standardized networking code, but a ill-defined, clumsy system
> for handling international text that may or may not support UTF-8. I could
> go with Perl or Python or Java and get networking code and strong support
> for UTF-8 in the basic package.
> 
> Or I could go with Ada. There's no standard networking code, and no way
> to input UTF-8 - I can't even input it into the basic character type and
> process it, not and stay within the standard. (Of course, that's what
> everyone does.) Worse yet, there's no standard or even existing libraries
> (IIRC) that will normalize Unicode text or sort it in a language dependent
> manner.

XML/Ada has complete Unicode support. I am using it for AdaCL.CGI. The
problem is, as somebody allready pointed out, that you have to collect half
a dozend Libs before Ada becomes usefull. What needed is a Unified Ada
Library which does not need to provide anything new - only put the
different parts together for a "one click download".

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Pascal Obry]

David Starner <dvdeug@email.ro> writes:

> Or I could go with Ada. There's no standard networking code, and no way
> to input UTF-8 - I can't even input it into the basic character type and
> process it, not and stay within the standard. (Of course, that's what
> everyone does.) Worse yet, there's no standard or even existing libraries
> (IIRC) that will normalize Unicode text or sort it in a language dependent
> manner.

Fine just do it and release the code as Open Source!

The problem with the Ada community is that we tend to spend more time saying
that this and that is missing than to do the job. Who did most of the Perl or
Python code out there ?

Now I agree that the Ada community is small, lot smaller than the Python, Perl
or Java ones... So we just need to work harder :) And we have the luck to have
Ada on our side with its great productivity !

Just do it :) ... and propose it for inclusion in the next standard.

Now about UTF-8, did you looked at XML/Ada or XML4Ada95 ? For networking did
you looked at AdaSockets or GNAT.Sockets ? This is not in the standard, ok,
but it is well designed and maintained.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Wed, 07 Apr 2004 19:40:50 +0200, Pascal Obry wrote:

> Fine just do it and release the code as Open Source!

Why? I have other things to do in my life then write a library that no one
is ever going to use. It seems like there's dozens of alpha libraries and 
bindings out there for Ada, most of which don't actually seem to be used
anywhere, and many of which aren't supported. I'd rather spend my time
working on something interesting and maybe even useful.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ed Falis]

On Wed, 07 Apr 2004 22:14:07 GMT, David Starner <dvdeug@email.ro> wrote:

> On Wed, 07 Apr 2004 19:40:50 +0200, Pascal Obry wrote:
>
>> Fine just do it and release the code as Open Source!
>
> Why? I have other things to do in my life then write a library that no 
> one
> is ever going to use. It seems like there's dozens of alpha libraries and
> bindings out there for Ada, most of which don't actually seem to be used
> anywhere, and many of which aren't supported. I'd rather spend my time
> working on something interesting and maybe even useful.


So let me pose a stupid question to you, David.  Why do you waste your 
time whining here?  Or don't you recognize that that's what you're doing?

- Ed

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Szymon Guz]

Ed Falis wrote:
> On Wed, 07 Apr 2004 22:14:07 GMT, David Starner <dvdeug@email.ro> wrote:
> 
>> On Wed, 07 Apr 2004 19:40:50 +0200, Pascal Obry wrote:
>>
>>> Fine just do it and release the code as Open Source!
>>
>>
>> Why? I have other things to do in my life then write a library that no 
>> one
>> is ever going to use. It seems like there's dozens of alpha libraries and
>> bindings out there for Ada, most of which don't actually seem to be used
>> anywhere, and many of which aren't supported. I'd rather spend my time
>> working on something interesting and maybe even useful.
> 
> 
> 
> So let me pose a stupid question to you, David.  Why do you waste your 
> time whining here?  Or don't you recognize that that's what you're doing?
> 
> - Ed

well... that's not so stupid

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Wed, 07 Apr 2004 22:44:38 +0000, Ed Falis wrote:
> 
> So let me pose a stupid question to you, David.  Why do you waste your 
> time whining here?  Or don't you recognize that that's what you're doing?

Yeah, that was a little over the top, wasn't it? I knew it was shortly
after I sent it, but it never occurred to me that I could cancel it.

More generally, my time's cheap, and comp.lang.ada doesn't take much time.
I program in Ada, but I don't need to define myself by Ada or even
programming (not that the things I define myself by are superior, just
different), and being unable to play language lawyer, I play devil's
advocate, especially to those willing to accuse people of being irrational
because they didn't chose Ada for the job, even when it wouldn't be the
best tool for the job.

Pascal Obry, I'm sorry for my response. It was not a productive response
to your post.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ed Falis]

On Thu, 08 Apr 2004 09:18:41 GMT, David Starner <dvdeug@email.ro> wrote:

> Yeah, that was a little over the top, wasn't it? I knew it was shortly
> after I sent it, but it never occurred to me that I could cancel it.
>

I agree that my comment was also over the top, but I was frustrated by 
your reaction to what was essentially a positive suggestion for dealing 
with the problem.  Life goes on ;-)

- Ed

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Wes Groleau]

Pascal Obry wrote:
> Now I agree that the Ada community is small, lot smaller than the Python, Perl
> or Java ones... So we just need to work harder :) And we have the luck to have
> Ada on our side with its great productivity !

Ah, but a language that is ten times more productive
still can't compete with one that has a hundred times
as many developers.

-- 
Wes Groleau

    Nobody believes a theoretical analysis -- except the guy who did it.
    Everybody believes an experimental analysis -- except the guy who did it.
                                  -- Unknown

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[chris]

Wes Groleau wrote:
> Pascal Obry wrote:
> 
>> Now I agree that the Ada community is small, lot smaller than the 
>> Python, Perl
>> or Java ones... So we just need to work harder :) And we have the luck 
>> to have
>> Ada on our side with its great productivity !
> 
> Ah, but a language that is ten times more productive
> still can't compete with one that has a hundred times
> as many developers.

I'd like to see unbiased studies that find that an Ada programmer is 
10times more productive than a Java one.  It just seems like it's 
peoples opinion, not a fact.  It's also typical of all language 
supporters whatever the language.  Usually they boil down to...

"I am 10 times more productive in Ada than in Java because when I 
program in Java I think in Ada"

"I am 10 times more productive in C++ than in Ada because C++ has curly 
braces which I can type more easily on my keyboard"

"I am 10 times more productive in Erlang than C++ because it has HOF and 
concurrency.  Oh and I can 'Let It Fail(tm)'" - actually this one has 
some truth to it.  The Erlang way is to "Let It Fail".

Assuming it is true that an Ada programmer is 10 times more productive 
than a Java programmer, it can only be so assuming *equivalent* tools 
are available to do the job at hand and equivalent programming skill (no 
point in a comparison otherwise).  If an Ada programmer can complete the 
original job in 1/10th the time with the right tools, great!  If otoh 
they could do it in 1/10th the time if the tools existed but the tools 
aren't available and you have to spend time creating them what's the 
productivity gain?  Still 1/10th?

The productivity argument is useless all languages are on equal footing 
(you might be able to do such a comparison on .Net).

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Vinzent 'Gadget' Hoefler]

chris wrote:

>Assuming it is true that an Ada programmer is 10 times more productive 
>than a Java programmer, it can only be so assuming *equivalent* tools 
>are available to do the job at hand and equivalent programming skill (no 
>point in a comparison otherwise).

The tool is the language.


Vinzent.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[chris]

Vinzent 'Gadget' Hoefler wrote:
> chris wrote:
> 
> 
>>Assuming it is true that an Ada programmer is 10 times more productive 
>>than a Java programmer, it can only be so assuming *equivalent* tools 
>>are available to do the job at hand and equivalent programming skill (no 
>>point in a comparison otherwise).
> 
> 
> The tool is the language.

No, it's a tool not the tool.  Java has 2D, 3D, Sound, Swing, 
Containers, ... all as part of the platform not the language.  If the 
task at hand involves developing something like an image manipulation 
program Java has tools available to make the job easier, like Java 2D. 
Ada has no such tools so the Java programmer finishes sooner than the 
Ada one and has the opportunity to analyse the program sooner.

It might be comforting to some people that for simple Text IO 
applications, the Ada programmer finishes in 1/10th the time than the 
Java one but I might be writing applications for a set of servers on 
different platforms, need to parse XML from clients, contact 2 different 
DBMS from different vendors and stream media to clients as well as 
interfacing to an accounts system so that's irrelevant to me since it 
doesn't hold for this application and Ada.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Vinzent 'Gadget' Hoefler]

chris wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> chris wrote:
>> 
>>>Assuming it is true that an Ada programmer is 10 times more productive 
>>>than a Java programmer, it can only be so assuming *equivalent* tools 
>>>are available to do the job at hand and equivalent programming skill (no 
>>>point in a comparison otherwise).
>> 
>> The tool is the language.
>
>No, it's a tool not the tool.

Well in my domain it's still the main tool.

>Containers, ... all as part of the platform not the language.  If the 
>task at hand involves developing something like an image manipulation 
>program Java has tools available to make the job easier, like Java 2D.

I am actually doing some sort of image manipulation. :) But it
happens, that all the big Java Libraries aren't useful for this kind
of application.
 
>It might be comforting to some people that for simple Text IO 
>applications, the Ada programmer finishes in 1/10th the time than the 
>Java one but I might be writing applications for a set of servers on 
>different platforms,

That shouldn't be too hard with Ada. It's indeed very portable,
especially when it comes to multi-tasking or even distributed systems.

>need to parse XML from clients, contact 2 different 
>DBMS from different vendors and stream media to clients as well as 
>interfacing to an accounts system so that's irrelevant to me since it 
>doesn't hold for this application and Ada.

Yes. That's certainly true, if you have a big library and you can use
it, it can speed up your development. OTOH it could well be, that all
the time you just saved you will spend with debugging or even
searching for the appropriate library functions... ;)

Don't get me wrong, I'd really like to the Ada Standard Container
Library in the next standard, but anything more than that... 

In fact, you can boil it all down to the famous saying: "Use the right
tool for the job." - If you're putting a GUI together, hell, yes,
stick with Java, Python or whatever. Use LabView if it's appropriate.
Even use C if the job you have to do isn't worth the effort to do it
right the first time. :->

But - and that's just a note for my (and probably other ones)
boss(es), so please don't take it personally, Chris - get used to the
fact that even the so really cool and hyped Java is *not* the right
tool for a _lot_ of jobs. Especially when it comes to the things where
Ada is really good at: real time and embedded applications and systems
with a long life (read: maintenance) time. When it comes to those I'd
say development in Ada outperforms anything I've seen yet.

Sure, it's not too easy to click a crappy GUI together if you want to
do this in Ada, but that sort of development doesn't get a rocket to
fly to the moon, does it?


Vinzent.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[chris]

Vinzent 'Gadget' Hoefler wrote:
> chris wrote:
> 
> Yes. That's certainly true, if you have a big library and you can use
> it, it can speed up your development. OTOH it could well be, that all
> the time you just saved you will spend with debugging or even
> searching for the appropriate library functions... ;)

Maybe but I never find that in Java unless I'm using unfamiliar APIs 
like RMI and I don't develop in Java every day or even every week - 
ditto digging into the ARM for unfamiliar elements.  I'm familiar with a 
lot of languages and use each as appropriate in personal work. 
Otherwise I just get on with it.


> Don't get me wrong, I'd really like to the Ada Standard Container
> Library in the next standard, but anything more than that... 

Which get's revised every ten years.  Such a thing is better revised as 
required.  Lumping it with the standard is a bad idea.


> In fact, you can boil it all down to the famous saying: "Use the right
> tool for the job." - If you're putting a GUI together, hell, yes,
> stick with Java, Python or whatever. Use LabView if it's appropriate.
> Even use C if the job you have to do isn't worth the effort to do it
> right the first time. :->

Of course use the right tool for the right job.  The point is people say 
they want Ada to become more popular and I'm assuming it's on the 
desktop and servers.  All the discussions seem to suggest that.  If it 
isn't then my mistake.  Perhaps people should clarify their intent or 
perhaps stop trying to convince people to use the wrong tool for the job 
  - if Ada is indeed the wrong tool for desktop development; I'm not 
saying it is or isn't.

Marketting to the desktop involves developing applications and tools 
people want to use, not bugging everyone with productivity arguments 
that people largely ignore because they became immune to marketting hype 
of that type when everyone started yelling in the early 90's.  Everyone 
in sw goes on about productivity and it's all subjective, so very few 
educated people listen to it (zealots and managers are a different 
kettle of fish).  They make choices based on others they trusts' 
experience.  There are no examples of desktop sw written in Ada for 
users outside the Ada community, only non-desktop sw in rockets and 
planes.


> But - and that's just a note for my (and probably other ones)
> boss(es), so please don't take it personally, Chris - get used to the
> fact that even the so really cool and hyped Java is *not* the right
> tool for a _lot_ of jobs. 

I never said anything about Java being the right tool for the given 
application, I just said it was a better option because things are 
available for it that are not available in Ada.

Personally I'd write the server side stuff in Erlang and the client side 
stuff in Java.  Indeed that's what I was doing.

Ada wasn't considered for more than a few seconds, not because it wasn't 
a good language, not because I am not familiar with it - the opposite is 
true and Erlang is still a bit unnerving - but because it's too much 
hassle to go around looking for libs and build the missing ones.

I never even said Java was the right tool for any job.  C is not the 
right tool for any job IMO, yet people still use it today.  It's just 
that Java is a better tool than Ada, not because of language details but 
because of it's level of support in the target application area.


 > Especially when it comes to the things where
> Ada is really good at: real time and embedded applications and systems
> with a long life (read: maintenance) time. When it comes to those I'd
> say development in Ada outperforms anything I've seen yet.

And I might use Ada there if that was the area of application at hand. 
I'm largely a desktop developer (with some interest in server 
development), so what does Ada as a package and a language offer me?


> Sure, it's not too easy to click a crappy GUI together if you want to
> do this in Ada, but that sort of development doesn't get a rocket to
> fly to the moon, does it?

No.  Don't be rediculous.  There's a world of difference between putting 
together a crappy GUI and testing for job schedulability in real time 
systems and everything else that goes on in such efforts.  If that's 
your job and Ada is good for that, fine.  It isn't my job - neithers 
plunking together crappy GUIs, any fool can do that (UIs should be the 
domain of UI designers) - and to use Ada makes sense only for a subset 
of the set of applications Ada is suitable for in this area.


Chris

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

O.K., but here is an issue: Most software these days has a GUI and a 
relatively short life. Large, long-lived projects are not nearly as 
numerous. So while I agree with your assessment, I'd observe that Ada is 
aiming to provide help to the smaller market and not offering nearly so 
much help to the larger market.

And then we wonder why Ada isn't as popular. :-)

MDC

Vinzent 'Gadget' Hoefler wrote:
> 
> But - and that's just a note for my (and probably other ones)
> boss(es), so please don't take it personally, Chris - get used to the
> fact that even the so really cool and hyped Java is *not* the right
> tool for a _lot_ of jobs. Especially when it comes to the things where
> Ada is really good at: real time and embedded applications and systems
> with a long life (read: maintenance) time. When it comes to those I'd
> say development in Ada outperforms anything I've seen yet.
> 
> Sure, it's not too easy to click a crappy GUI together if you want to
> do this in Ada, but that sort of development doesn't get a rocket to
> fly to the moon, does it?
> 
> 
> Vinzent.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

I doubt there is any general purpose language applied to relatively 
significant sized projects that is going to be 10 time faster than its 
nearest competitor. If that was a reality, I'd bet everyone developing 
apps would be using it. One might find some fractional improvement from 
just a language - and that's something to talk about - but you're right 
that it would have to be measurable and not just perceptual. One might 
also find that for some narrowly defined problem space one language *is* 
10x faster to develop with, but let's not define the problem so narrowly 
that we get the answer we want rather than reality.

You can never divorce "Language Productivity" from the surrounding task 
and the language environment. Its great to say "Programming in Ada is 
more efficient than programming in Java - all other things being equal". 
One might even be convinced of that by some measured data - SLOCS per 
Fortnight or whatever. But in the real world where we actually have to 
build an end product and sell it, "All Other Things" are NEVER equal. 
Hence, the language with a big library and compatibility with the other 
software it is involved with and the best GUI support and the nicest 
IDE, etc., is always going to win even if it has clunky syntax & 
semantics that mean each SLOC is designed and debugged at a higher cost. 
Write fewer SLOCs and productivity goes up!

MDC


chris wrote:
> 
> Assuming it is true that an Ada programmer is 10 times more productive 
> than a Java programmer, it can only be so assuming *equivalent* tools 
> are available to do the job at hand and equivalent programming skill (no 
> point in a comparison otherwise).  If an Ada programmer can complete the 
> original job in 1/10th the time with the right tools, great!  If otoh 
> they could do it in 1/10th the time if the tools existed but the tools 
> aren't available and you have to spend time creating them what's the 
> productivity gain?  Still 1/10th?



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Warren W. Gay VE3WWG]

chris wrote:
> Wes Groleau wrote:
> 
>> Pascal Obry wrote:
>>
>>> Now I agree that the Ada community is small, lot smaller than the 
>>> Python, Perl
>>> or Java ones... So we just need to work harder :) And we have the 
>>> luck to have
>>> Ada on our side with its great productivity !
>>
>> Ah, but a language that is ten times more productive
>> still can't compete with one that has a hundred times
>> as many developers.

Hiring may be an issue, but I think that point is overstated.

I think a bigger issue in the General Purpose arena is that
Ada so frequently needs bindings that are lacking. Like it or
not, we basically live in a C/C++ world, and any time you have
to stop and write bindings to it, you lose some of the
productivity advantages.

However, it still may be well worth it in the long run, if the
binding SLOC is significantly less than the application code.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Pascal Obry]

Wes Groleau <groleau+news@freeshell.org> writes:

> Ah, but a language that is ten times more productive
> still can't compete with one that has a hundred times
> as many developers.

Let's dream :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Wes Groleau <groleau+news@freeshell.org> wrote:
 
: Ah, but a language that is ten times more productive
: still can't compete with one that has a hundred times
: as many developers.

Hmm... This leaves out the effects emerging from the
number of links in a larger network.
They might grow exponentially, analogous to self-administering
administrations.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert Spooner]

Wes Groleau wrote:

> 
> Ah, but a language that is ten times more productive
> still can't compete with one that has a hundred times
> as many developers.
> 
Let's see... 100*programmers => 100^2*more lines of communication - 
you're right, the project with the huge number of programmers will be 
finished much later, if at all. :)

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Björn Persson]

Robert Spooner wrote:

> Let's see... 100*programmers => 100^2*more lines of communication - 
> you're right, the project with the huge number of programmers will be 
> finished much later, if at all. :)

How many programmers does Linux have? How many does Hurd have? Which 
project is making faster progress?

There must apparently be ways to get around the communication problem.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[chris]

Pascal Obry wrote:

> 
> Fine just do it and release the code as Open Source!

Speaking of which, anyone want a Lua binding?  I reworked the code and 
it's more efficient than last time.  Email me if you do (I don't have 
hosting - no cash, no job and no prospects).


> The problem with the Ada community is that we tend to spend more time saying
> that this and that is missing than to do the job. 

You noticed that too?  I've brought this up before, but it get's drowned 
out in all the reposts of stuff from last months "Let's Market Ada to 
the Masses" thread.  Wait!  That means this message is a repost! :(


 > Who did most of the Perl or Python code out there ?

Perl and Python programmers?  Oh... :)


> Now I agree that the Ada community is small, lot smaller than the Python, Perl
> or Java ones... So we just need to work harder :) And we have the luck to have
> Ada on our side with its great productivity !

But we're programmers!  Being lazy is in our nature. ;)

Sorry.  I always remember an old School teacher who said programmers 
where lazy.  Her point was that programmers don't like to do unnecessary 
work.  That's sort of what this thread is about.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Pascal Obry]

chris <spamoff.danx@ntlworld.com> writes:

> But we're programmers!  Being lazy is in our nature. ;)

Ok.

> Sorry.  I always remember an old School teacher who said programmers where
> lazy.  Her point was that programmers don't like to do unnecessary work.
> That's sort of what this thread is about.

That's not the way I remember it. We must be lazy and reuse whatever already
exits for a specific problem, but we must do the hard work if needed in new
fields...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

David Starner wrote:

> Or I could go with Ada. There's no standard networking code, and no way
> to input UTF-8 - I can't even input it into the basic character type and
> process it, not and stay within the standard. (Of course, that's what
> everyone does.) Worse yet, there's no standard or even existing libraries
> (IIRC) that will normalize Unicode text or sort it in a language dependent
> manner.
> 
> It may be general-purpose, but it doesn't fit this purpose. Given that
> a lot of programs need to access the net and handle the world's languages,
> that's pretty bad.

I think you are confused here.  What operating system are you targeting? 
  And which Ada compiler do you want to use?  As far as Ada is 
concerned, input and output of extended character sets in part depends 
on the underlying OS.  The technical decisions that in standard mode, 
Character = Latin1, Wide_Character = BMP are just decisions about a 
standard default.  RM 3.5.2(4) says: "In a nonstandard mode, an 
implementation may provide other interpretations for the predefined 
types Character and Wide_Character, to conform to local conventions."

If you need an implementation that maps Wide_Character to Unicode 
instead of the BMP, fine.  Personally, I have never needed to go outside 
the BMP. (Klingon anyone?)

As for UTF-8, that is again an implementation specific decision as to 
the external representation of Wide_Character.  If you need software to 
map from Wide_Character to UTF-8 on a system that doesn't normally use 
UTF-8, you can write it if you have to, but there are several 
implementations around.  If the compiler you choose to use doesn't 
support it, you can write your own version of Wide_Text_IO.

Yes, I know you were complaining about having to do that.  But as I see 
it, that is complaining that you choose the wrong compiler, not the 
wrong language.  To make this point explicit, in GNAT 3.15p, there are 
six Wide_Character encodings supported.  A Form parameter of WCEM=8 
specifies UTF-8.  Or you can compile with -gnatW8, which makes UTF-8 the 
default representation.  That doesn't prevent you from using the other 
representations in some files at run-time, it changes the representation 
with no Form string supplied.

So how difficult is it to use UTF-8 in Ada? ;-)

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alan Anderson]

"Robert I. Eachus" <rieachus@comcast.net> wrote

> If you need an implementation that maps Wide_Character to Unicode 
> instead of the BMP, fine.  Personally, I have never needed to go outside 
> the BMP. (Klingon anyone?)

Klingon?  Sure.

http://bologh.blogspot.com/2004_04_04_bologh_archive.html#108125934713287804

http://www.kli.org/QQ/QQ0402.html?mode=UTF

Enjoy.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Alan Anderson wrote:
> "Robert I. Eachus" <rieachus@comcast.net> wrote
> 
> 
>>If you need an implementation that maps Wide_Character to Unicode 
>>instead of the BMP, fine.  Personally, I have never needed to go outside 
>>the BMP. (Klingon anyone?)
> 
> 
> Klingon?  Sure.
> 
> http://bologh.blogspot.com/2004_04_04_bologh_archive.html#108125934713287804
> 
> http://www.kli.org/QQ/QQ0402.html?mode=UTF
> 
> Enjoy.

I think you missed my point.  I think Klingon was the first language to 
be included in Unicode version 3, that is not in the BMP.  There are 
also some Chinese characters that are in the extended (version 3) 
Unicode, but not in the BMP, etc.  But so far I have never needed 
_personally_ to go outside the BMP. _Your_ milage may vary.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Thu, 15 Apr 2004 17:50:29 -0400, Robert I. Eachus wrote:
> I think you missed my point.  I think Klingon was the first language to 
> be included in Unicode version 3, that is not in the BMP.  

I think that ADA is only good for military systems.

Honestly, it would have taken you very little time to check this "fact"
and find out that Klingon is not in Unicode. Do you really appreciate it
when people spout "facts" about Ada that could have been trivially checked
but weren't?

>  But so far I have never needed 
> _personally_ to go outside the BMP. _Your_ milage may vary.

It's not about your needs as a programmer, it's about your user's needs.
If you're writing a program for general distribution, you never know when
someone from Hong Kong will want to IM someone else or when a professor of
ancient languages will want to write a document and include cuneiform. The
world needs partial implementations of Unicode even less than it needs
partial implementations of Ada.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Tue, 13 Apr 2004 10:14:25 -0400, Robert I. Eachus wrote:

> I think you are confused here.  What operating system are you targeting? 
>   And which Ada compiler do you want to use? 

So we can just toss portability out the window. 

> The technical decisions that in standard mode, 
> Character = Latin1, Wide_Character = BMP are just decisions about a 
> standard default.  RM 3.5.2(4) says: "In a nonstandard mode, an 
> implementation may provide other interpretations for the predefined 
> types Character and Wide_Character, to conform to local conventions."

In a nonstandard mode, an implementation may do anything. 

> If you need an implementation that maps Wide_Character to Unicode 
> instead of the BMP, fine.  Personally, I have never needed to go outside 
> the BMP. (Klingon anyone?)

Try Hong Kong Chinese. In any case, I've never needed to use
'Storage_Size, but that doesn't mean that I should go around writing
programs to process Ada code that doesn't support it.

Furthermore, dismissing Unicode outside the BMP as Klingon is offensive
and just plain wrong. There's characters for musical notation, for Linear
A and B, for Gothic, for Aegean numbers, for a Mormon orthography for
English, for Chinese characters for non-Mandarian Chinese or Vietnamese or
archaic Chinese, but no characters for Klingon. In fact, the Unicode
Consortium has specifically said that Klingon is not suitable for encoding
at this time. Let's try dismissing things for technical reasons, instead
of the rumors and falsehoods that have been used so many times against Ada.

> But as I see
> it, that is complaining that you choose the wrong compiler, not the
> wrong language. 

So I can't process plain text, in the modern encoding that the IETF says
every new RFC must support by default, in standard Ada; instead I need to
be tied to one vendor. 

> Or you can compile with -gnatW8, which makes UTF-8 the 
> default representation. 

I've always found this wrong. Information like this should be embedded in
the code, not in the compiler options.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

David Starner wrote:

> Furthermore, dismissing Unicode outside the BMP as Klingon is offensive
> and just plain wrong. There's characters for musical notation, for Linear
> A and B, for Gothic, for Aegean numbers, for a Mormon orthography for
> English, for Chinese characters for non-Mandarian Chinese or Vietnamese or
> archaic Chinese, but no characters for Klingon. In fact, the Unicode
> Consortium has specifically said that Klingon is not suitable for encoding
> at this time. Let's try dismissing things for technical reasons, instead
> of the rumors and falsehoods that have been used so many times against Ada.

I was not "dismissing" Unicode outside of the BMP as useless, I was just 
refering to one part of it.  There is a mapping of Klingon to the 
"private use" area of the BMP, see 
http://www.evertype.com/standards/csur/index.html  There is/was also a 
proposal to move Klingon to plane 1: 
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1643/n1643.htm

As such, I thought Klingon was a good example of a character set where 
"full" Unicode was a nice to have, not a must have.  If JTC1/SC2/WG2 has 
  rejected N1643, that makes my point even more strongly, since the only 
Klingon encoding is the private use registration.

>>Or you can compile with -gnatW8, which makes UTF-8 the 
>>default representation.  
> 
> I've always found this wrong. Information like this should be embedded in
> the code, not in the compiler options.

You CAN imbed use of UTF-8 for Ada.Text_IO files in the form string. 
But -gnatWa (for various values of a) tells the compiler how to 
interpret the character set in the SOURCE file.  That is a little 
difficult to do in the source file itself.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sat, 17 Apr 2004 09:58:09 -0400, Robert I. Eachus wrote:

> I was not "dismissing" Unicode outside of the BMP as useless, 

Referring to Klingon is the standard way of doing that, whether or
not you intended it that way. It ignores the real usages for one that
often inspires ridicule.

> You CAN imbed use of UTF-8 for Ada.Text_IO files in the form string. But
> -gnatWa (for various values of a) tells the compiler how to interpret
> the character set in the SOURCE file.  That is a little difficult to do
> in the source file itself.

Why would you think that? HTML and XML does it. Unless you're dealing with
EBCDIC, you have two encodings to deal with in order to reach a "pragma
charset ("UTF-8");": ASCII and UTF-16, which are trivial to distinguish.

In any case, using it to distinguish source character set isn't evil. It's
using it change the default Text_IO character set, and worse yet, coupling
the two, that's bad.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

David Starner wrote:

> Why would you think that? HTML and XML does it. Unless you're dealing with
> EBCDIC, you have two encodings to deal with in order to reach a "pragma
> charset ("UTF-8");": ASCII and UTF-16, which are trivial to distinguish.

But Shift-JIS and EUC can't be distinguished that way.  More generally, 
with your suggested approach all of the languages must conform to some 
meta-standard.  GNAT on the other hand wants to work with existing 
character sets which may or may not conform to any particular standard.

> In any case, using it to distinguish source character set isn't evil. It's
> using it change the default Text_IO character set, and worse yet, coupling
> the two, that's bad.

Then don't use it.  Again, it is the intended audience.  GNAT tries to 
allow itself to be adapted to any existing environment, including 
character sets.  In say, a Shift-JIS environment, almost all files will 
be written in Shift-JIS.


-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sat, 17 Apr 2004 20:07:32 -0400, Robert I. Eachus wrote:

> David Starner wrote:
> 
>> Why would you think that? HTML and XML does it. Unless you're dealing with
>> EBCDIC, you have two encodings to deal with in order to reach a "pragma
>> charset ("UTF-8");": ASCII and UTF-16, which are trivial to distinguish.
> 
> But Shift-JIS and EUC can't be distinguished that way. 

Sure they can. Shift-JIS and EUC just look like ASCII until you start
sticking in non-ASCII characters. If you put the pragma charset
("Shift-JIS"); before any Japanese characters, the compiler will have no
problem reading it. Again this is how HTML does it; do you really need
more variety of character sets in source code than HTML or XML?

> Then don't use it.  Again, it is the intended audience.  GNAT tries to
> allow itself to be adapted to any existing environment, including
> character sets.  In say, a Shift-JIS environment, almost all files will
> be written in Shift-JIS.

I maintain one Ada program for open distribution. I don't know whether the
users are using it in a EUC-JIS environment or ISO-8859-1 environment or
KOI8-R environment or a UTF-8 environment. Almost any program suitable for
distribution with a Linux distribution is going to have to accept that as
reality and react appropriately. (I personally deal with nothing more
complex than filenames, and hence escape most of the pain.)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

David Starner wrote:

> Sure they can. Shift-JIS and EUC just look like ASCII until you start
> sticking in non-ASCII characters. If you put the pragma charset
> ("Shift-JIS"); before any Japanese characters, the compiler will have no
> problem reading it. Again this is how HTML does it; do you really need
> more variety of character sets in source code than HTML or XML?

The if above is the problem.  Sure, IF you are willing to impose some 
discipline on the source files at a meta-level, you can deal with this. 
  But as I said, GNAT wants to be able to accept EXISTING files.

So as I said, if you want to specify the character set in the source, 
fine.  GNAT supports that (although I prefer to specify the character 
set for a library as a whole, also supported).  But if you have files 
which were originally targeted at some non-GNAT environment, GNAT wants 
to make it possible to use them WITHOUT modification.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Yes, that's probably a more accurate characterization. But if Sun Java 
is essentially equal to "Java" (I don't know about any other major 
implementations) then - as a language - the libraries are essentially 
part of it. People tend to ignore any distinction between a "Language 
Standard" and whatever they get with their compiler. In the absence of a 
competing implementation, for any practical purposes, the compiler *is* 
the standard.

Ada would be in the same ballpark if, for example, Gnat were the only 
compiler out there with any significant user base. Then the Gnat 
libraries would effectively be "part of the language" and anyone using 
Ada would likely be familiar with them and could count on their presence 
anywhere that Ada was in use. But clearly, that is not the case.

MDC

James Rogers wrote:
> 
> I would rephrase that. Java standard libraries do not exist due to the 
> intrinsic nature of the Java language. They exist because Sun Microsystems
> has poured millions of dollars into the development of Java standard
> libraries.
> 
> While Java is a very useful tool, it is good to remember that Java is
> owned by Sun. It is a proprietary product. Just ask Microsoft, who
> recently paid Sun $700,000,000.00 in the settlement of a lawsuit
> regarding Java.
> 
> Jim Rogers


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[James Rogers]

Marin David Condic <nobody@noplace.com> wrote in
news:406EE6EB.8040507@noplace.com: 

> Yes, that's probably a more accurate characterization. But if Sun Java
> is essentially equal to "Java" (I don't know about any other major 
> implementations) then - as a language - the libraries are essentially 
> part of it. People tend to ignore any distinction between a "Language 
> Standard" and whatever they get with their compiler. In the absence of
> a competing implementation, for any practical purposes, the compiler
> *is* the standard.

There are no other major vendors. Microsoft tried making their
own implementation and suffered a lawsuit from Sun. The Microsoft
response was C#, which looks and smells a lot like Java but is being
marketed as a different language.

Sun provides several different and somewhat incompatible versions of
Java. There are Java Standard Edition, Enterprise Java, Real Time Java,
and Java Micro-Edition. The major difference between these versions is
the accompanying library set. The core Java language remains the same.
This is similar to different Ada compilers providing different sets of
optional annexes.

When managers decide to use Java they seldom recognize the differences
between the various versions. Sun provides the different development 
tools at no cost to the managers. Of course, there is a learning curve
for dealing with the different libraries, but that is seldom acknowledged
by managers.

Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Wes Groleau]

James Rogers wrote:
> There are no other major vendors. Microsoft tried making their
> own implementation and suffered a lawsuit from Sun. The Microsoft
> response was C#, which looks and smells a lot like Java but is being
> marketed as a different language.

According to comments I've seen on this newsgroup, C#
_IS_ a different language.  In fact, at least one of
those comments claimed it is a better language than Java,
at least from the viewpoint of the type of person who
likes Ada.

-- 
Wes Groleau

   A bureaucrat is someone who cuts red tape lengthwise.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Fundamentally no different than having to learn about different Ada 
compilers with different libraries. There's seldom a zero-cost 
transition from one domain to another. Even with the same toolset on two 
different projects, you'll have a transition cost. That's not a language 
issue.

MDC

James Rogers wrote:
> 
> When managers decide to use Java they seldom recognize the differences
> between the various versions. Sun provides the different development 
> tools at no cost to the managers. Of course, there is a learning curve
> for dealing with the different libraries, but that is seldom acknowledged
> by managers.
> 
> Jim Rogers


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

MSG wrote:

> Ludovic Brenta <ludovic.brenta@insalien.org> wrote in message
> news:<m3isij11u4.fsf_-_@insalien.org>...
> 
> [...]
> 
>> The "zen master" languages are Pascal, Modula,
>> Oberon, and, master of masters, Ada.  The beauty of these languages is
>> that, once you are Enlightened, you can apply your wisdom to other
>> languages as well -- but often would prefer not to.
> 
> 
> Can you do the following in Ada:
> 
> 1. Write *one* bubble-sort function that will work on different
>    types given an appropriate comparison function

Shure you can. Ada invented templates long bevore C++ was even though of.
Ada templates are far more powerfull then C++.

> 2. If B is a subtype of A, can you pass it to any function that
>    takes A as an argument? (covariance)

subtype as in object orientation:

type Parent is tagged null record;
type Child is new Parent with null record;

or subtype as in simple types:

type Day_of_Month is range 1 ..  31;
subtype Day_of_Febuary is Day_of_Month range 1 .. 29;

Well, the answer is yes in both cases.

> 3. If B is a subtype of A, and FA and FB are functions accepting A
>    and B as arguments, can you use FA wherever FB could be used?
>    (contravariance)

Of corse.
 
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.

Others did that allready. Besides, you would need an installed Ada compiler
to verify anyway.
 
> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> letting on about why Ada isn't used much at NASA any more.

He also won't tell you why Spirit died.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Josh Sebastian]

On Sun, 08 Feb 2004 14:05:53 +0100, Martin Krischik wrote:

> MSG wrote:
> 
>> Can you do the following in Ada:
>> 
>> 1. Write *one* bubble-sort function that will work on different
>>    types given an appropriate comparison function
> 
> Shure you can. Ada invented templates long bevore C++ was even though of.

Factoid: Alex Stepanov started off his research that led to the STL in Ada.

> Ada templates are far more powerfull then C++.

Why do you say that? I haven't used Ada terribly much, but from what I
remember, I don't think Ada generics are Turing-complete, which C++
templates are.

Josh

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Krischik]

Josh Sebastian wrote:

> On Sun, 08 Feb 2004 14:05:53 +0100, Martin Krischik wrote:
> 
>> MSG wrote:
>> 
>>> Can you do the following in Ada:
>>> 
>>> 1. Write *one* bubble-sort function that will work on different
>>>    types given an appropriate comparison function
>> 
>> Shure you can. Ada invented templates long bevore C++ was even though of.
> 
> Factoid: Alex Stepanov started off his research that led to the STL in
> Ada.

I am not quite shure what you want to say. As far as I know generics had
been part of Ada 83. But of course without some STL.

>> Ada templates are far more powerfull then C++.
> 
> Why do you say that? I haven't used Ada terribly much, but from what I
> remember, I don't think Ada generics are Turing-complete, which C++
> templates are.

Well I have used C++ for 10 years and Ada for just 1 year - I can express my
will better with Ada generics then with C++ templates.

With Regards


Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Josh Sebastian]

On Sun, 08 Feb 2004 19:02:02 +0100, Martin Krischik wrote:

> Josh Sebastian wrote:
> 
>> On Sun, 08 Feb 2004 14:05:53 +0100, Martin Krischik wrote:
>> 
>> Factoid: Alex Stepanov started off his research that led to the STL in
>> Ada.
> 
> I am not quite shure what you want to say.

I was saying that the STL started off in Ada before it was moved to (and
completed in) C++. I wasn't disagreeing with you (yet :).

>>> Ada templates are far more powerfull then C++.
>> 
>> Why do you say that? I haven't used Ada terribly much, but from what I
>> remember, I don't think Ada generics are Turing-complete, which C++
>> templates are.
> 
> Well I have used C++ for 10 years and Ada for just 1 year - I can express my
> will better with Ada generics then with C++ templates.

Maybe you just weren't very good at C++ templates. I don't mean to be
insulting, but personal preferences do play a huge roll here. Unless
someone can prove Ada's generics are Turing-complete, though (a quick
google doesn't turn up anything), I'd say that we'll have to call C++
templates more powerful.

Josh

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Ambuhl]

Josh Sebastian and Martin Krischik are continuing their silly language 
advocacy.
Perhaps comp.lang.ada cares about the preference of one for Ada;
perhaps comp.lang.c++.  Who knows what the people in comp.lang.java care 
about?  I know for damn sure that comp.lang.c is not the place for your 
silly discussion of Ada vs. C++.
I have set follow-ups to comp.lang.ada and comp.lang.c++.  Even that might 
be too much.  In any event, take comp.lang.c off any future exchanges you 
idiots have.  Even better: take it to e-mail.



-- 
Martin Ambuhl

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

Language advocacy can be an entertaining activity on a cold winter's
evening,
but even the most ardent enthusiasts for one language or another will
eventually
admit that languages are nothing more than tools for composing computer
programs.   The good craftsperson selects the appropriate tool for the job
at hand.

During my forty-plus year career I have had to use a variety of different
programming languages.  In some cases I have had to construct fairly
large programs.  Other times, my programs were small parts of much
larger systems.

During the past four years (actually longer if I count preparation time), I
have
had to put to use, engage, and confront several newer language offerings. Of
these new offerings, I rather like some aspects of Ruby, some ideas in C#,
and have gained a new level of respect for certain functional languages.

Still, each of these new languages is a tool.   My responsibility, as a
computer
software practitioner, is to understand when to pick the right tool for the
right
job.  On a large-scale project, I must realize that several different
languages
might be required.   Also, some people will be more skilled with one
language
than another or some pre-existing code might be better suited to the
solution
than brand-new code in the latest whiz-bang language.

Under some circumstances, C++ is a perfectly appropriate choice. It is no
better than Ada for these circumstances, but it is acceptable.   In some
other
set of circumstances, Ada is a perfectly good choice.  Again, it is no
better
than C++, but works out just fine.

There are still other problems where language choice does matter.   For
programming
an small microcomputer (e.g. I-8051) C is almost always a better choice than
either Ada or C++.   For large, mainframe data processing systems, modern
COBOL
(Yes, COBOL has been modernized) is probably a better choice.    The worst
possible choice for those mainframe systems is probably C++, but lots of
irresponsible
software managers are allowing such code to disrupt their development cycle.

For windows  (MS) programming, C++ still has some edge over Ada simply
because it is
more closely associated with the MS programming libraries.  However, I have
been involved
in a least one significant project where Ada proved more portable across
more kinds of
windows environments than C++.

We select Ada when dependability is an issue.   A clear requirement of safe
software is
that of predictability.   C++ is well-known to be the source of much that is
unpredictable.
We certainly do not want to use tools with inherent unpredicatbility in the
creation of
predictable, deterministic software solutions.   In such cases, Ada is the
correct tool.
Some might suggest that Eiffel also fits that description.   The language
definition for
Eiffel probably does.  One needs to examine implementations to determine
whether
the result will involve complete predictability.

Meanwhile,  SQL remains useful.   Visual Basic is a good tool for those
applications
that lend themselves to such solutions.   Java is good for a limited range
of things, but
is used for more things than it is good for.   C++ continues to have much to
recommend it.

People do not select their programming tools as wisely as they select their
carpentry
tools.  Usually, someone learns a language and sticks with it they way some
people
stick with the same religion into which they were born, or the same
political party
into which they were born.

The religiofication of language arguments leads nowhere.   Reasonable people
must understand
that languages are designed by people, and every language is flawed in one
way or another.  We
must admit the flaws in our preferred language before the other fellow will
admit the flaws in
his/her preferred language.  As we do so, we might just come up with some
ideas for the next
improved language rather than remain paralyzed with the our current
favorite.

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Richard Riehle wrote:

> Language advocacy can be an entertaining activity on a cold winter's
> evening, but even the most ardent enthusiasts for one language or another
> will eventually admit that languages are nothing more than tools for
> composing computer programs.   The good craftsperson selects the
> appropriate tool for the job at hand.

Not really.  Programming languages are also tools for thinking.  And 
different languages favor different ways of thinking.  This effect can 
also be seen in spoken languages you can't understand the French and the 
people of Quebec unless you can think in French.  (I am the first to 
admit I can't.  I can try, but I find the exercise very strenuous.  I 
need to literally accept a foreign viewpoint to do it well and I am 
unwilling to do so.  The cultural baggage with Arabic and Chinese is 
larger that that which comes with French, but it isn't as imperialistic.

Japanese on the other hand, is much more demanding than French,  but in 
another sense it is not as hard.  Japanese requires you to act in 
certain ways, but it doesn't try as hard to impose its worldview on you. 
  However, the worldview that comes with Japanese is pretty nasty. 
Note, this does not say that Japanese are nasty. However, I have found 
that there is a huge difference in world view between those Japanese who 
speak English and those who don't, I don't know if this holds true for 
those who speak only another Asian as opposed to European language.  I 
haven't studied Russian in decades, but I remember it as being like the 
Germanic langauges.  They do fit your discription above.  They are tools 
and can be used in many different ways.

> ...The religiofication of language arguments leads nowhere.   Reasonable
> people must understand that languages are designed by people, and every
> language is flawed in one way or another.  We must admit the flaws in our
> preferred language before the other fellow will admit the flaws in
> his/her preferred language.  As we do so, we might just come up with some
> ideas for the next improved language rather than remain paralyzed with
> the our current favorite.

I don't disagree, but I am going to draw a very different parallel with 
religion.  In the sermon this Sunday, our minister who worked in 
marketing for decades before going to seminary, drew an interesting 
comparison between "the church" and corporations.  He was talking about 
how corporate structures were designed to be conservative, in the sense 
that they are designed to preserve and enhance the corporation. 
Products and customers, while important, are secondary.  I corporation 
can switch products or switch products, if necessary for the survival of 
the company.

The church is different.  We can't walk away from the message and we 
really are failing if we chose to target a particular market.  It may be 
a good strategy for the short term survival of the organization, but at 
the same time we can't tailor the message to a particular market.  (We 
can package the message differently--but that is starting to get away 
from the point I would like to make.)

So on one hand we have the church organization, and there is a strong 
tendancy to make it as comfortable as possible for "our kind of 
Christian."  As I said above, nothing wrong with that if it is confined 
to packaging--the way the building is decorated, which hymns we sing, 
even the scheduled time for the Sunday service.  But we can't lose sight 
of the important fundamentals that can't be changed if we still want to 
be Christians.  (And again the doctrinal differences between various 
denominations are way off topic here.  But the parallels in programming 
languages are on topic in the next paragraph. ;-)

So we have three levels of competing priorities, and it is the job of 
the Elders to insure that we get those priorities straight.  The rest of 
the sermon was about the fundamental conservative nature of any 
organization such as a church, and the revolutionary nature to religion 
as such.

We have similar levels in programming languages and a similar problem 
with organizational conservatism.  Notice that there is a need for 
conservatism that can't be ignored.  Fixing the roof may not be the 
primary mission of the church.  On the other hand having the building 
collapse and kill half the congregation is not acceptable.

In the programming language arena, there are three groups of 
"stakeholders."  There are those whose responsibility is to keep the 
language consistant and usable.  There are also current users who don't 
want to be forced to learn new features.  Finally there are the language 
evangelists, who want to use the language in new market segments, and 
think that the language would be perfect if the langauge maintainers 
would only add a few dozen small changes. ;-)

In programming languages the ultra-conservative role of church doctrine 
is the job of the language lawyers.  Any major programming language has 
a maintenance organization which is by nature very conservative, and 
with good reason.  If (in the case of Ada) the ARG doesn't do its job 
right, the result is not just a loss of users.  Languages can be made 
unsuitable for their current role, and the result is usually something 
similar to a religous schism.

A perfect example of this was Algol 68.  It was a huge change from Algol 
60, and the net result was a schism.  Wirth put his alternate proposal 
"on the table" Algol-W, and a large portion of the current Algol 60 
users switched to Algol-W and then to Pascal.  Algol 68 was a nice 
language once decent documentation existed, and several good compilers 
were eventually available.  But the programmers who wanted to use Algol 
68 included very few Algol 60 programmers.

On the other hand if the ARG doesn't keep the language "relevant," 
eventually the user community will wither away to nothing.  The Ada 
community is currently growing, but not nearly as fast as the overall 
demand for programmers.  (I should say as fast as the overall demand for 
software engineers, but let's keep to one religious war at a time.)

I think that the ARG is maintaining the correct balance.  Those who 
don't want change are not screaming about the proposed changes in Ada 
0Y, and the evangelists are not satisified, but it is their nature to be 
unsatisfied.

There will always be those who are unwilling or unable to tolerate the 
almost glacial pace of change.  Fine.  For those people there are 
boutique languages and languages du joir.  And I am not denigrating that 
need.  There have been several projects I worked on where we developed 
project specific languages.  But the toolset we used were based on an 
existing major production language, with a set of translation tools for 
the modified language.

One good example of a language that started out that way was C++. 
Another was Object Ada which added object oriented features to Ada 83. 
Object Ada was made obsolete by Ada 95, but C++ is now a separate 
language development tree from C.  (And it will stay that way.  The 
market for C is now different enough from the market for C++ as to be 
almost disjoint.)  Of course for every seed that finds nourishing soil 
and grows, hundreds of others fall on barren ground.

But the language evangilists want someone else to do the job of 
developing their concept of a perfect language for them.  It can never 
happen.  If they learn how to use the tools, they can develop your own 
language and do all the maintenance themselves.  Or if they win the 
Powerball lottery, they may be able to hire someone to do it for them.

But otherwise it is just a huge job.  My guess is that just the Ada 0Y 
changes including proposals and reviews will be on the order of a man 
century of work. If you want to argue that it is only a couple of man 
decades, I hear you and don't.  You have to count the effort by current 
langauge users to learn the changes, the compiler developers who have to 
modify their compilers, the textbook authors who have to update their 
texts, and so on.  Yes, at the core of all this, between the ARG and 
WG9, there are several dozen people who average less than three months a 
year working on standards related issues.

However, we can't forget that any changes we agree to will eventually 
have a much larger effect on the Ada community as a whole.  That is in 
part what makes the organizational parts of the Ada community so 
conservative.  Of course, if there is a bug in the current standard, and 
different compilers do different things, then we don't need to be 
conservative, and we aren't.  We might as well choose whatever is best 
in the long run for the Ada community, because the "extra" effort to 
understand the problems and the fix is going to have to be spent in any 
case.

So if you want Ada to change, be patient.  However, if you want any 
changes which make the language unacceptable to its current users, 
forget it.  If you identify a new need that can't be satisifed by any 
version of Ada which satisfies current users, go off and do your own 
thing.  (Or for that matter a new version of C++, C, Pascal or COBOL.)

It won't be the first time.  Some such efforts have been drawn back into 
the fold, like Object Ada.  Others such as VHDL and SPARK identified a 
market that was sufficiently different so that the right solution was to 
develop separate tool chains.  (SPARCK is a "pure" Ada subset, so it can 
be compiled by normal Ada compilers.  But you also have to run the 
source through the SPARK Examiner to have correct SPARK code.)

And I am not trying to "blow off" reasonable extension proposals.  I am 
just trying to describe the sort of thinking we go through before making 
ANY language change.  If you just make a three paragraph recommendation 
of an idea that looks identical to one that was worked out in minute 
detail by the ARG and rejected by WG9, don't be surprised when we say it 
won't fly, and don't want to go into details.  The details may involve 
dozens to hundreds of hours (and pages) of discussions.  (You can 
usually find them at www.ada-auth.org  and if you aren't willing to read 
what is there, thoroughly, you can see why I and other ARG members 
sometimes get frustrated.



-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> > ... languages are nothing more than tools for
> > composing computer programs.   The good craftsperson selects the
> > appropriate tool for the job at hand.
>
> Not really.  Programming languages are also tools for thinking.  And 
> different languages favor different ways of thinking.

Yes. And they provide a multitude of convenient patterns for those favored
ways.

> This effect can 
> also be seen in spoken languages you can't understand the French and the 
> people of Quebec unless you can think in French.  (I am the first to 
> admit I can't.  I can try, but I find the exercise very strenuous.  I 
> need to literally accept a foreign viewpoint to do it well and I am 
> unwilling to do so.

Actually you need not *accept* that foreign viewpoint as a "proper" or "true"
one for you, but you should become aware of its essense and its relationships
with various facts, events, doctrines etc. And yes, you need to admit that
that viewpoint is viable and somehow appropriate for its native environment
and circumstances. No more than that. That should not be destructive for your
own worldview... if you don't think that the latter is definitely better than
all others and therefore should be propagated everywhere and dominate over all
those inferior others.

By the way, nowadays the English language is very interesting in this
aspect - because there is a clear choice between two possible viewpoints for
this language: American and British (in alphabetical order -:) . These are
certainly different viewpoints, and a learner has to choose between them.

> The cultural baggage with Arabic and Chinese is 
> larger that that which comes with French, but it isn't as imperialistic.

This sentence seems quite strange... well, not exactly. I can't believe that
you know so much about Arabic or Chinese culture that you can estimate whether
or not it is imperialistic. After all, most of their cultural baggages (which
are large, as you said) were created during their corresponding Imperial ages.
Not knowing French (as you said) you certainly can't judge French cultural
baggade in this aspect as well. But you did that, and there is a clear cause
for that - you see French as the most important center of resistance against
worldwide propagation of American viewpoint. Well, I think that this feeling
is quite correct, and this is why recently I gradually become interested in
learning French (there are, and always were other reasons of course, but this
new additional one has a chance to be decisive).

> Japanese on the other hand, is much more demanding than French,  but in 
> another sense it is not as hard.  Japanese requires you to act in 
> certain ways, but it doesn't try as hard to impose its worldview on you. 
>...
> However, I have found 
> that there is a huge difference in world view between those Japanese who 
> speak English and those who don't,

This passage about Japanese vividly reminds me the following anecdote:

----------
A Pan Am 727 flight engineer waiting for start clearance in Munich overheard
the following:

Lufthansa (in German): Ground, what is our start clearance time?"

Ground (in English): "If you want an answer you must speak English."

Lufthansa (in English): "I am a German, flying a German airplane, in Germany.
Why must I speak English?"

Unknown voice (in a beautiful British accent): "Because you lost the bloody
war!"
----------

> I haven't studied Russian in decades, but I remember it as being like the 
> Germanic langauges.  They do fit your discription above.  They are tools 
> and can be used in many different ways.

I can't speak for Germanic languages, but for Russian I tend to agree. Yes,
I don't think that Russian, as a language, is substantially associated with
any specific viewpoint. (But its Soviet flavour certainly was... I hope it is
obvious.)

But just one external observation about Germanic languages: although it may
be true that the whole family of Germanic languages isn't substantially
associated with any particular viewpoint, this seems to be false for one
particular area, and the corresponding language flavour: Austria. It seems
that there, in Austria, some coherent viewpoint was present (I don't know
whether it is still alive).




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

I said:
>>This effect can 
>>also be seen in spoken languages you can't understand the French and the 
>>people of Quebec unless you can think in French.  (I am the first to 
>>admit I can't.  I can try, but I find the exercise very strenuous.  I 
>>need to literally accept a foreign viewpoint to do it well and I am 
>>unwilling to do so.

>>The cultural baggage with Arabic and Chinese is 
>>larger that that which comes with French, but it isn't as imperialistic.

> 
> This sentence seems quite strange... well, not exactly. I can't believe that
> you know so much about Arabic or Chinese culture that you can estimate whether
> or not it is imperialistic. After all, most of their cultural baggages (which
> are large, as you said) were created during their corresponding Imperial ages.
> Not knowing French (as you said) you certainly can't judge French cultural
> baggade in this aspect as well. But you did that, and there is a clear cause
> for that - you see French as the most important center of resistance against
> worldwide propagation of American viewpoint. Well, I think that this feeling
> is quite correct, and this is why recently I gradually become interested in
> learning French (there are, and always were other reasons of course, but this
> new additional one has a chance to be decisive).

I think you misunderstood.  I speak French well enough to get along, in 
both Paris and Quebec--although my accent is hardly Parisian.  But I 
can't fit my thoughts inside the language imposed worldview.  So when I 
am speaking French I am thinking in English then translating.  (I don't 
have to go through that step when listening.)  It has been awhile since 
I studied Chinese, long enough that the new transliterations still seem 
strange.  And I suspect I would feel more at home in Taiwan than 
mainland China.

>>Japanese on the other hand, is much more demanding than French,  but in 
>>another sense it is not as hard.  Japanese requires you to act in 
>>certain ways, but it doesn't try as hard to impose its worldview on you. 
>>...
>>However, I have found 
>>that there is a huge difference in world view between those Japanese who 
>>speak English and those who don't,
> 
> This passage about Japanese vividly reminds me the following anecdote:
> 
> ----------
> A Pan Am 727 flight engineer waiting for start clearance in Munich overheard
> the following:
> 
> Lufthansa (in German): Ground, what is our start clearance time?"
> 
> Ground (in English): "If you want an answer you must speak English."
> 
> Lufthansa (in English): "I am a German, flying a German airplane, in Germany.
> Why must I speak English?"
> 
> Unknown voice (in a beautiful British accent): "Because you lost the bloody
> war!"

And the French pretend they were on the winning side, rather than losing 
early, being occupied for years, and then liberated by the Allies. ;-) 
In fact in French, it is hard to think of French military history as 
other than glorious.

> I can't speak for Germanic languages, but for Russian I tend to agree. Yes,
> I don't think that Russian, as a language, is substantially associated with
> any specific viewpoint. (But its Soviet flavour certainly was... I hope it is
> obvious.)
> 
> But just one external observation about Germanic languages: although it may
> be true that the whole family of Germanic languages isn't substantially
> associated with any particular viewpoint, this seems to be false for one
> particular area, and the corresponding language flavour: Austria. It seems
> that there, in Austria, some coherent viewpoint was present (I don't know
> whether it is still alive).

Sure in Austria there is a consistent world view:  Austrian beer is 
better than any other beer, including German. ;-)  Seriously the 
Austrian culture is very relaxed compared to northern Germany.  But I 
spent a couple years in Bavaria, and the culture there seemed very 
similar to Austria.  (In fact, I think that southern German is still 
more religious and fun loving than Austria, but compared to northern 
Germany, the difference is relatively minor.)

All this is sort of very off topic for this newsgroup, with one 
exception.  The languages that we discussed as not imposing world views 
seem to be required learning at a young age (usually as a "milk tongue") 
to be any good at building compilers and designing programming 
languages.  (There are some excellent language designers in France, but 
they all seem to speak fluent English.  So it may be that if French is 
your milk tongue you can learn another language later, and still commit 
language design.)  I have often felt that this was due to some spoken 
languages being easily extensible, and others forcing you into another 
language if you want to add a new concept.  The two extremes seem to be 
English and Japanese.

All popular programming languages seem to have an English heritage.  In 
fact it is almost surprising that there are a few languages with more of 
a British background than American.  (Algol, especially Algol 68, and 
Coral 66 come to mind.)  There have been a few German and Russian 
programming languages, but none has made it into the mainstream.  There 
have been a few languages from non-English speaking areas.  SIMSCRIPT 
has a Scandinavian heritage.  However, it is hard to contend that 
English is not the primary language in some areas of Scandinavia. Wirth 
who designed Pascal and Algol-W among other languages, was Dutch.  But 
all those languages have a clear English heritage (and documentation).

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:

: Seriously the 
: Austrian culture is very relaxed compared to northern Germany.

Interesting that you see it this way. There are many
who say it is the other way.

:   (In fact, I think that southern German is still 
: more religious and fun loving than Austria, but compared to northern 
: Germany, the difference is relatively minor.)

Just a different sort of humor (and religious history).


: All this is sort of very off topic for this newsgroup,

as is probably the assumption that "The Protestant Ethic and the
Spirit of Capitalism" (articulately present in Bill Gates and
co-workers) might have to do with inventing computer languages
and tools, directly or indirectly :-)


: Wirth 
: who designed Pascal and Algol-W among other languages, was Dutch.

(Uhm, he seems to be from Winterthur in Switzerland. Though Dijkstra was
from the Netherlands.)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> I speak French well enough to get along, in 
> both Paris and Quebec--although my accent is hardly Parisian.  But I 
> can't fit my thoughts inside the language imposed worldview.  So when I 
> am speaking French I am thinking in English then translating.  (I don't 
> have to go through that step when listening.)

I think that there must be some *right French for you*, which you
just did not find. First, I believe that you'll agree that Cartesian
coordinate system is distinctly French (extremely imperialistic -:) ,
and at the same time very good thing. Second, take a book - a
collection of famous speeches given in court by French advocates near
1900. Third, read "War Pilot" (or "Military Pilot" - I don't know its
title in English translation, I read it in Russian) by Saint-Exupery.
And finally read memoirs of Grothendieck (it isn't easy to obtain, but
possible - in French... there is Russian translation, but perhaps
still no English translation). I guess that this package will create
a glimpse of worldview, which is certainly French and at the same time
acceptable for you.

> It has been awhile since 
> I studied Chinese, long enough that the new transliterations still seem 
> strange.  And I suspect I would feel more at home in Taiwan than 
> mainland China.

I guess that the difference between Traditional and Simplified Chinese
would not be the most significant reason for that your feeling -:)

> And the French pretend they were on the winning side, rather than losing 
> early, being occupied for years, and then liberated by the Allies. ;-) 

Well, I must confess that this situation annoyed me for a couple of
decades -:) . But then I realized that taking a physisist's viewpoint,
I must admit that the French actually were among winners - this is a
fact, a primary fact, and all the theories and reasons are secondary.
But nevertheless we need a theory, a reason - so I managed to produce
one: despite all their losing and occupation, French appear *ready*,
immediately ready to carry all the banners and duties of a winner.
I hope you agree that it isn't easy and simple for a war loser, for
an recently occupied country to behave correctly as a true winner -
and French did that succesfully. So I concluded that there was a sense
in admitting French into the company of winners - not because they
significantly contributed to the victory, but because they were able
to carry a share in post-war matters as a winner.

> In fact in French, it is hard to think of French military history as 
> other than glorious.

Do you know a big country, in which own military history isn't
glorious? -:)

> All this is sort of very off topic for this newsgroup, with one 
> exception.  The languages that we discussed as not imposing world views 
> seem to be required learning at a young age (usually as a "milk tongue") 
> to be any good at building compilers and designing programming 
> languages.  (There are some excellent language designers in France, but 
> they all seem to speak fluent English.  So it may be that if French is 
> your milk tongue you can learn another language later, and still commit 
> language design.)  I have often felt that this was due to some spoken 
> languages being easily extensible, and others forcing you into another 
> language if you want to add a new concept.  The two extremes seem to be 
> English and Japanese.

I tend to agree, but with one addition: those coming from other
languages (which have a "fixed worldview) may convey elements of their
"native" worldview to the whole construction, and this may be very
important, even critical for overall success.

> All popular programming languages seem to have an English heritage.

It coudn't be othewise simply because of the weight of American
computer industry and American market.

> There 
> have been a few languages from non-English speaking areas.  SIMSCRIPT 
> has a Scandinavian heritage.

It is somehow strange that you did not mention Simula-67 here.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Robert I. Eachus wrote:

> Do you know a big country, in which own military history isn't
> glorious? -:)

France of course, but not in French.  Do you know of any other country 
where the man touted as the most brilliant General (Napolean) is more 
famous for his losses than his victories.  (Waterloo and the retreat 
from Moscow.)

To be fair, there have been many Generals who showed their true mettle 
when the chips were down, and that tends to happen in close battles.

>>There 
>>have been a few languages from non-English speaking areas.  SIMSCRIPT 
>>has a Scandinavian heritage.
> 
> It is somehow strange that you did not mention Simula-67 here.

Oops! You are right.  And I also mixed up Wirth and Dijkstra.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> > Do you know a big country, in which own military history isn't 
> > glorious? -:)
>
> France of course, but not in French.

As I can see (having read several books somehow related to France's war history),
American view (perhaps English view too, but I don't know) on this matter is
quite interesting: in short summary, beginning from 12 century France almost
never win a war, it always either lost or just managed to save pre-war status
at the end (one exception is WW1, but the decisive factor there was American
intervention in the final stage of the war, so it was actually more American
then French victory - France alone would lose as usual). And with all that,
France somehow managed to maintain continuously her state, character, morale,
language, and her status of one of the most important intellectual and artistic
centers of the world. One can conclude that all those defeats were somehow
incomplete... 

> Do you know of any other country 
> where the man touted as the most brilliant General (Napolean) is more 
> famous for his losses than his victories.  (Waterloo and the retreat 
> from Moscow.)

Well, here in Russia we know about Napoleon's retreat from Moscow quite well -:) .
But we also know that that was very big achievement - to reach Moscow (without
tanks, railways and even cars). And before Moscow and Waterloo he had many
victories - in fact he won several local wars. He certainly was brilliant
general of his time, and his errors in war with Russia weren't military errors,
they were geopolitical errors... but those errors seem unavoidable for a 
brilliant and successful general who became Emperor (and those who wish Ada
to become Great Mainstream Language can take a lesson from this old story -:) .

But if you still need "another country" - try to look at Sweden (I heard not
once that most revered Swedish king is exactly that who lost war with Russia
and brought Sweden many losses, including important territorial losses).




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Fri, 13 Feb 2004 17:47:36 -0500, Robert I. Eachus wrote:
> 
> France of course, but not in French.  Do you know of any other country 
> where the man touted as the most brilliant General (Napolean) is more 
> famous for his losses than his victories.  

Of course, Russian peasants were telling a story a hundred years later
where Napoleonder was a creation of the Devil and, after the enemy killed
his army, he could raise them as undead by saying his name. It wasn't
merely the French who were impressed with Napoleon.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Tarjei T. Jensen]

Robert I. Eachus wrote:
> France of course, but not in French.  Do you know of any other country
> where the man touted as the most brilliant General (Napolean) is more
> famous for his losses than his victories.  (Waterloo and the retreat
> from Moscow.)

I think you confuse matters here. He became famous for his victories. He may
be best known in English speaking countries for Waterloo and the retreat
from Moscow.

Think of it, the French squeezed out the English from France, but the famous
battles in English speaking countries are the ones the English won. Once the
French armoured their infantry the game was over for the English.

greetings,

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Reivilo Snuved]

"Robert I. Eachus" <rieachus@comcast.net> writes:

[snip]

> In fact in French, it is hard to think of French military history as 
> other than glorious.

You might be attaching more "baggage" to the language than is really 
necessary here.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:YaWdncfnQoOFHrXd4p2dnA@comcast.com...
> Richard Riehle wrote:
>
> > Language advocacy can be an entertaining activity on a cold winter's
> > evening, but even the most ardent enthusiasts for one language or
another
> > will eventually admit that languages are nothing more than tools for
> > composing computer programs.   The good craftsperson selects the
> > appropriate tool for the job at hand.
>
> Not really.  Programming languages are also tools for thinking.  And
> different languages favor different ways of thinking.  This effect can
> also be seen in spoken languages you can't understand the French and the
> people of Quebec unless you can think in French.  (I am the first to
> admit I can't.  I can try, but I find the exercise very strenuous.  I
> need to literally accept a foreign viewpoint to do it well and I am
> unwilling to do so.  The cultural baggage with Arabic and Chinese is
> larger that that which comes with French, but it isn't as imperialistic.
>
> Japanese on the other hand, is much more demanding than French,  but in
> another sense it is not as hard.  Japanese requires you to act in
> certain ways, but it doesn't try as hard to impose its worldview on you.
>   However, the worldview that comes with Japanese is pretty nasty.
> Note, this does not say that Japanese are nasty. However, I have found
> that there is a huge difference in world view between those Japanese who
> speak English and those who don't, I don't know if this holds true for
> those who speak only another Asian as opposed to European language.  I
> haven't studied Russian in decades, but I remember it as being like the
> Germanic langauges.  They do fit your discription above.  They are tools
> and can be used in many different ways.

When I am in China, the tool for communication I prefer is Chinese, although
I often find myself having to think first in English.   In Japan, I prefer
to use
Japanese as much as possible.   In Russia, I have found it useful to use
Russian, and that does come rather easily to me.   English has become the
reasoning and communication tool for most of the educated world, and
anyone who tries to publish a paper in some other language finds the range
of publications quite limited.

Quite right, that programming languages are tools for reasoning.   If one of
those languages leads one to faulty reasoning, it is the wrong tool.   And
reasoning is largely about choosing the right abstractions.   Sometimes
those
abstractions are internally inconsistent or not easily verifiable.

When comparing C++ and Ada, one of the key issues for me is predictability.
The more I am forced to use C++, the more I realize that it is not now nor
will
it ever be as  consistently predictable as Ada.   I dislike it when a
program
compiles with no errors only to discover something that the compiler should
have
caught.  And the ridicule, "You should have known about that little quirk
in the language,"  does not bring much satisfaction when I realize that such
quirks
are rare in Ada.

Why is it that, in engineering, which is intolerant of surprise, we continue
to use
tools in software engineering that are characterized by their tendency to
produce
surprises?

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

Richard Riehle wrote:

> English has become the
> reasoning and communication tool for most of the educated world,
This may be mostly true for communication, but certainly not for reasoning -
please don't make such dangerous illusions.

> and
> anyone who tries to publish a paper in some other language finds the range
> of publications quite limited.
Although mostly true, there were and are notable exceptions. First, any
significant scientific result that was published in prominent journal in any
language will be immediately and widely known, and either the article will be
soon translated into English or a detailed English review will be provided...
at least in "mainstream sciences" - mathematics, physics, chemistry, biology.
Second, I remember that in 70-80th several Soviet mathematical journal were
translated into English by Americans (American Mathematical Society) - in whole
and every issue.

> Why is it that, in engineering, which is intolerant of surprise, we continue to use
> tools in software engineering that are characterized by their tendency to produce
> surprises?

That's because not only tools, but also people may produce surprises.
And there is widespread suspicion that the people who select and insist on
good and robust tools have a tendency to produce surprises by themselves.
And management often prefers surprises from tools to surprises from employers -;) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ed Falis]

On Tue, 10 Feb 2004 03:37:39 GMT, Richard  Riehle <adaworks@earthlink.net> 
wrote:

> People do not select their programming tools as wisely as they select 
> their
> carpentry
> tools.

While I don't disagree with the thrust of your comments, this one is off.  
In woodworking and carpentry, there are many ways to get a specific task 
done, and the choice of tool is often personal preference, just as it is 
for programming language.

- Ed

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

"Ed Falis" <falis@verizon.net> wrote in message
news:opr253fyv98wdn3j@news.verizon.net...
> On Tue, 10 Feb 2004 03:37:39 GMT, Richard  Riehle <adaworks@earthlink.net>
> wrote:
>
> > People do not select their programming tools as wisely as they select
> > their
> > carpentry
> > tools.
>
> While I don't disagree with the thrust of your comments, this one is off.
> In woodworking and carpentry, there are many ways to get a specific task
> done, and the choice of tool is often personal preference, just as it is
> for programming language.

'tis true Ed, that there are many ways to accomplish the same task in
carpentry.  In fact, in carpentry, we often invent tools on the fly to
create some unusual effect.   This goes to the argument of whether
programming is an art, a craft, or an engineering activity.   When I
am trying to be artistic (something I am not), my inventiveness is
more far ranging.   When I am striving for good craftsmanship, I
am able to be inventive but more likely to choose tried and true tools
and methods that have worked for me before.   When I am engineering,
I am encouraged to use well-established, published specifications,
and the corresponding appropriate tools for design representation.

As an artist, I work alone (most of the time).  As a craftsperson,
I am usually crafting solo.   As an engineer, I must communicate
with other engineers using settled knowledge, reasoning tools
that communicate my ideas with clarity, and strive for a
predictable outcome.  If my tools are not conducive to predictability,
they are probably the wrong tools.  This is one of my reasons for
disliking C++ as a engineering tool.

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Thomas Stegen CES2000]

Josh Sebastian wrote:
> Maybe you just weren't very good at C++ templates. I don't mean to be
> insulting, but personal preferences do play a huge roll here. Unless
> someone can prove Ada's generics are Turing-complete, though (a quick
> google doesn't turn up anything), I'd say that we'll have to call C++
> templates more powerful.

Turing completeness is only one measure of power. And not a very
good one for measuring different systems of templates. If you use
templates for any sort of computational programming beyond some
very simple things you are stretching the rubber band beyond its
limit.

-- 
Thomas.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[MSG]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<2460735.u7KiuvdgQP@linux1.krischik.com>...

> Others did that allready. Besides, you would need an installed Ada compiler
> to verify anyway.

time apt-get install gnat
=> 15 seconds

> > 
> > Can you do the following in Ada:
> > 
> > 1. Write *one* bubble-sort function that will work on different
> >    types given an appropriate comparison function
> 
> Shure you can. Ada invented templates long bevore C++ was even though of.
> Ada templates are far more powerfull then C++.

Example? 

> > 2. If B is a subtype of A, can you pass it to any function that
> >    takes A as an argument? (covariance)
> 
> subtype as in object orientation:
> 
> type Parent is tagged null record;
> type Child is new Parent with null record;

"null record" ? How about non-null ones? Is a 3D point (x, y, z) a
subtype of a 2D one (x, y) ?

BTW, does Ada have discriminated unions? (if you don't know what they
are, probably none of the language you used had them)

Also, is it possible to corrupt memory in Ada?
Is it possible to leak memory in Ada?

> or subtype as in simple types:
> 
> type Day_of_Month is range 1 ..  31;
> subtype Day_of_Febuary is Day_of_Month range 1 .. 29;

That's neat.
  
> > BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> > letting on about why Ada isn't used much at NASA any more.
> 
> He also won't tell you why Spirit died.

It's not dead, it's sleeping!

Cheers,
MSG

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[James Rogers]

Given the quite reasonable objections presented by some in the
cross-posted news-groups I would like to carry on this conversation
with you via email. My return email is valid.

Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[MSG]

Thanks very much to everyone for the interesting info. It made me look
more closely at Ada. It looks like it is indeed one of the safest
languages among the ones that aren't garbage collected, which probably
makes it suitable for programming things like airplanes, etc.:

1. hard real-time
2. bug-averse
3. not very performance demanding (don't know about other compilers,
but they say GNAT produces slow executables)

However, it does not look like it's a good match for me, since my
needs are the exact opposite:

1. no real time
2. bugs welcome (but not wrong results) - lusers will not come near my
programs
3. performance is highly important


James Rogers <jimmaureenrogers@att.net> wrote in message news:<Xns9489AEC0F8702jimmaureenrogers@204.127.36.1>...
> Given the quite reasonable objections presented by some in the
> cross-posted news-groups I would like to carry on this conversation
> with you via email. My return email is valid.
> 
> Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ed Falis]

On 9 Feb 2004 18:26:33 -0800, MSG <msg1825@yahoo.com> wrote:

> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)

"... but they say ..."

Great research!

;-)

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[James Rogers]

msg1825@yahoo.com (MSG) wrote in
news:54759e7e.0402091826.2847e0c@posting.google.com: 

> Thanks very much to everyone for the interesting info. It made me look
> more closely at Ada. It looks like it is indeed one of the safest
> languages among the ones that aren't garbage collected, which probably
> makes it suitable for programming things like airplanes, etc.:
> 
> 1. hard real-time
> 2. bug-averse
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
> 
> However, it does not look like it's a good match for me, since my
> needs are the exact opposite:
> 
> 1. no real time
> 2. bugs welcome (but not wrong results) - lusers will not come near my
> programs
> 3. performance is highly important

I find your list of needs interesting. 

How do you distinguish between bugs and wrong results? My experience
is that bugs are detected because they produce incorrect results.
If nothing goes wrong we do not declare the presence of a bug.

I think you will find, if you look into hard real-time systems,
that performance is critical. While it is true that GNAT has
produced relatively slow executables in the past, those same
executables are often 3 to 5 times faster than early Java
programs. I know that current JVMs have improved performance
significantly. I speak of JVMs from around the year 2000. Other
Ada compilers produce faster code than GNAT. Sometimes you get
what you pay for. (GNAT is a free compiler in the GNU compiler
chain).

What kind of performance measures do you use in your problem
domain? C programmers are fond of fast code execution and fast
compilation. C++ programmers have similar performance priorities,
but are willing to sacrifice some compiler speed for the
flexibility of templates. Java programmers frequently prize
speed of coding, with the clever use of the large set of API
libraries available to them. Ada programmers are fond of fast
code and early detection of coding defects.

Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <Xns948AC8C8E553Ejimmaureenrogers@204.127.36.1>, 
jimmaureenrogers@att.net says...

[ ... ]

> I think you will find, if you look into hard real-time systems,
> that performance is critical.

I've looked.  It's usually not.  For real-time systems, the primary 
requirement is usually for absolute predictability, NOT for maximum 
performance.

> While it is true that GNAT has
> produced relatively slow executables in the past, those same
> executables are often 3 to 5 times faster than early Java
> programs. I know that current JVMs have improved performance
> significantly. I speak of JVMs from around the year 2000.

Using Java as a standard of comparison is a tacit admission of a major 
problem.

> Other
> Ada compilers produce faster code than GNAT. Sometimes you get
> what you pay for. (GNAT is a free compiler in the GNU compiler
> chain).

The last time I checked, GNAT uses the same back-end as the other GNU 
compilers, so if it doesn't produce as good of code, it's a strong 
indication of a performance problem in the language proper.
 
> What kind of performance measures do you use in your problem
> domain? C programmers are fond of fast code execution and fast
> compilation. C++ programmers have similar performance priorities,
> but are willing to sacrifice some compiler speed for the
> flexibility of templates. Java programmers frequently prize
> speed of coding, with the clever use of the large set of API
> libraries available to them. Ada programmers are fond of fast
> code and early detection of coding defects.

Any statement that attempts to characterize all C++ (or Java or Ada) 
programmers as having the same priorities as each other is bound to be 
false.

Worse, there's a tendency to overcompensate for perceived weaknesses at 
the expense of perceived strengths.  Thinking of error reporting as a 
weakness, many C++ programmers frequently put tremendous work into it.

Conversely, many C++ programmers take execution speed so much for 
granted that they write horribly inefficient code on the assumption that 
the compiler can (and will) make up for whatever they do.

Though I don't work with as many Ada programmers on as regular a basis, 
it appears to me that many do more or less the opposite: it's so widely 
assumed that the compiler will catch almost all errors, that many 
blithely assume that almost anything that compiles MUST be correct.  At 
the same time, execution speed has been perceived as a problem often 
enough that many knowingly and intentionally subvert type-checking and 
such, on the assumption that it's necessary to get the speed they think 
they need to be competitive.

Without trying to take this too far, the result is that in _many_ cases, 
what are widely perceived as strengths or weaknesses of particular 
languages often end up being almost exactly the opposite of what's 
really the case.  In the end, nearly all the factors being discussed 
depend far more on the programmer than the language, so complacency is 
common but rarely justified.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Chad R. Meiners]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a93b6629128b2fc989c8b@news.clspco.adelphia.net...
> In article <Xns948AC8C8E553Ejimmaureenrogers@204.127.36.1>,
> jimmaureenrogers@att.net says...
>
> [ ... ]
>
> > I think you will find, if you look into hard real-time systems,
> > that performance is critical.
>
> I've looked.  It's usually not.  For real-time systems, the primary
> requirement is usually for absolute predictability, NOT for maximum
> performance.

Performance can be critical while not being the primary requirement.

> > While it is true that GNAT has
> > produced relatively slow executables in the past, those same
> > executables are often 3 to 5 times faster than early Java
> > programs. I know that current JVMs have improved performance
> > significantly. I speak of JVMs from around the year 2000.
>
> Using Java as a standard of comparison is a tacit admission of a major
> problem.

He was talking about the GNAT of the past gone by (most likely predating
1996), when the compiler was still young and produced relatively slow code.

> > Other
> > Ada compilers produce faster code than GNAT. Sometimes you get
> > what you pay for. (GNAT is a free compiler in the GNU compiler
> > chain).
>
> The last time I checked, GNAT uses the same back-end as the other GNU
> compilers, so if it doesn't produce as good of code, it's a strong
> indication of a performance problem in the language proper.

You should make sure that you are comparing the same back end version for
each compiler.  For instance GNAT 3.15p uses the gcc 2.8.1 backend for
stability reasons.

> Though I don't work with as many Ada programmers on as regular a basis,
> it appears to me that many do more or less the opposite: it's so widely
> assumed that the compiler will catch almost all errors, that many
> blithely assume that almost anything that compiles MUST be correct.  At
> the same time, execution speed has been perceived as a problem often
> enough that many knowingly and intentionally subvert type-checking and
> such, on the assumption that it's necessary to get the speed they think
> they need to be competitive.

However, from my personal experience it appears to me that MOST Ada
programmers don't suffer from such unwise beliefs.  (Many Ada programmers
could be as little as one; Most Ada programmers implies the majority)

> Without trying to take this too far, the result is that in _many_ cases,
> what are widely perceived as strengths or weaknesses of particular
> languages often end up being almost exactly the opposite of what's
> really the case.  In the end, nearly all the factors being discussed
> depend far more on the programmer than the language, so complacency is
> common but rarely justified.

Of course you need a competent and vigilant programmer; however, language
design does affect the effectiveness of this programmer so it does not just
boil down to finding good programmers.

-CRM

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Jerry Coffin wrote:
> 
> I've looked.  It's usually not.  For real-time systems, the primary 
> requirement is usually for absolute predictability, NOT for maximum 
> performance.
> 
Speaking as one who does this daily in Ada, I'd take minor exception. 
Yes, *predictability* is essential and that's more an algorithmic issue 
rather than a language issue. However, don't believe for a moment that 
we don't sweat bullets over *speed* as well. When you have things that 
*must* finish in a millisecond and leave something to spare you worry 
about compiler efficiency quite a lot. Embedded, avionics quality 
compilers are typically stressing efficiency over other attributes (like 
related support tools). I've used and do use Ada compilers that are as 
good or better than those for other languages.


> 
> The last time I checked, GNAT uses the same back-end as the other GNU 
> compilers, so if it doesn't produce as good of code, it's a strong 
> indication of a performance problem in the language proper.
>  
Having used Gnat quite a bit, I'd like to know what you think it does 
that is slow. I'd be interested in some benchmark code that Gnat does 
inefficiently in comparison to similar code in C passed through gcc.

Given that I regularly use high quality Ada compilers for hard realtime 
work and have been more than satisfied with the resultant efficiency of 
the code, I'd have to say that your "strong indication of a performance 
problem in the language proper" is essentially disproven by example. Its 
an old cannard that gets regularly dragged out because people have this 
tendancy to believe unicorn stories. "My brother knows this guy who had 
a friend wo worked with this guy who used to use Ada 20 years ago and he 
said that Ada is slow, so it *must* be true..."


> 
> Though I don't work with as many Ada programmers on as regular a basis, 
> it appears to me that many do more or less the opposite: it's so widely 
> assumed that the compiler will catch almost all errors, that many 
> blithely assume that almost anything that compiles MUST be correct.  At

I work with lots of Ada programmers in a place where failure is not an 
option. We *never* blithely assume that if it compiles, its correct. We 
spend lots of time and money testing. However, in studies I've done of 
errors in Ada code versus that in other languages, you typically get a) 
fewer of them and b) of a different class. We used to get all sorts of 
errors relating to scalings on numeric values and similar sorts of 
problems that relate closely to type checking. Now, those errors all but 
disappear.

We still have errors - but they tend to be more along the lines of 
*logic* errors. No language can save you from that. The net result is 
that we save lots of money in not having to rework code and regression 
test it all because of relatively small problems that the compiler can 
catch for us. Everyone who studies "process" knows that the sooner you 
catch a problem in the production chain, the cheaper it is to fix.



> the same time, execution speed has been perceived as a problem often 
> enough that many knowingly and intentionally subvert type-checking and 
> such, on the assumption that it's necessary to get the speed they think 
> they need to be competitive.
> 
There's no way that runtime checks aren't going to cost *something*. 
However, in most apps, the cost isn't so high as to be prohibitive. When 
I build PC based apps in Ada, all the checks are left on and though 
there must be a performance hit in there somewhere, its really hard to 
see these days given the speed of your garden variety microprocessor. 
For 90% of apps it should fall below the noise floor and not matter. For 
the relatively *small* number of apps (and usually only in some critical 
places within those apps) that have a performance issue, sure - go ahead 
and turn off checks. You still get the static checks and that covers a 
lot of ground. It seems to be a non-issue to me.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Dowie]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a93b6629128b2fc989c8b@news.clspco.adelphia.net...
> The last time I checked, GNAT uses the same back-end as the other GNU
> compilers, so if it doesn't produce as good of code, it's a strong
> indication of a performance problem in the language proper.

No, it could be an indication of a problem in the front-end - but any such
inefficiency need not be *required* by the language standard.


[snip]
> Though I don't work with as many Ada programmers on as regular a basis,
> it appears to me that many do more or less the opposite: it's so widely
> assumed that the compiler will catch almost all errors, that many
> blithely assume that almost anything that compiles MUST be correct.

I do and I'm not sure that's true but YMMV.


> Without trying to take this too far, the result is that in _many_ cases,
> what are widely perceived as strengths or weaknesses of particular
> languages often end up being almost exactly the opposite of what's
> really the case.  In the end, nearly all the factors being discussed
> depend far more on the programmer than the language, so complacency is
> common but rarely justified.

I agree with this. For example, I know lots of engineers who worry about
context switch times and function call overheads, but on today's processors,
these are unlikely to be a major problem - cache paging on the other hand...

-- Martin

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On 9 Feb 2004 18:26:33 -0800, msg1825@yahoo.com (MSG) wrote:

>Thanks very much to everyone for the interesting info. It made me look
>more closely at Ada. It looks like it is indeed one of the safest
>languages among the ones that aren't garbage collected, which probably
>makes it suitable for programming things like airplanes, etc.:
>
>1. hard real-time
>2. bug-averse
>3. not very performance demanding (don't know about other compilers,
>but they say GNAT produces slow executables)
>
>However, it does not look like it's a good match for me, since my
>needs are the exact opposite:
>
>1. no real time

This is easy in Ada:

loop
   null;
end loop;
   -- The rest won't meet any deadline!

>2. bugs welcome (but not wrong results) - lusers will not come near my
>programs

It is easy to write a virus program scanning your source codes and
randomly sowing them with bugs, if you so enjoy them...

>3. performance is highly important

GNAT is a front end of GNU C...

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Dowie]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:vjah20tahj48fftkpeghp29ugnojfdd4r4@4ax.com...
> >3. performance is highly important
>
> GNAT is a front end of GNU C...

Not quite...
...they share a back-end - GNAT does NOT translate Ada source into C as an
intermediate.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On Tue, 10 Feb 2004 11:08:16 +0000 (UTC), "Martin Dowie"
<martin.dowie@btopenworld.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:vjah20tahj48fftkpeghp29ugnojfdd4r4@4ax.com...
>> >3. performance is highly important
>>
>> GNAT is a front end of GNU C...
>
>Not quite...
>...they share a back-end - GNAT does NOT translate Ada source into C as an
>intermediate.

Yes of course, GNU C is just a name of a set of compilers. Important
is that the back-end is same, so it is unlikely for GNAT to be slower
than GNU C. Theoretically Ada as a language should allow better
optimization than C.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Dowie]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:22jh209rupt9e957iloaus9fn34ofm0qt3@4ax.com...
> >Not quite...
> >...they share a back-end - GNAT does NOT translate Ada source into C as
an
> >intermediate.
>
> Yes of course, GNU C is just a name of a set of compilers. Important
> is that the back-end is same, so it is unlikely for GNAT to be slower
> than GNU C. Theoretically Ada as a language should allow better
> optimization than C.

For total pedantry, GCC is the name for the set of compilers, GNU C is
one element in this set.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Mark McIntyre]

On Tue, 10 Feb 2004 14:11:16 +0000 (UTC), in comp.lang.c , "Martin Dowie"
<martin.dowie@btopenworld.com> wrote:

stuff.

Can you take comp.lang.c off the crossposts. this has wandered miles away
from topicality, even if it were near in the first place....

-- 
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[August Derleth]

Martin Dowie wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:22jh209rupt9e957iloaus9fn34ofm0qt3@4ax.com...
> 
>>>Not quite...
>>>...they share a back-end - GNAT does NOT translate Ada source into C as
> 
> an
> 
>>>intermediate.
>>
>>Yes of course, GNU C is just a name of a set of compilers. Important
>>is that the back-end is same, so it is unlikely for GNAT to be slower
>>than GNU C. Theoretically Ada as a language should allow better
>>optimization than C.
> 
> 
> For total pedantry, GCC is the name for the set of compilers, GNU C is
> one element in this set.
> 

GNU C is also used to refer to a nonstandard (extended and modified) 
version of C compiled by the GNU Project's C compilers in a 
non-conformant mode. A notable extension provided by GNU C over standard 
C is the existence of functions that are private to another function, 
and are defined within the function they are private to.

An example:

int foo(int x)
{
    int bar(int y)
    {
       return y % 2;
    }
    int z = bar(x);

    return z + 2;
}

That is a compilable GNU C program, and it behaves such that bar() is 
not visible outside foo(). It is not conformant to any relevant standard 
(as far as I know).

-- 
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[MSG]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<vjah20tahj48fftkpeghp29ugnojfdd4r4@4ax.com>...
> On 9 Feb 2004 18:26:33 -0800, msg1825@yahoo.com (MSG) wrote:
> >
> >1. no real time

[...]

> >2. bugs welcome (but not wrong results) - lusers will not come near my
> >programs

[...]

> It is easy to write a virus program scanning your source codes and
> randomly sowing them with bugs, if you so enjoy them...

What I meant was of course that I don't place as much emphasis on
these as, say, Boeing does, and so all other factors in language
choice become relatively more important to me.

> >3. performance is highly important
> 
> GNAT is a front end of GNU C...

Can you write (*) a matrix multiplication routine in Ada, compile it
with GNAT and measure the number CPU cycles per FLOP, compare to a
similar routine in C?
The shootout seems to put GNAT closer to Perl and Java than to C/C++.

Cheers,
MSG

(*) Only if you think the one on the shootout page is inadequate.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[James Rogers]

msg1825@yahoo.com (MSG) wrote in
news:54759e7e.0402101819.95cec1d@posting.google.com: 

> Can you write (*) a matrix multiplication routine in Ada, compile it
> with GNAT and measure the number CPU cycles per FLOP, compare to a
> similar routine in C?
> The shootout seems to put GNAT closer to Perl and Java than to C/C++.

The shootout numbers I saw put vc at .07, gcc at 0.10 and GNAT at .20.
Java was 0.73 and Perl was 34.31.

I do not see how .2 is closer to .7 or 34 than it is to .1.

Your mathematics seems seriously flawed. 

Please explain your reasoning.

Jim Rogers

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Dmitry A. Kazakov]

On 10 Feb 2004 18:19:13 -0800, msg1825@yahoo.com (MSG) wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<vjah20tahj48fftkpeghp29ugnojfdd4r4@4ax.com>...
>> On 9 Feb 2004 18:26:33 -0800, msg1825@yahoo.com (MSG) wrote:
>> >
>> >3. performance is highly important
>> 
>> GNAT is a front end of GNU C...
>
>Can you write (*) a matrix multiplication routine in Ada, compile it
>with GNAT and measure the number CPU cycles per FLOP, compare to a
>similar routine in C?

There is a problem with that. C does not have arrays. Yet matrices,
you know, are two-dimensional ones. So any comparison here would be
suspicious. A program in C, supposed to multiply matrices would lack
ADT abstraction layer. It is well possible to write something similar
in Ada, using pointers instead of arrays etc. (After all true
programmer can write a FORTRAN program in Pascal, if I correctly quote
the famous sentence) Such a program with all checks surpressed will
take the same number of CPU cycles. But who might be interested in
such comparison?

Note that presence of an abstraction per se does not mean performance
penalty. The effect could be quite opposite. The difference between C
and Ada is that in C you almost cannot express intention. It is too
low-level language. You just order the compiler to do something and it
obeys. This may result in slower code, because the compiler should
deduce that:

char * t;
char * s;

while (*t++ = *s++);

is in fact to copy a string. If it would, it could then apply a
corresponding target CISC machine instruction. In Ada it is easier for
the compiler:

T : String (...);
S : String (...);

T := S;

Even if you work at the array abstraction level:

for I in S'Range loop
   T (I) := S (I);
end loop;

there is a lot of useful information for the compiler here, much more
than in pointer increments and dereferencings. Note also, that by
using pointers you commit yourself to only the objects which can be
referenced by a pointer. This might be a heavy burden on some
machines. Compare this with Ada, where you have to *explicitly*
specify that an object is aliased (a subject of referencing). If you
don't, the compiler is free to move such objects to registers, cache,
an external matrix processing unit etc.

Even if GNAT might not use all that, it is at best a GNAT problem, not
one of Ada.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Given that it is 100% legal Ada to build a procedure that contains 
nothing but assembly language instructions, I'd be confident that one 
could build Ada code that is just as fast as anything produced by any 
compiler anywhere. So if one wants to get into high-speed shootouts 
between languages, a ground rule has to be that you're comparing similar 
code.

If an Ada example uses a high level abstraction of a matrix and C can't 
do that sort of abstraction, then C can't play in that game. If the C 
example uses some raw chunk of memory and address arithmetic, then the 
Ada example would need to be coded up in that style as well (and yes, 
that can be done - but nobody who uses Ada typically *wants* to. :-) 
Only if you have similarly coded examples can you possibly hope to 
determine if one compiler is more efficient than another.

MDC

Dmitry A. Kazakov wrote:
> 
> There is a problem with that. C does not have arrays. Yet matrices,
> you know, are two-dimensional ones. So any comparison here would be
> suspicious. A program in C, supposed to multiply matrices would lack

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ole-Hjalmar Kristensen]

Marin David Condic <nobody@noplace.com> writes:

> Given that it is 100% legal Ada to build a procedure that contains
> nothing but assembly language instructions, I'd be confident that one
> could build Ada code that is just as fast as anything produced by any
> compiler anywhere. So if one wants to get into high-speed shootouts
> between languages, a ground rule has to be that you're comparing
> similar code.
> 
> If an Ada example uses a high level abstraction of a matrix and C
> can't do that sort of abstraction, then C can't play in that game. If
> the C example uses some raw chunk of memory and address arithmetic,
> then the Ada example would need to be coded up in that style as well
> (and yes, that can be done - but nobody who uses Ada typically *wants*
> to. :-)
> Only if you have similarly coded examples can you possibly hope to
> determine if one compiler is more efficient than another.
> 
> MDC

Yes, but there are some caveats. Ada insists on getting floating point
arithmetic "right", so it will typically do it differently than C,
even though the Ada and C programs superficially look the same.  For
floating-point intensive programs, this may result in quite a
performance hit.  I recently ported a small ray-tracing kind of
application from C to Ada, keeping largely to the structure of the
original program, but using sensible Ada constructs where appropriate.
First I verified that it indeed worked the same as the original, then
turned off all checks and compiled both versions with -O3 and
-funroll-all loops.  The Ada version was slower by a factor of
2.

Profiling showed that much of the time was spent in sqrt() and other
math functions.  Next, I imported the necessary functions from the C
library and used those instead. This resulted in Ada and C versions
which ran at the same speed. Some slight algorithmic optimizations
later, the Ada version was approximately 20% faster than the C
version. Profiling again, I found that about 10 seconds of a total of
40 seconds runtime was consumed in the truncate function.  An inlined
assmbler version of this reduced the time spent in truncate to 1-2
seconds, which was more reasonable.

Note that neither the C version nor the Ada version are anywhere close
to the limit in terms of speed, using the short vector instructions of
the processor, I could probably get an overall speedup by a factor of
2-3 for this particular application if coded in assembler.

> 
> Dmitry A. Kazakov wrote:
> > There is a problem with that. C does not have arrays. Yet matrices,
> > you know, are two-dimensional ones. So any comparison here would be
> > suspicious. A program in C, supposed to multiply matrices would lack
> 
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
> 
> Send Replies To: m   o   d   c @ a   m   o   g
>                     c   n   i       c   .   r
> 
>      "Face it ladies, its not the dress that makes you look fat.
>      Its the FAT that makes you look fat."
> 
>          --  Al Bundy
> 
> ======================================================================
> 

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Ole-Hjalmar Kristensen wrote:
 >
 > Yes, but there are some caveats. Ada insists on getting floating point
 > arithmetic "right", so it will typically do it differently than C,
 > even though the Ada and C programs superficially look the same.  For


Well, I *did* say that only if you had similarly coded examples could 
you hope to do any comparison. Not that you couldn't do a comparison and 
see a difference. ;-)

Secondly, one needs to insist that some code under evaluation must 
produce a *correct* result. If a C coded example computes the wrong 
answer at twice the speed of a similar Ada example that gets the answer 
right, is it even worth discussing?

My final objection to the whole "Benchmark Wars" is that for 90% of the 
uses of compilers, it just plain doesn't matter. If I build a program to 
solve a matrix and it gets me an answer displayed on my screen in 10 
seconds - but I re-code it in another language and the answer pops up in 
8 seconds instead, what am I going to do with those extra two seconds? 
Save them up for Christmas? People do this sort of math stuff all day 
long in spreadsheets which are interpreting the answers at great 
inefficiency and they spend lots of time not caring about it. So why do 
programmers without a real performance constraint spend so much time 
getting their panties in a bunch over something that never has a real 
impact on what they're doing?

Keep in mind that I work with apps where miliseconds count, so I know 
how to worry about compiler efficiency. I also know I can get good 
compiler efficiency out of Ada (plus all of Ada's other benefits), so 
when I *must* be efficient, I know I can get there. But when I go over 
to a PC or workstation to develop some hacker tool I need, worrying 
about a few extra CPU cycles is way down on my list of concerns.

Too many people spend too much time agonizing over "Compiler Efficiency" 
- usually without any real scientific data to back up their perceptions 
of what is fast and what is slow - and most of the time it just plain 
doesn't matter. I'd bet that if we took most of the applications that 
people use on a daily basis and inserted random delay statements 
throughout them to double the amount of CPU cycles they use, nobody 
would notice any difference in how they got their job done.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

["Followup-To:" header set to comp.lang.ada.]
On 2004-02-12, Marin David Condic <nobody@noplace.com> wrote:
>
> Too many people spend too much time agonizing over "Compiler Efficiency" 
> - usually without any real scientific data to back up their perceptions 
> of what is fast and what is slow - and most of the time it just plain 
> doesn't matter. I'd bet that if we took most of the applications that 
> people use on a daily basis and inserted random delay statements 
> throughout them to double the amount of CPU cycles they use, nobody 
> would notice any difference in how they got their job done.

Yes. It is like debating which car is best and safest by how far the
speedometer goes and not caring if it has a seat belt or not. C/C++ do
not have seat belts.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Well, the seat belts are another issue. Its more like a case of 
comparing a '62 Chevvy capable of 70mph with a Lamborghini Countache 
capable of 170mph. Given that most roadways are limited to 65mph by law, 
from an *engineering* perspective, either car will perform acceptably 
with respect to speed. So, depending on other concerns (such as 
financial factors) there is no reason not to choose the '62 Chevvy just 
because it can't outrace the Lamborghini.

Given that all analogies are weak arguments, I'd like to just make sure 
it is clear that I don't consider Ada to be a '62 Chevvy, nor do I 
consider C to be a Lamborghini. I'm only objecting to making the race 
course into an overriding concern when most people will never even get 
on one.

MDC


Preben Randhol wrote:
> 
> Yes. It is like debating which car is best and safest by how far the
> speedometer goes and not caring if it has a seat belt or not. C/C++ do
> not have seat belts.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-02-13, Marin David Condic <nobody@noplace.com> wrote:
> Well, the seat belts are another issue. Its more like a case of 
> comparing a '62 Chevvy capable of 70mph with a Lamborghini Countache 
> capable of 170mph. Given that most roadways are limited to 65mph by law, 
> from an *engineering* perspective, either car will perform acceptably 
> with respect to speed. So, depending on other concerns (such as 
> financial factors) there is no reason not to choose the '62 Chevvy just 
> because it can't outrace the Lamborghini.
>
> Given that all analogies are weak arguments, I'd like to just make sure 
> it is clear that I don't consider Ada to be a '62 Chevvy, nor do I 
> consider C to be a Lamborghini. I'm only objecting to making the race 
> course into an overriding concern when most people will never even get 
> on one.

I agree with you. What I wanted to point out was that for me safety is more
important than some extra milliseconds. I'm tried of programs (in C,
C++) that crash and you loose 1-2 hours work. If one had used Ada in
stead one could have caught the unexpected exception at the outer layer and
done an emergency save of the data so that one would waste 1-2 hours of
work.

So in stead of comparing C (or C++) and Ada without checks on, one
should compare Ada with C (or C++) that has the same checks.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ole-Hjalmar Kristensen]

Marin David Condic <nobody@noplace.com> writes:

> Ole-Hjalmar Kristensen wrote:
>  >
>  > Yes, but there are some caveats. Ada insists on getting floating point
>  > arithmetic "right", so it will typically do it differently than C,
>  > even though the Ada and C programs superficially look the same.  For
> 
> 
> Well, I *did* say that only if you had similarly coded examples could
> you hope to do any comparison. Not that you couldn't do a comparison
> and see a difference. ;-)
> 
> Secondly, one needs to insist that some code under evaluation must
> produce a *correct* result. If a C coded example computes the wrong
> answer at twice the speed of a similar Ada example that gets the
> answer right, is it even worth discussing?
> 

It could well be. In the case of an interactive raytracer, minor
numerical errors does not really matter if you can get the results at
twice the speed. I imagine you can find other applications with
similar characteristics.  But in general, I agree that for the
majority of applications the difference in speed between languages and
compilers is nothing to worry about.

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Well, there's *always* exceptional cases and we could sit here all day 
long dreaming up applications in which math errors matter or math errors 
don't. We could also find lots of apps in which speed matters. The key 
factor being that for most of the software that gets built in the world 
(look at what's on your desktop for appropriate examples) and for most 
of the processors on which they execute (again, look at the computer on 
your desk for an appropriate example) the relative efficiency of most 
compilers/languages is incredibly unimportant. The word processor I'm 
using to type this could have been built in interpretive Basic 
functioning at 10x the number of CPU cycles as an equivalent program in 
some compiled language and I'd probably never see any difference from my 
keyboard.

So rather than talk about language/compiler efficiency its probably more 
productive for most apps to discuss what *else* a language/compiler 
offers the developer. (Things like safety/reliability, ease of 
understanding, developmental leverage, available tools & libraries, etc.)

MDC

Ole-Hjalmar Kristensen wrote:
> 
> 
> It could well be. In the case of an interactive raytracer, minor
> numerical errors does not really matter if you can get the results at
> twice the speed. I imagine you can find other applications with
> similar characteristics.  But in general, I agree that for the
> majority of applications the difference in speed between languages and
> compilers is nothing to worry about.
> 
> <snip>
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ole-Hjalmar Kristensen]

Marin David Condic <nobody@noplace.com> writes:

> Well, there's *always* exceptional cases and we could sit here all day
> long dreaming up applications in which math errors matter or math
> errors don't. We could also find lots of apps in which speed
> matters. The key factor being that for most of the software that gets
> built in the world (look at what's on your desktop for appropriate
> examples) and for most of the processors on which they execute (again,
> look at the computer on your desk for an appropriate example) the
> relative efficiency of most compilers/languages is incredibly
> unimportant. The word processor I'm using to type this could have been
> built in interpretive Basic functioning at 10x the number of CPU
> cycles as an equivalent program in some compiled language and I'd
> probably never see any difference from my keyboard.
> 
> So rather than talk about language/compiler efficiency its probably
> more productive for most apps to discuss what *else* a
> language/compiler offers the developer. (Things like
> safety/reliability, ease of understanding, developmental leverage,
> available tools & libraries, etc.)
> 
> MDC

Actually, I'm not exactly dreaming up such cases, since I spent the
last two years developing software for seismic visualization. Speed
matters very much, in that if you can double your speed, you can
handle a survey twice the size at the same machine.
The trick is to know where you need to be accurate and where not to be.
And yes, that particular application ran on a desktop PC.

But my mind is probably bent from too many years of programming
graphics and soft real time data bases.

I'm not arguing against discussing what else a language/compiler
offers, just pointing out that for some applications, the need for
speed is very real.

> 
> Ole-Hjalmar Kristensen wrote:
> > It could well be. In the case of an interactive raytracer, minor
> > numerical errors does not really matter if you can get the results at
> > twice the speed. I imagine you can find other applications with
> > similar characteristics.  But in general, I agree that for the
> > majority of applications the difference in speed between languages and
> > compilers is nothing to worry about.
> > <snip>
> >
> 
> 
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
> 
> Send Replies To: m   o   d   c @ a   m   o   g
>                     c   n   i       c   .   r
> 
>      "Face it ladies, its not the dress that makes you look fat.
>      Its the FAT that makes you look fat."
> 
>          --  Al Bundy
> 
> ======================================================================
> 

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

I agree. I do it all the time (and in Ada). My engine controls have to 
react with very real, very hard deadlines and I'd better have a compiler 
that squeezes out ever last instruction it possibly can. My point is 
that *most* apps *don't* have that kind of requirement, so designers of 
those types of apps shouldn't get wrapped around the axle over 
evaluation of the relative speed of compilers and languages. In other 
words if Ada's critics were correct that "Ada is slow..." (it isn't) it 
would still be suitable for proabably 90% of the software development 
done in the world.

MDC

Ole-Hjalmar Kristensen wrote:
> 
> I'm not arguing against discussing what else a language/compiler
> offers, just pointing out that for some applications, the need for
> speed is very real.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <402A29B4.3010807@noplace.com>, nobody@noplace.com says...
> Given that it is 100% legal Ada to build a procedure that contains 
> nothing but assembly language instructions, I'd be confident that one 
> could build Ada code that is just as fast as anything produced by any 
> compiler anywhere. So if one wants to get into high-speed shootouts 
> between languages, a ground rule has to be that you're comparing similar 
> code.
> 
> If an Ada example uses a high level abstraction of a matrix and C can't 
> do that sort of abstraction, then C can't play in that game. If the C 
> example uses some raw chunk of memory and address arithmetic, then the 
> Ada example would need to be coded up in that style as well (and yes, 
> that can be done - but nobody who uses Ada typically *wants* to. :-) 
> Only if you have similarly coded examples can you possibly hope to 
> determine if one compiler is more efficient than another.

IMO, this produces a benchmark that is so far departed from the real 
world that while it may produce results that are accurate (for some 
definition of the word) they're utterly devoid of relationship with 
reality, and therefore of any real meaning.

If you want to do a comparison, you need to compare things how they're 
really used.  There are certainly variations among programmers, but to 
be meaningful the test code should fall well within the range of normal 
variations.  We all know that "real programmers can write Fortran in any 
language", but writing Fortran in Ada, C++, Java, etc., doesn't really 
accomplish much, and the performance of such code is meaningless at 
best, and more likely to be downright misleading.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

Well, from my experience with benchmarking for realtime systems, we 
generally drew on sample code that was typical of our control systems. 
Compiler A might do a real good job of optimizing one algorithm while 
Compiler B was better at another. This was done for purposes of 
selecting which Ada compiler we wanted to use for the given target - not 
for selecting a language.

We never attempted language-to-language benchmarking because we pretty 
much figured it was pointless. Too many variables to really get a 
meaningful result and we knew we could get realtime quality out of most 
languages usually used for the purpose. So we picked the language based 
on other factors (error reduction, improved productivity, etc) and then 
benchmarked the competitors in that category. Key to trying to do any 
evaluation of anything in a scientific manner is to hold "all other 
things being equal" and when it comes to code in different languages 
with different compilers, you have a tough time doing this.

A key result of our tests is that there are seldom any clear winners. It 
depends a lot on what your real-world code is going to look like. Some 
languages may be ruled out for lack of a competing implementation (if 
nobody makes an embedded compiler for your target, the game is over) but 
usually the "conventional" players are around. Then - depending on the 
specific compiler - there are various ways of getting optimal code for 
the algorithms you're interested in and usually you have to learn that 
along the way. Its seldom an exact science. Sooner or later you pick 
something and then get on with getting the job done. So long as you 
didn't pick something hopelessly inefficient, you usually find a way to 
get reasonable results with what you picked.

I'd offer again my observation that for probably 90% of the software 
development that goes on in the world, relative compiler/language 
inefficiency is a total non-issue and people ought not to sweat over it. 
Even if there was any truth to the "Ada is slow..." rumor (and a given 
compiler is twice as slow as some highly optimized C example?) you'll 
never even see it in most applications. One ought to then focus in on 
other important factors that go along with language selection such as 
available compilers, reliable implementations, improvements in error 
rates and/or productivity, available tools, available libraries, 
time-to-market issues, etc.

MDC


Jerry Coffin wrote:
> 
> IMO, this produces a benchmark that is so far departed from the real 
> world that while it may produce results that are accurate (for some 
> definition of the word) they're utterly devoid of relationship with 
> reality, and therefore of any real meaning.
> 
> If you want to do a comparison, you need to compare things how they're 
> really used.  There are certainly variations among programmers, but to 
> be meaningful the test code should fall well within the range of normal 
> variations.  We all know that "real programmers can write Fortran in any 
> language", but writing Fortran in Ada, C++, Java, etc., doesn't really 
> accomplish much, and the performance of such code is meaningless at 
> best, and more likely to be downright misleading.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Xenos]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:qdqj20lomb5865p7qb24eojpgk7ijpbikr@4ax.com...
> On 10 Feb 2004 18:19:13 -0800, msg1825@yahoo.com (MSG) wrote:
>
> is in fact to copy a string. If it would, it could then apply a
> corresponding target CISC machine instruction. In Ada it is easier for
> the compiler:
>
> T : String (...);
> S : String (...);
>
> T := S;
>
> Even if you work at the array abstraction level:
>
> for I in S'Range loop
>    T (I) := S (I);
> end loop;
>
But of course, the first example will only work if S'Length is equal to
T'Length or it will raise a constraint_error.  The second will only work if
T'Length is greater than or equal to S'Length.

DrX

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-02-11, Xenos <dont.spam.me@spamhate.com> wrote:
> But of course, the first example will only work if S'Length is equal to
> T'Length or it will raise a constraint_error.  The second will only work if
> T'Length is greater than or equal to S'Length.

Yes, you won't get a buffer overflow.


Preben
-- 
"When Roman engineers built a bridge, they had to stand under it while
 the first legion  marched across.  If programmers today  worked under
 similar  ground rules,  they might well find  themselves getting much
 more interested in Ada!"                              -- Robert Dewar

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Xenos]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnc2kn4d.aav.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no...
>
> Yes, you won't get a buffer overflow.
>
You wouldn't of gotten a buffer overflow either way, it would have raised a
constraint_error.

DrX

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

["Followup-To:" header set to comp.lang.ada.]
On 2004-02-11, Xenos <dont.spam.me@spamhate.com> wrote:
>
> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
> message
> news:slrnc2kn4d.aav.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no...
>>
>> Yes, you won't get a buffer overflow.
>>
> You wouldn't of gotten a buffer overflow either way, it would have raised a
> constraint_error.

Not in C.

But you cut that example out.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Xenos]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnc2ksoh.djj.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no...
> Not in C.
>
> But you cut that example out.
>
My bad then :)

DrX

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

MSG wrote:

> Can you write (*) a matrix multiplication routine in Ada, compile it
> with GNAT and measure the number CPU cycles per FLOP, compare to a
> similar routine in C?
> The shootout seems to put GNAT closer to Perl and Java than to C/C++.

As a matter of fact I am writing a fairly complex linear algebra package 
in Ada that is designed for high-performance in supercomputer type 
applications.  I probably could write it in C and stay out of the 
asylum, but it would be a close call. Why? It does things like A := A*B; 
in place, with only a row sized temporary, and using Strassen's 
algorithm with almost no copying.  For efficiency the code works not 
with an array type, but with a view that may share data with another 
view.  That way I can, for example, divide an existing matrix into four 
smaller matrices in O(1) time and space. Eventually I will also have 
code present to support both transposed views of matrices, in fact I 
just finished the fast transpose code.  That way I can transpose the 
right argument, and avoid doing it more than once.

But if I did write the same code in C, I would not expect performance to 
be better.  (There are a few cases where the parameter passing overhead 
in C would be higher, so performance would be technically worse, but 
only by a few instructions.)

> (*) Only if you think the one on the shootout page is inadequate.

Which shootout page, this one? http://dada.perl.it/shootout/matrix.html

If so the only questions I would have is why are there no default 
initial values for the matrices to insure consistancy.  (It would be 
possible for any implementation to fail unless overflow checking is 
turned off, and in Ada that can cause code to run slower.)  Incidently 
on this page, on this test gcc takes ten milliseconds, GNAT takes 20 ms. 
  Hardly in the same class as perl, 34.31 seconds, or even java, 73 
milliseconds.

Also I just submitted a new version of the strcat routine to fix a 
minor problem that resulted in the test being reported as failed.  (The 
length was printed with leading spaces, and the test harness didn't 
expect that.)  While I was at it I rewrote basically the whole thing:

with Ada.Command_Line; use Ada.Command_Line;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Strings.Fixed; use Ada.Strings;
with Ada.Text_Io; use Ada.Text_Io;
procedure Strcat is
    N: Integer;
    Hello : String := "hello" & Ascii.Lf;
begin
    if Argument_Count < 1
    then N := 10_000;
    else N := Integer'Value(Argument(1));
    end if;
    declare
      Buffer : Unbounded_String := N*Hello;
    begin
    Put_Line(Ada.Strings.Fixed.Trim
              (Integer'Image(Length(Buffer)),Left));
    end;
end Strcat;

This results in about a 100x speed up.  Is this the right way to write 
it and the code they had wrong?  In one sense, that probably is true. 
But if I use Bounded_String, the version on the website is slightly 
faster, and both versions fall midway between the fast and slow 
Unbounded versions.  (A version that just uses String is actually faster 
than the Unbounded String version.  However, I think that version is a 
bit of a cheat. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Lutz Donnerhacke]

* Robert I. Eachus wrote:
> with Ada.Command_Line; use Ada.Command_Line;
> with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
> with Ada.Strings.Fixed; use Ada.Strings;
> with Ada.Text_Io; use Ada.Text_Io;
> procedure Strcat is
>     N: Integer;
>     Hello : String := "hello" & Ascii.Lf;
> begin
>     if Argument_Count < 1
>     then N := 10_000;
>     else N := Integer'Value(Argument(1));
>     end if;
>     declare
>       Buffer : Unbounded_String := N*Hello;
>     begin
>     Put_Line(Ada.Strings.Fixed.Trim
>               (Integer'Image(Length(Buffer)),Left));
>     end;
> end Strcat;
>
> This results in about a 100x speed up.  Is this the right way to write
> it and the code they had wrong?  In one sense, that probably is true.
> But if I use Bounded_String, the version on the website is slightly
> faster, and both versions fall midway between the fast and slow
> Unbounded versions.  (A version that just uses String is actually faster
> than the Unbounded String version.  However, I think that version is a
> bit of a cheat. ;-)

I do not see any cheat in:

with Ada.Command_Line;  use Ada.Command_Line;
with Ada.Strings.Fixed; use Ada.Strings, Ada.Strings.Fixed;
with Ada.Text_IO;       use Ada.Text_IO;

procedure Strcat is
    N: Natural;
    Hello : String := "hello" & ASCII.LF;
begin
    if Argument_Count < 1 then
       N := 10_000;
    else
       N := Natural'Value(Argument(1));
    end if;

    declare
      Buffer : String := N*Hello;
    begin
      Put_Line(Trim(Natural'Image(Buffer'Length), Left));
    end;
end Strcat;

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Rasmussen]

MSG wrote:
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
> 

Who says that? Ada can be at least as fast as C++.

/David, writing from comp.lang.c++

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Dowie]

"David Rasmussen" <david.rasmussen@gmx.net> wrote in message
news:c0aa3o$i3t$1@news.net.uni-c.dk...
> MSG wrote:
> > 3. not very performance demanding (don't know about other compilers,
> > but they say GNAT produces slow executables)
> >
>
> Who says that? Ada can be at least as fast as C++.

Different implementations of any language will produce
different results. Also, where one compiler may do a
good job with float point arithmetic, it may be lousy at
optimising.

The important thing is that there is nothing in the language
definition that _requires_ it to produce 'slow' code. One
of the design aims for Ada95 was to actually introduce
new language constructs that would actually allow faster
code to be produced, while retaining the reliability, ease
of maintenance, etc.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

Martin Dowie wrote:

> The important thing is that there is nothing in the language
> definition that _requires_ it to produce 'slow' code. One
> of the design aims for Ada95 was to actually introduce
> new language constructs that would actually allow faster
> code to be produced, while retaining the reliability, ease
> of maintenance, etc.

Not quite true.  There was an infamous feature in Ada 83 that seemed to 
require "extra" copies of vectors on certain vector processing CPUs 
without precise error checking.

I remember one time when a compiler developer for a manufacturer of such 
vector processing supercomputers called with a complex question about 
what was required and what wasn't.  We had a long discussion and she 
concluded that she could use the current Fortran back-end rules except 
for one case.

After she hung up, what she had said percolated through my head, and I 
e-mailed a short Fortran example.  Sure enough it produced garbage.  So 
yes, Ada 83 required that you not produce garbage output.  The Ada 95 
rules may be somewhat different, but they still require that you make 
temporary copies when the alternative is junk results. In fact, where 
the Ada 83 and Ada 95 rules are different is that, in Ada 83, programs 
that discarded their results were still required to get the right answer 
in some cases.  In Ada 95, you can compute wrong answers if the 
externally visible behavior of the program doesn't change. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Robert I. Eachus]

I wrote:

> After she hung up, what she had said percolated through my head, and I 
> e-mailed a short Fortran example.  Sure enough it produced garbage...

Hmmm. Trying to be terse, I may have inadvertantly slandered Fortran, or 
the (intentionally unnamed) system vendor.

The bug had nothing to do with Fortran as such.  The Fortran standard 
was just aa clear as the Ada standard in this area.  But the hardware 
vendor was working on upgrading their compiler for new hardware with a 
wider memory interface.  So what Carol said on the phone bugged me until 
I worked out an example that would determine whether there was a bug in 
their compiler, or a misunderstanding.  It turned out that the code 
worked correctly on their existing hardware, but broke on the new 
hardware.  So she fixed the optimizer, and was able to share the code 
between the Ada and Fortran front-ends.  (Unless a user defined 
floating-point type had explicit bounds.  Then the Ada code would be 
much slower, but you have to assume that the user did that intentionally.)

Incidently, I don't know why Ada compiler implementors picked me to call 
with that sort of question.  (Or maybe they called everyone looking for 
an answer they liked to some questions.)  There were three areas in the 
Ada 83 standard where everyone who was working on an Ada compiler--and 
wasn't represented on the then LMC (now ARG)--called me with the exact 
same questions.

The simplest was described as "for I in -1..10 loop..."  Yes, you were 
expected to reject that at compile time.  ("for I in Integer(-1)..10 
loop..." was okay.)  The second, was that yes it was intentional that 
the size of record objects with discriminants could change at run-time, 
but only if the discriminants had default values.  And the final one was 
that yes, elaboration of Ada generics happens at run-time not compile 
time.  This causes some major issues if you want to implement generics 
as textual substitutions.  Not that you can't do it, but there are some 
things that you have to work pretty hard to get right.

I used to joke that I could tell how the vendors were doing on their 
compilers by when they called. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic]

MSG wrote:
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
> 
I don't know how this comes up - I've used Gnat for non-realtime code 
and found its performance to be as good as most other languages compiled 
for PCs or workstations. It is, after all, just a different front end to 
the gcc compiler and so the code generation is as good as for Gnu C and 
the other languages it supports. (As always, you need to know how to use 
the compiler to get optimal results. That's true no matter what language 
you're talking about.)

BTW: I use Ada all the time for hard real time systems and its 
performance is as good or better than other languages routinely used to 
do similar jobs. I have very demanding timing requirements and very old, 
slow processors. If you get a good quality embedded Ada compiler, it 
works just fine. The "language" can't be slow if good quality 
implementations exist to prove the opposite.

So before you go reacting to rumors, I'd suggest you actually look at 
some facts about Ada. You might even get yourself some benchmark 
algorithms and test it out. That would be the scientific thing to do. 
Believing in unsubstantiated rumors is a little like believing in 
fairies & pixies because you heard someone tell a story about them.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

msg1825@yahoo.com (MSG) writes:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> 
> > Others did that allready. Besides, you would need an installed Ada compiler
> > to verify anyway.
> 
> time apt-get install gnat
> => 15 seconds

Thanks, I made that package :)

> > > 
> > > Can you do the following in Ada:
> > > 
> > > 1. Write *one* bubble-sort function that will work on different
> > >    types given an appropriate comparison function
> > 
> > Shure you can. Ada invented templates long bevore C++ was even though of.
> > Ada templates are far more powerfull then C++.
> 
> Example? 

I gave one earlier on c.l.ada.  I did not cross-post it to the other
newsgroups.

Ada templates are superior to C++ templates in several respects.  For
one thing, you can pass procedures and functions as generic
parameters, and the generic formal parameters specify the signature
for them.  Another thing is that the generic formal parameters can
specify several kinds of restrictions to types that are acceptable.

> > > 2. If B is a subtype of A, can you pass it to any function that
> > >    takes A as an argument? (covariance)
> > 
> > subtype as in object orientation:
> > 
> > type Parent is tagged null record;
> > type Child is new Parent with null record;
> 
> "null record" ? How about non-null ones? Is a 3D point (x, y, z) a
> subtype of a 2D one (x, y) ?

type Point_2D is tagged record
   X, Y : Float;
end record;

type Point_3D is new Point_2D with record
   Z : Float;
end record;

> BTW, does Ada have discriminated unions? (if you don't know what they
> are, probably none of the language you used had them)

Yes, they are called variant records.

> Also, is it possible to corrupt memory in Ada?

Yes, if you try hard enough and use Unchecked_Conversion and
System.Address instead of the more usual stuff.  Very hard in
practice.  I once tried to do a buffer overflow in Ada, and managed
it, but the code to achieve this is rather ugly.  Basically, you have
to go the extra mile to corrupt memory in Ada.

> Is it possible to leak memory in Ada?

Yes, just like in C.  However, since Ada programmers do much less
dynamic memory allocation, this happens much less often than it does
in C.  Note that there also exists a garbage collector in Ada, as part
of AdaCL.

> > or subtype as in simple types:
> > 
> > type Day_of_Month is range 1 ..  31;
> > subtype Day_of_Febuary is Day_of_Month range 1 .. 29;
> 
> That's neat.

If this is neat then dig this:

for J in Day_Of_Month loop
   exit when Month = February and then J >= Day_Of_February'Last;
   Put_Line (Day_Of_Month'Image (J));
end loop;

And think about the implications of these ranges on subprograms that
accept only a small set of integer constants as a parameter:

type Assessment is (Yes, No, Maybe, Maybe_Not);

procedure P (A : Assessment);

which is not possible in C:

typedef enum { YES, NO, MAYBE, MAYBE_NOT } assessment_t;

void P (assessment_t A) { }

int main () {
  P (42); // no compiler check!
  return 0;
}

I just tried the above with gcc -Wall and got no warning.  This means
that only a human carefully reviewing this program will see the
mistake (you may also try lint, but this is a tool external to the
language and based on heuristics, not language rules).  By contrast,
the Ada compiler catches the mistake automatically in seconds and
leaves you with the confidence that 100% of your code has been
screened for such stupid mistakes.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <m3fzdlyrh1.fsf@insalien.org>, ludovic.brenta@insalien.org 
says...

[ ... ]

> And think about the implications of these ranges on subprograms that
> accept only a small set of integer constants as a parameter:
> 
> type Assessment is (Yes, No, Maybe, Maybe_Not);
> 
> procedure P (A : Assessment);
> 
> which is not possible in C:
> 
> typedef enum { YES, NO, MAYBE, MAYBE_NOT } assessment_t;
> 
> void P (assessment_t A) { }
> 
> int main () {
>   P (42); // no compiler check!
>   return 0;
> }
> 
> I just tried the above with gcc -Wall and got no warning.

Since you're cross-posting to c.l.c++, perhaps you'd have the kindness 
to also check this as a C++ program.  If you do so, you'll find that 
either the program is rejected, or else your C++ compiler is drastically 
broken.

If you insist on only compiling it as C, at least use a good compiler.  
Comeau C (for one example) produces the following in C mode:

"enum.c", line 6: warning: enumerated type mixed with another type
    P (42); // no compiler check!
       ^
> This means that only a human carefully reviewing this program will see 
> the mistake

A fundamental mistake: assuming that one compiler's inferiority means 
something about the language itself, or even about other compilers.

> (you may also try lint, but this is a tool external to the
> language and based on heuristics, not language rules). 

I'd use a C++ compiler, and know that it was simply enforcing a 
requirement of the language.  As you can see above, even if I compiled 
it as C, it would be found.

> By contrast,
> the Ada compiler catches the mistake automatically in seconds and
> leaves you with the confidence that 100% of your code has been
> screened for such stupid mistakes.

...and there's the complacency typical of all too many Ada programmers! 
A properly functioning Ada compiler will catch _this_ stupid mistake 
just as well as a C++ compiler will -- but assuming that means it will 
catch all such stupid mistakes is taking a leap well beyond reality.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Martin Dowie]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a93b9e1697e47b4989c8c@news.clspco.adelphia.net...
> If you insist on only compiling it as C, at least use a good compiler.
> Comeau C (for one example) produces the following in C mode:
>
> "enum.c", line 6: warning: enumerated type mixed with another type
>     P (42); // no compiler check!
>        ^
> > This means that only a human carefully reviewing this program will see
> > the mistake
>
> A fundamental mistake: assuming that one compiler's inferiority means
> something about the language itself, or even about other compilers.

That's all well and good but where in the C standard is it required to
produce a warning?.. That's the bottom line - what one language throws
out as an error, another may say nothing and then the user is left to the
vagaries of what a particular vendor offers.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <c0e5su$33j$1@titan.btinternet.com>, 
martin.dowie@btopenworld.com says...

[ ... ]

> > A fundamental mistake: assuming that one compiler's inferiority means
> > something about the language itself, or even about other compilers.
> 
> That's all well and good but where in the C standard is it required to
> produce a warning?

It's not -- in some ideal world, it might be that there's a programming 
language implementation that warns you every time you do something 
wrong, but it certainly doesn't exist in this world.

I, however, never claimed that the situation with this in C was ideal by 
any means.  He claimed that because it wasn't caught by one compiler, 
that this proved it could only ever be caught by human examination.  I 
proved that wrong.

> .. That's the bottom line - what one language throws
> out as an error, another may say nothing and then the user is left to the
> vagaries of what a particular vendor offers.
 
Rarely true and irrelevant on the rare occasion that it is.  Comparing 
the languages only makes sense when both are available for the target 
platform.  If a particular target is so obscure that it truly leaves to 
the vagaries of a particular vendor (i.e. there's only one C compiler 
for it) then there's basically no chance of finding even one Ada 
compiler for the platform.  As such, Ada is useless relative to that 
platform, regardless of how much merit it might have in theory.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Chad R. Meiners]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
> If a particular target is so obscure that it truly leaves to
> the vagaries of a particular vendor (i.e. there's only one C compiler
> for it) then there's basically no chance of finding even one Ada
> compiler for the platform.  As such, Ada is useless relative to that
> platform, regardless of how much merit it might have in theory.

Not exactly true.  There exist Ada to ANSI C compilers so you can make use
of Ada's compile time benefits for such platforms.

-CRM

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <c0esdi$63s$1@msunews.cl.msu.edu>, crmeiners@hotmail.com 
says...
> 
> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> > If a particular target is so obscure that it truly leaves to
> > the vagaries of a particular vendor (i.e. there's only one C compiler
> > for it) then there's basically no chance of finding even one Ada
> > compiler for the platform.  As such, Ada is useless relative to that
> > platform, regardless of how much merit it might have in theory.
> 
> Not exactly true.  There exist Ada to ANSI C compilers so you can make use
> of Ada's compile time benefits for such platforms.

Also rarely true -- for better or worse, the "ANSI C" compilers on many 
obscure (especially embedded) systems are "ANSI C" only by courtesy -- 
they're generally enough like C that it's easy for a reasonably 
experienced programmer to learn and live with their restrictions, but 
unless the translator in question uses quite a restricted portion of C, 
there's still a pretty good chance that what it produces won't be 
accepted by the "C compiler" in question.

In many cases, the editing that would be involved to make it work would 
theoretically be pretty trivial.  Unfortunately, that fact that it's 
machine-generated code prevents almost anything from being trivial -- 
such code is usually opaque in the extreme.  Worse, this route places 
even higher demands on the programmers: they have to know Ada to write 
the original code, AND they have to know C to edit the output of the 
translator.  Worse, the problems involved are often in relatively 
obscure corners of the language that few programmers would ever delve 
into, so they can't just be reasonably good C programmers either: they 
have to be exceptionally knowledgeable and well-informed ones.

The bottom line is that an Ada to C translator could be useful under 
some circumstances, but in the situation that was being described, it's 
likely to be far more of a problem than a solution.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Chad R. Meiners]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a9555bd517ba66d989c91@news.clspco.adelphia.net...
> > > As such, Ada is useless relative to that
> > > platform, regardless of how much merit it might have in theory.
> >
> > Not exactly true.  There exist Ada to ANSI C compilers so you can make
use
> > of Ada's compile time benefits for such platforms.
>
> Also rarely true

Even if it is rarely true, it proves that your above statement is false.
Perhaps that is not what you intended to say, but it is what you wrote.

> -- for better or worse, the "ANSI C" compilers on many
> obscure (especially embedded) systems are "ANSI C" only by courtesy --

courtesy?  An ANSI C compiler that doesn't compile ANSI C is incorrect.

<snip>

> In many cases, the editing that would be involved to make it work would
> theoretically be pretty trivial.

In the trivial cases the backend for the translator can be modified by the
vendor.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <c0h781$27a9$1@msunews.cl.msu.edu>, crmeiners@hotmail.com 
says...
> 
> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> news:MPG.1a9555bd517ba66d989c91@news.clspco.adelphia.net...
> > > > As such, Ada is useless relative to that
> > > > platform, regardless of how much merit it might have in theory.
> > >
> > > Not exactly true.  There exist Ada to ANSI C compilers so you can make
> > > use of Ada's compile time benefits for such platforms.
> >
> > Also rarely true
> 
> Even if it is rarely true, it proves that your above statement is false.
> Perhaps that is not what you intended to say, but it is what you wrote.

More or less accurate, so to summarize the situation: there are quite a 
few platforms for which no Ada compiler exists, and no completely 
conforming C compiler exists to act as the target of an Ada to C 
translator.

There may be (though I've never confirmed it) a small number of 
platforms for which there is no native Ada compiler, but the C compiler 
is able to act as the target of an Ada to C translator.

There are also (of course) quite a few platforms for which native 
compilers for both Ada and C are available.

> > -- for better or worse, the "ANSI C" compilers on many
> > obscure (especially embedded) systems are "ANSI C" only by courtesy --
> 
> courtesy?  An ANSI C compiler that doesn't compile ANSI C is incorrect.

That's not entirely true: the C standard defines two types of systems: 
standalone implementations and hosted implementations.  A typical 
compiler for UNIX, Windows, etc., is a hosted implementation, which 
includes the whole standard library.  A typical compiler for an embedded 
system is a standalone implementation, which excludes essentially the 
entire library and most of the standard headers.

I wouldn't want to go on record as saying it's truly _impossible_ to 
implement an Ada to C translator that doesn't require parts of the 
standard library, but rather doubt such a thing exists.

> > In many cases, the editing that would be involved to make it work would
> > theoretically be pretty trivial.
> 
> In the trivial cases the backend for the translator can be modified by the
> vendor.

Maybe -- or maybe not.  First you have to get the vendor to cooperate.  
Second, you have to read through the (usually mind-bendingly horrible) C 
it has produced to try to figure out what's going wrong.  Third, you 
have to figure out how to make that work with the compiler in question.

Theoretically, this might be trivial.  In fact, not even one of those 
three steps is likely to be trivial in practice, and the concatenation 
of all three is likely to be anything but.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]


"Jerry Coffin" <jcoffin@taeus.com> a �crit dans le message de news:MPG.1a960be69bef079d989c9c@news.clspco.adelphia.net...
> Second, you have to read through the (usually mind-bendingly horrible) C
> it has produced to try to figure out what's going wrong.
The compiler in question is made by Sofcheck (http://www.sofcheck.com:5050), and they claim that it generates human-readable code.
Tuck, are you here?

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Peter Amey]

Jean-Pierre Rosen wrote:
> "Jerry Coffin" <jcoffin@taeus.com> a �crit dans le message de news:MPG.1a960be69bef079d989c9c@news.clspco.adelphia.net...
> 
>>Second, you have to read through the (usually mind-bendingly horrible) C
>>it has produced to try to figure out what's going wrong.
> 
> The compiler in question is made by Sofcheck (http://www.sofcheck.com:5050), and they claim that it generates human-readable code.
> Tuck, are you here?
> 

Last time I spoke to Tuck he said he didn't follow c.l.a regularly.  The 
compiler does exist 'though.  We have had some good experiences using it 
with SPARK to target processors that don't have an Ada cross-compiler. 
Our Ada Europe paper "High Integrity Ada in a UML and C World" will 
reveal all.

Peter

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <60bi0c.ppg.ln@skymaster>, rosen@adalog.fr says...

[ ... ]

> The compiler in question is made by Sofcheck (http://www.sofcheck.com:5050), 
> and they claim that it generates human-readable code.

I guess I'll have to take your word for that -- the URL you gave above 
doesn't seem to work for me.  Maybe it'll only work for browsers written 
in Ada. :-)

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Randy Brukardt]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a97636642574457989ca0@news.clspco.adelphia.net...
> In article <60bi0c.ppg.ln@skymaster>, rosen@adalog.fr says...
>
> [ ... ]
>
> > The compiler in question is made by Sofcheck
(http://www.sofcheck.com:5050),
> > and they claim that it generates human-readable code.
>
> I guess I'll have to take your word for that -- the URL you gave above
> doesn't seem to work for me.  Maybe it'll only work for browsers written
> in Ada. :-)

The correct URL is http://www.sofcheck.com (which will redirect to another
on port 5055 [not 5050 as above]). But I can't get to their site from my
desk either; I have to go use the web server in the DMZ. The problem is that
the non-standard port confuses the web proxy that I'm using. If you have a
direct net connection, it works fine.

                    Randy.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> news:MPG.1a97636642574457989ca0@news.clspco.adelphia.net...
>>In article <60bi0c.ppg.ln@skymaster>, rosen@adalog.fr says...
>>[ ... ]
>>>The compiler in question is made by Sofcheck
> 
> (http://www.sofcheck.com:5050),
> 
>>>and they claim that it generates human-readable code.
>>
>>I guess I'll have to take your word for that -- the URL you gave above
>>doesn't seem to work for me.  Maybe it'll only work for browsers written
>>in Ada. :-)
> 
> The correct URL is http://www.sofcheck.com (which will redirect to another
> on port 5055 [not 5050 as above]). But I can't get to their site from my
> desk either; I have to go use the web server in the DMZ. The problem is that
> the non-standard port confuses the web proxy that I'm using. If you have a
> direct net connection, it works fine.
> 
>                     Randy.

Many company's firewalls will block unusual ports like this.
I'd have to try this port from home, since the FW here at
work is quite restrictive.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]


"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> a �crit dans le message de news:O6NYb.6431$Cd6.542123@news20.bellglobal.com...
> > The correct URL is http://www.sofcheck.com (which will redirect to another
> > on port 5055 [not 5050 as above]). But I can't get to their site from my
> > desk either; I have to go use the web server in the DMZ. The problem is that
> > the non-standard port confuses the web proxy that I'm using. If you have a
> > direct net connection, it works fine.
> >
> >                     Randy.
>
> Many company's firewalls will block unusual ports like this.
> I'd have to try this port from home, since the FW here at
> work is quite restrictive.

So does mine. I talked to that with Tuck, and he said it was due to a silly restriction from his ISP, but that he will be changing
ISP soon.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a9555bd517ba66d989c91@news.clspco.adelphia.net...
> In article <c0esdi$63s$1@msunews.cl.msu.edu>, crmeiners@hotmail.com
> says...
> >
> The bottom line is that an Ada to C translator could be useful under
> some circumstances, but in the situation that was being described, it's
> likely to be far more of a problem than a solution.

This is a description of the C-path compiler solution used for other
languages,
most notably, Eiffel.  I believe Tucker Taft's Ada compiler uses this
approach,
and Irvine Compiler Corporation used to do this, but I'm not sure if they
still
do.

C-Path compilers have their own problems.   The most well-known is the
infamous "integer overflow" problem.   I recall that Tucker worked hard to
eliminate this problem in his compiler (so it would pass validation).   I'm
not
sure what other compiler publishers are doing to avoid such problems, but
as long as we require conformance testing (along with other kinds of
testing)
for Ada compilers chosen for weapons systems, we avoid some of those
issues.

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Peter Amey]

Richard Riehle wrote:

[snip]
> 
> C-Path compilers have their own problems.   The most well-known is the
> infamous "integer overflow" problem.   I recall that Tucker worked hard to
> eliminate this problem in his compiler (so it would pass validation).   I'm
> not
> sure what other compiler publishers are doing to avoid such problems, but
> as long as we require conformance testing (along with other kinds of
> testing)
> for Ada compilers chosen for weapons systems, we avoid some of those
> issues.

One of the nice properties of SPARK to C translation (to be described in 
our Ada Europe 2004 paper) is that we can constuct a proof at the SPARK 
level that all the numeric ranges will fit into the C types to which 
they will map and that overflows will therefore not occur.

Peter

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Warren W. Gay VE3WWG]

Richard Riehle wrote:

> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> news:MPG.1a9555bd517ba66d989c91@news.clspco.adelphia.net...
> 
>>In article <c0esdi$63s$1@msunews.cl.msu.edu>, crmeiners@hotmail.com
>>says...
>>
>>The bottom line is that an Ada to C translator could be useful under
>>some circumstances, but in the situation that was being described, it's
>>likely to be far more of a problem than a solution.
> 
> This is a description of the C-path compiler solution used for other
> languages,
> most notably, Eiffel.  I believe Tucker Taft's Ada compiler uses this
> approach,
> and Irvine Compiler Corporation used to do this, but I'm not sure if they
> still
> do.
...
> Richard Riehle

It would be useful to have such an Open Sourced version of the same
(or a flavour of GNAT). It could then be used as a bootstrap
compiler for GNAT on new platforms. You would of course have to
do a lot of Ada runtime library support at the C level as well,
but for a bootstrap compiler, this could be minimized I think.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

Jerry Coffin <jcoffin@taeus.com> writes:

> In article <c0e5su$33j$1@titan.btinternet.com>, 
> martin.dowie@btopenworld.com says...
> 
> [ ... ]
> 
> > > A fundamental mistake: assuming that one compiler's inferiority means
> > > something about the language itself, or even about other compilers.
> > 
> > That's all well and good but where in the C standard is it required to
> > produce a warning?
> 
> It's not -- in some ideal world, it might be that there's a programming 
> language implementation that warns you every time you do something 
> wrong, but it certainly doesn't exist in this world.
> 
> I, however, never claimed that the situation with this in C was ideal by 
> any means.  He claimed that because it wasn't caught by one compiler, 
> that this proved it could only ever be caught by human examination.  I 
> proved that wrong.

No, I was comparing languages not compilers.  As stated elsewhere, the
C language does not require any compiler to catch the particular bug I
used as an example.  If your compiler does, good for you, but the C
language says you cannot assume it will.  What your compiler did was
akin to "lint", which I referred to as using heuristics, not language
rules.  Heuristics means that so many people were hurt by this bug
before that it seemed like a good idea to try and catch it at compile
(or "lint") time.

The Ada language mandates that all Ada compilers must catch this bug.
This gives much more confidence in Ada than in C.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <m3ptck662y.fsf@insalien.org>, ludovic.brenta@insalien.org 
says...

[ ... ]

> No, I was comparing languages not compilers.  

That may have been what you _intended_, but here's what you actually 
_said_:

	I just tried the above with gcc -Wall and got no warning.  
	This means that only a human carefully reviewing this program
	will see the mistake

I was addressing that statement, and proved it wrong.  Worse than simply 
being wrong, however, is the fallacious reasoning it represents.  You 
claim that a single example proves an entire class.  I honestly don't 
want to turn this into a personal attack, but it's difficult to take any 
of your opinions seriously when you apparently lack all grasp of logic 
or reasoning.

> As stated elsewhere, the
> C language does not require any compiler to catch the particular bug I
> used as an example.  If your compiler does, good for you, but the C
> language says you cannot assume it will.  What your compiler did was
> akin to "lint", which I referred to as using heuristics, not language
> rules.  Heuristics means that so many people were hurt by this bug
> before that it seemed like a good idea to try and catch it at compile
> (or "lint") time.

Rather the contrary: it gets caught because it's trivial to catch, and 
the market for C compilers is sufficiently competitive that nearly every 
vendor is constantly working at adding features, especially those that 
are easy to implement.
 
> The Ada language mandates that all Ada compilers must catch this bug.
> This gives much more confidence in Ada than in C.

It may give you "much more confidence in Ada", but if so, it's precisely 
the false sense of security I've pointed out a number times before. If 
you were being realistic, this would increase your confidence in Ada 
over C by approximately the number of real bugs it catches.

In my experience that would be well under one part per million -- 
probably closer to one part per billion.  I've a pretty fair amount of 
experience, and I've yet to see a real bug like this.  I don't think it 
hurts anything for the compiler to catch it, but the degree of 
confidence it should inspire is exceptionally minimal.

The sad part is that Ada is a good enough language that it deserves a 
much better defense than you're giving it.  Ada provides features that 
really can (and do) help prevent bugs that are much more common in C. 
Unfortunately, every indication you've given so far in this thread is 
that you lack sufficient insight into either language to recognize those 
areas and base your arguments on them.

On a slightly different subject, given that this is cross-posted to 
c.l.ada and c.l.c++, if you're going to advocate Ada as being superior, 
the comparison should clearly be to C++ rather than C.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Rob Thorpe]

Ludovic Brenta <ludovic.brenta@insalien.org> wrote in message news:<m3fzdlyrh1.fsf@insalien.org>...
...
> which is not possible in C:
> 
> typedef enum { YES, NO, MAYBE, MAYBE_NOT } assessment_t;
> 
> void P (assessment_t A) { }
> 
> int main () {
>   P (42); // no compiler check!
>   return 0;
> }

In C enums are interchangable with ints so there is no error, though
there maybe the compiler should give a warning.

A C++ compiler should check
I got:

bash-2.05b$ g++ -Wall fiddle.cpp
fiddle.cpp: In function `int main()':
fiddle.cpp:6: error: invalid conversion from `int' to `assessment_t'

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Chris Torek]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]

(I restricted this to just the two groups, although comp.lang.c only
might be even more appropriate.  The article quoted first below is
not available to me so I have only the quotes themselves.)

>Ludovic Brenta <ludovic.brenta@insalien.org> wrote in message
>news:<m3fzdlyrh1.fsf@insalien.org>...
>> which is not possible in C:
>> 
>> typedef enum { YES, NO, MAYBE, MAYBE_NOT } assessment_t;
>> 
>> void P (assessment_t A) { }
>> 
>> int main () {
>>   P (42); // no compiler check!
>>   return 0;
>> }

In article <news:1a61f7e5.0402111131.2667fa6@posting.google.com>
Rob Thorpe <robert.thorpe@antenova.com> writes:
>In C enums are interchangable with ints so there is no error, though
>there maybe the compiler should give a warning.

More precisely, while "enum" <typename> "{" <id-list> "}" defines
a new enumerated type, the members of the id-list are simply ordinary
integral constants, and the enumerated type is "compatible with"
an integral type (which one is not specified, and different enums
might choose different integral types, so that a "small" enum is
stored in a char while a "big" one uses an int).  As such, enum
types are not as useful as one might hope.

Note that the "typedef" keyword is a red herring: as with so many
of C's keywords, it means the opposite of what it claims. :-)  In
this case it means "do not define a new type named assessment_t;
define assessment_t as an alias for the type this identifier would
have if this were not a typedef".  For instance, "typedef int A,
*B;" makes A a synonym for "int" and B a synonym for "int *".

C's most useful type-definer is actually the "struct" keyword, which
is perhaps best thought of as standing for "STRange spelling for
User-defined abstraCt Type".  (Or you can just read it as a weird
way to spell the word "type".  All new types are thus record types.)
The sequence:

    struct assessment_t { int value; };

defines a new type named "struct assessment_t", after which:

    void P(struct assessment_t A) { }

    int main(void) {
        P(42); /* draws a diagnostic */
        return 0;
    }

To get constants of type "struct assessment_t" requires C99:

    #define AS_T_YES ((const struct assessment_t) { 42 })
    #define AS_T_NO ((const struct assessment_t) { 99 })
    #define AS_T_MAYBE ((const struct assessment_t) { 1 })
    #define AS_T_MAYBE_NOT ((const struct assessment_t) { -1 })

Of course, these macros live in a largely-uncontrolled name space
(their scope starts after the #define and ends only at the end of
the translation unit or a corresponding #undef).

Note that the "obvious" method of defining constants:

    const struct assessment_t AS_T_YES = { 42 };

does not define a constant at all, because in C (but not C++), the
"const" keyword, in keeping with tradition :-) , means "do not
define a constant; instead, make this ordinary variable read-only".
On the other hand, one can use pointers to application-wide read-only
variables as a way to fake constants, but then P() needs to take
a "struct assessment_t *".  C99's aggregate constructors are probably
better, where available.

(The "const" in the aggregate constructor constants above tells
the C compiler that it is allowed to use a single, read-only object
to store the resulting aggregate, if its address is taken.  If the
address is never taken the "const" is not really required, but it
could generate slightly better code on some compilers.  The need
to take aggregates' addresses arises because of C's peculiar
treatment of arrays.)

(Ada folks reading this might get the impression that I dislike C.
This is not the case -- I just think it is "so ugly it's cute", as
it were, the way a former girlfriend of mine thought of various
animals.  But there is no denying that C is full of sharp edges
and odd mannerisms, and that it is easier to get good compile-time
testing with Ada.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Preben Randhol]

On 2004-02-08, MSG <msg1825@yahoo.com> wrote:
> Also, is it possible to corrupt memory in Ada?

"... in Ada, you can never have a buffer overflow error. Unless of
course you go very far out of your way to specifically program one
[...] most Ada programmers would consider going out of your way to
construct an Ada program that had a potential buffer overflow not
as a challenge, but as a kind of pornography." 

      - Robert I. Eachus

> Is it possible to leak memory in Ada?

Sure, if that is what you want to do... I wouldn't advice it though.

Preben
-- 
                 �For me, Ada95 puts back the joy in programming.�

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Jerry Coffin]

In article <2460735.u7KiuvdgQP@linux1.krischik.com>, 
krischik@users.sourceforge.net says...

[ ... ]

> Shure you can. Ada invented templates long bevore C++ was even though of.

It's clearly true that Ada had generics before C++ did, but not (it 
would appear) before Bjarne had started to come up with the ideas for 
what eventually came to be known as C++.  In point of fact, Bjarne seems 
to have started working toward C++ around the time of the Ironman 
document, which clearly predates the final Ada design.

Ada didn't invent generic programming either -- just for example, Lisp 
has supported generic programming (to some degree or other) since about 
1959 or so.  Many have argued over how sanitary all its facilities are, 
but the fact remains that the basic idea clearly predates Ada by quite a 
wide margin.

> Ada templates are far more powerfull then C++.

Experience tends to indicate otherwise.  In point of fact, Alexander 
Stepanov had a great deal of input into the design of templates in C++, 
largely because Ada generics didn't support what he wanted.

Other large projects have reflected the same difference. Just for 
example, the Booch components started out in Ada 83, got ported to C++, 
and then ported back to Ada (95). The original Ada version was ~125,000 
lines of code.  The C++ version was about 12,000 lines of code.  

It's easy to find estimates that the Ada 95 version should be about 
10,000 lines of code.  For better or worse, these seem to be incorrect: 
the current version of BC for Ada 95 seems to some out somewhere between 
15,000 and 18,000 non-comment, non-blank lines of code.  I haven't had 
the time to go through in detail, but it _appears_ that even so, there 
are still some missing pieces.  I think it's also worth noting that C++ 
templates have changed (and understanding of them has improved) 
considerably since the Booch components were ported to C++.  If the same 
job were being done today, line counts and such would undoubtedly be 
somewhat different.

I AM reasonably convinced, however, that Ada generics are more 
_accessible_, so they provide more power to a typical programmer. Using 
more than a fraction of the capabilities of C++ templates requires 
substantially more study.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Pat Rogers]

Jerry Coffin wrote:
[snip]
> Other large projects have reflected the same difference. Just for
> example, the Booch components started out in Ada 83, got ported to
> C++, and then ported back to Ada (95). The original Ada version was
> ~125,000 lines of code.  The C++ version was about 12,000 lines of
> code.

Neither the design of the C++ version of the Ada 83 BCs, nor that of
the Ada 95 version, corresponded to the design of the Ada 83 version.
It is useless to compare the numbers of different designs.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Richard Riehle]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.1a93af8d8189b567989c8a@news.clspco.adelphia.net...
> In article <2460735.u7KiuvdgQP@linux1.krischik.com>,
> krischik@users.sourceforge.net says...

In response to the earlier assertion that, >
> > Ada templates are far more powerfull then C++.
>
> Experience tends to indicate otherwise.  In point of fact, Alexander
> Stepanov had a great deal of input into the design of templates in C++,
> largely because Ada generics didn't support what he wanted.
>
> Other large projects have reflected the same difference. Just for
> example, the Booch components started out in Ada 83, got ported to C++,
> and then ported back to Ada (95). The original Ada version was ~125,000
> lines of code.  The C++ version was about 12,000 lines of code.

A issue with Ada 83 generics was the inability to design with generic formal
package parameters.   In this respect, C++ had a significant edge in the
design
of reusable templates.   With Ada 95, this problem was resolved.

There are still some features of C++ templates that one does not find in
Ada,
but those features are just complicated enough that a designer can make some
entertaining mistakes that fail the understandability test.

Another important point is the difference in the goals of Ada and C++.   For
Ada,
we continue to focus on the issue of maximizing the amount of error checking
that
can be accomplished at compile-time.   While C++ continues to improve in
this
respect, it also still falls short of what Ada can do to satisfy this goal.
That being
said, the goal itself has produced some rules that are also difficult to
understand,
particularly when considering generic formal package parameters.   I have
covered
this topic in Ada Distilled with a simple fully-coded example that some
programmers
have found useful in making the concept accessible.

Richard Riehle

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

Ludovic Brenta wrote:

> The third type is what I would call the "zen master" type of
> languages.  They treat you like an apprentice, slapping you on the
> hand each time you make a small mistake, and they scorn at you for
> choosing the quick and easy path -- which leads to the Dark Side.  If
> you accept their teachings, you quickly become a Master yourself.
No, this way you have a little chance for that. Following this way you'll
most probably become more or less respectable member of the guild, a master,
but not Master. Just because you are deprived from Dark Side, and every Master
must know it from good personal experience (some manage to get it from their
own imagination, but this is very rare case, as it requires exceptionally
strong imagination abilities... and exceptional abilities for keeping mental
balance as well).

> If you rebel against them,
Actually you must rebel against something if you want to achieve anything 
significantly above average. Surely, it isn't necessary to rebel against your
master personally, but a rebellion against some widespread and respectable
opinion is almost inevitable for such a "graduation".

> you will never achieve Enlightenment and will always produce bugs.
You will produce bugs anyway, with or without Enlightenment -;) . And I'm
afraid that in this your description Enlightenment doesn't seem different
from Doctrine -;) .

>  The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.
I don't think so - there is vast amount of various "zens" and "zen masters"
for C++, Java... Smalltalk, Lisp, etc (even COBOL had at least one "zen", and
I remember that it was a good one). And all those "zen masters" feel themselves
quite comfortable with their accustomed languages.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sat, 07 Feb 2004 14:00:35 +0100, Ludovic Brenta wrote:

> Of course, this is a lie, because programming is inherently
> difficult and no language can make it easy. 

That's exactly what the assembly language programmers said about the
first Fortran compiler, and it's equally wrong now. Sure, there are cases
where you need to run DSP code and coordinate with the home base thirty
million miles away using one space-hardened 386, and that's hard. Then
there's the cases where you need two lines of shell to simplify moving
files around, and that's something assembly or Fortran or Ada or Java
would make much more complex then it is.

> (like e.g. memory management.  If some Java
> "guru" reads this, ask yourself this one question: how many threads
> does your program have, and please justify the existence of each
> thread).

In the Jargon file, there's a story of a man who bummed every cycle out of
a poker program, even the initialization code, who spurned assembly
language because it was too inefficient. How would you explain your choice
of programming language to him? Who cares if there's a couple extra
threads running? You make a big deal about languages that protect you
against buffer overflows, why not use a language that protects you against
memory leaks?

> The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.

Pascal is hardly usable, unless you use one of a dozen proprietary
extensions. That's hardly "zen master".

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Ludovic Brenta]

David Starner <dvdeug@email.ro> writes:

> On Sat, 07 Feb 2004 14:00:35 +0100, Ludovic Brenta wrote:
> 
> > Of course, this is a lie, because programming is inherently
> > difficult and no language can make it easy. 
> 
> That's exactly what the assembly language programmers said about the
> first Fortran compiler, and it's equally wrong now. Sure, there are cases
> where you need to run DSP code and coordinate with the home base thirty
> million miles away using one space-hardened 386, and that's hard. Then
> there's the cases where you need two lines of shell to simplify moving
> files around, and that's something assembly or Fortran or Ada or Java
> would make much more complex then it is.

If you call this programming, then you're right.  Scripting languages
do have a place and purpose.  I was more concerned with large-scale,
real-world programming, where Ada shines but is being ignored by too
many people.  I was only trying to explain to myself why.  I stand by
my claim that no language can make programming easy.  But a language
help you find, or avoid, bugs.

> > (like e.g. memory management.  If some Java
> > "guru" reads this, ask yourself this one question: how many threads
> > does your program have, and please justify the existence of each
> > thread).
> 
> In the Jargon file, there's a story of a man who bummed every cycle out of
> a poker program, even the initialization code, who spurned assembly
> language because it was too inefficient. How would you explain your choice
> of programming language to him?

I would ask him, "would you trust your own life to your program"?

> Who cares if there's a couple extra threads running? You make a big
> deal about languages that protect you against buffer overflows, why
> not use a language that protects you against memory leaks?

Because I want to control exactly how much memory my program uses, and
I want to know exactly how many "a couple" means, and why these
"couple" threads are necessary.  You referred to embedded software for
space-bound devices, this is one area where these questions are really
important.  I am willing to accept run-time inefficiency and "a couple
extra threads" if justified.  There are some languages that force
these upon you and won't justify this cost.

> > The "zen master" languages are Pascal, Modula,
> > Oberon, and, master of masters, Ada.
> 
> Pascal is hardly usable, unless you use one of a dozen proprietary
> extensions. That's hardly "zen master".

That is true, but I meant "master" in the sense of "teacher".  Pascal
was quite good at teaching, and as a "master" it had quite a lot of
apprentices.

-- 
Ludovic Brenta.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sun, 08 Feb 2004 02:00:01 +0100, Ludovic Brenta wrote:

> I was more concerned with large-scale,
> real-world programming, where Ada shines but is being ignored by too
> many people. 

Ah, so that wasn't in the real world. Thanks for clarifying that.

> I was only trying to explain to myself why.  I stand by
> my claim that no language can make programming easy.  But a language
> help you find, or avoid, bugs.

But that's not the goal of programming. The goal of programming is to
produce programs that get the job done. There are certainly languages that
remove the concern about memory usage, and allow you to easily handle
strings and databases and GUIs, and these languages certainly do make it
easier to solve certain classes of programs. If they're slower and take
more memory, no one cares. If they have a few bugs, well, they get worked
around. 
 
> I would ask him, "would you trust your own life to your program"?

He would tell you of course, and ask you how you could trust your life to
a program automatically produced by a compiler you know to be buggy.

I might point out that his program doesn't require that you trust your
life to it. Not everything is life and death, and a lot of things require
writing the program quickly or having the program run quickly over
absolute correctness.
 
> Because I want to control exactly how much memory my program uses, 

So you're anal. There are very few programs that push my computer, with
300 MB of RAM to swap. Worrying about 10% memory usage on the rest in
exchange for occasional crashes is not a good tradeoff. 

> You referred to embedded software for
> space-bound devices, this is one area where these questions are really
> important. 

Yes, but you missed the point. That's one class of software, and
there's probably not a million lines of code written a year for that
class; probably not one percent of the code written for PCs with 1 GB of
memory that won't use over a few MB in practice.

> There are some languages that force these
> upon you and won't justify this cost.

But you aren't the one being asked to justify it; you are telling other
programmers that it's unjustified. Perhaps the inefficiency is justified
to them.

> Pascal
> was quite good at teaching, and as a "master" it had quite a lot of
> apprentices.

Java has a lot of apprentices, too. Pascal has something to do with the
number of people who refused to look at Ada, in the way that it forced
everyone into this tiny box, without modules or generics or bit twiddling
and all in one file.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

David Starner wrote:

> The goal of programming is to produce programs that get the job done.

Your employer must be satisfied with that statement -:) , but as you put it
here instead of your resume, I must tell you that this statement is severely
flawed. Programming is not covered by compilation and scripting. Generally,
major part of programming is to define precisely and formally, *what* is the
job, and what does it mean that this job *is done*. For a compilation-like job
both definitions are prerequisites, and for scripting some imprecise and
informal understanding of them very often is enough, but for other flavours
of programming this is major part of the goal.

(As an exercise you may try to define that - what is the job and what means
that this job is done - for a "good text editor"... better to do that exercise
within a group of your fellow programmers -:) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[David Starner]

On Sun, 08 Feb 2004 19:02:50 +0300, Alexandre E. Kopilovitch wrote:

> David Starner wrote:
> 
>> The goal of programming is to produce programs that get the job done.
> 
> [...] I must tell you that this statement is severely
> flawed. Programming is not covered by compilation and scripting. Generally,
> major part of programming is to define precisely and formally, *what* is the
> job, and what does it mean that this job *is done*. 

And once you have the program at a state where it needs no more
programming, all that goes into a drawer and disappears. That is part of
what needs to be done to get a program that gets the job done, but that's
not part of the goal; that's part of the process.

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Alexandre E. Kopilovitch]

David Starner wrote:

> >> The goal of programming is to produce programs that get the job done.
> > 
> > [...] I must tell you that this statement is severely
> > flawed. Programming is not covered by compilation and scripting. Generally,
> > major part of programming is to define precisely and formally, *what* is the
> > job, and what does it mean that this job *is done*. 
>
> And once you have the program at a state where it needs no more
> programming, all that goes into a drawer and disappears.

That may be true for programs with short lifecycles and no (or very little)
maintenance anticipated (but even for those kind of programs that isn't always
true). But here in comp.lang.ada newsgroup we speak primarily about Ada language,
which was designed specifically for applications with long lifecycles and
substantial amount of maintenance. In such circumstances permanent tracking
of the meaning of "job" and "is done" for the application is necessary. 

> That is part of
> what needs to be done to get a program that gets the job done, but that's
> not part of the goal; that's part of the process.

When you expect long lifecycle and much maintenance, the relations between
the goal and the process aren't so simple and straitforward. In fact, providing
good support for a long process is a major part of the goal.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Nick Landsberg]

David Starner wrote:

> On Sat, 07 Feb 2004 14:00:35 +0100, Ludovic Brenta wrote:
> 
> 
>>Of course, this is a lie, because programming is inherently
>>difficult and no language can make it easy. 
> 
> 
> That's exactly what the assembly language programmers said about the
> first Fortran compiler, and it's equally wrong now. Sure, there are cases
> where you need to run DSP code and coordinate with the home base thirty
> million miles away using one space-hardened 386, and that's hard. Then
> there's the cases where you need two lines of shell to simplify moving
> files around, and that's something assembly or Fortran or Ada or Java
> would make much more complex then it is.
> 
> 
>>(like e.g. memory management.  If some Java
>>"guru" reads this, ask yourself this one question: how many threads
>>does your program have, and please justify the existence of each
>>thread).
> 
> 
> In the Jargon file, there's a story of a man who bummed every cycle out of
> a poker program, even the initialization code, who spurned assembly
> language because it was too inefficient. How would you explain your choice
> of programming language to him? Who cares if there's a couple extra
> threads running? You make a big deal about languages that protect you
> against buffer overflows, why not use a language that protects you against
> memory leaks?

"Who cares it there's an extra couple of threads running?" you ask.
I do!  I work on systems which are required to process thousands
of requests per second.  Unnecessary threads (just because the language
makes it easy to create them), waste precious CPU cycles.  (But that's
OT in c.l.c, I think).

If your last statement refers to Java protecting you against memory
leaks, then you have a surprise in store for you.
If it protects you against memory leaks why is there a need for
a garbage collector in the first place?
I have found many situations where the garbage collector did
not clear unused memory.  The garbage collector is just as
buggy as any other code.  (This is also OT in the c.l.c group.
and I don't want to subsribe to c.l.java :)



> 
> 
>>The "zen master" languages are Pascal, Modula,
>>Oberon, and, master of masters, Ada.
> 
> 
> Pascal is hardly usable, unless you use one of a dozen proprietary
> extensions. That's hardly "zen master".
> 

-- 
Ñ
"It is impossible to make anything foolproof because fools are so 
ingenious" - A. Bloch