RE: One language environment don't have future

RE: One language environment don't have future

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Karel Miklav [mailto:karel@inetis.spppambait.com]

> The IT tower of Babel may never be built, but UML and tools around it 
> are a step forward. And there is a difference between modeling and 
> coding; I guess we're not going to rewrite data structures in all sorts 
> of languages forever? Or watch compilers #%@! us with cryptic messages? 
> There must be evolution even in IT.

Wasn't (or isn't) that the goal of CASE tools?  Of course, the CASE tools
would need to evolve more to go from design to implementation.

I haven't kept up with the current state of the CASE tools, but most of them
were trying to use a graphical interface tool to draw your system on the
screen and then produce compilable software components.

The ultimate evolution of the CASE tools would be to draw something on the
screen and have it spit out a working executable.  I guess you would have a
"primitive" (or base) set of components and data structures with which to
build all others necessary for developing your target product.  The problem
someone else eluded to was, what do you do when a new data structure is
required which cannot be built from your primitive or composite sets?  Then
someone has to go in with the language used to build the CASE tool and
add the new structure(s).  Unless the CASE tool can be used to build the new
components or data structures for itself (the Cobol compiler to build a
Cobol compiler approach).

Just thinking out loud.

Frank

Re: One language environment don't have future

[Karel Miklav]

I'm starting to sound like a certain R-company promoter, but as Grady 
Booch said about objects and patterns: "no class is an island, but 
rather that all interesting, well-structured object-oriented systems 
consist of societies of classes." The point in evolution of knowledge is 
to compress it in the sense of complexity, to make it appear plain simple.

As every possible combination of assembly instructions didn't come out 
practical, people invented higher level languages. And even though that 
may not be the reason there shure is a limit in practical societies of 
classes and their tweakable parameters.

Beard, Frank Randolph CIV wrote:
> From: Karel Miklav
>>The IT tower of Babel may never be built, but UML and tools around it 
>>are a step forward. And there is a difference between modeling and 
>>coding; I guess we're not going to rewrite data structures in all sorts 
>>of languages forever? Or watch compilers #%@! us with cryptic messages? 
>>There must be evolution even in IT.
> 
> Wasn't (or isn't) that the goal of CASE tools?  Of course, the CASE tools
> would need to evolve more to go from design to implementation.
> 
> I haven't kept up with the current state of the CASE tools, but most of them
> were trying to use a graphical interface tool to draw your system on the
> screen and then produce compilable software components.
> 
> The ultimate evolution of the CASE tools would be to draw something on the
> screen and have it spit out a working executable.  I guess you would have a
> "primitive" (or base) set of components and data structures with which to
> build all others necessary for developing your target product.  The problem
> someone else eluded to was, what do you do when a new data structure is
> required which cannot be built from your primitive or composite sets?  Then
> someone has to go in with the language used to build the CASE tool and
> add the new structure(s).  Unless the CASE tool can be used to build the new
> components or data structures for itself (the Cobol compiler to build a
> Cobol compiler approach).

You're right, but there are other ways. The other day I downloaded Booch 
components for Ada; I managed to compile the examples but I don't have a 
clue what's going on. For start I would just like my tool to select and 
tweak the apropriate version of container for me. There is no tool like 
that at the moment, but with more stupid people like me, there will :)

Regards,
Karel Miklav

RE: One language environment don't have future

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Preben Randhol [mailto:randhol+news@pvv.org]

> Besides how will your VB programmer be able to change a part of a
> project written in C++/Ada/whatever unless he also learns this language?

This is an interesting point that I meant to comment on.  It leads to
multiple points of failure.  The project would have to be modularized.
But this would only compartmentalize the failure point.  If you lost
your expert in any area, there would definitely be down time, learning
curves, etc.

We have this problem on our current project.  It was built with Ada,
Delphi, and C++.  Another related system used to build messages to send
to it, was built using M$ VB.  To maintain it, you need someone who knows
each language fairly well.  Otherwise, you could end up with kludged
updates in the future.

Frank

Re: One language environment don't have future

[Preben Randhol]

Beard, Frank Randolph CIV wrote:
> 
> -----Original Message-----
> From: Preben Randhol [mailto:randhol+news@pvv.org]
> 
>> Besides how will your VB programmer be able to change a part of a
>> project written in C++/Ada/whatever unless he also learns this language?
> 
> This is an interesting point that I meant to comment on.  It leads to
> multiple points of failure.  The project would have to be modularized.
> But this would only compartmentalize the failure point.  If you lost
> your expert in any area, there would definitely be down time, learning
> curves, etc.
> 
> We have this problem on our current project.  It was built with Ada,
> Delphi, and C++.  Another related system used to build messages to send
> to it, was built using M$ VB.  To maintain it, you need someone who knows
> each language fairly well.  Otherwise, you could end up with kludged
> updates in the future.

And if memory serves me well this was the (or at least one) initial
concern that sparked the development of Ada :-)

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: One language environment don't have future

[Amir Yantimirov]

Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnb3vgas.458.randhol+news@kiuk0152.chembio.ntnu.no>...
> Beard, Frank Randolph CIV wrote:
> > 
> > -----Original Message-----
> > From: Preben Randhol [mailto:randhol+news@pvv.org]
> > 
> >> Besides how will your VB programmer be able to change a part of a
> >> project written in C++/Ada/whatever unless he also learns this language?
> > 
> > This is an interesting point that I meant to comment on.  It leads to
> > multiple points of failure.  The project would have to be modularized.
> > But this would only compartmentalize the failure point.  If you lost
> > your expert in any area, there would definitely be down time, learning
> > curves, etc.

This is not differ from situation when experts use one language but
specialize in different domains.

> > 
> > We have this problem on our current project.  It was built with Ada,
> > Delphi, and C++.  Another related system used to build messages to send
> > to it, was built using M$ VB.  To maintain it, you need someone who knows
> > each language fairly well.  Otherwise, you could end up with kludged
> > updates in the future.

How familar! But the main troubles comes not from languages
differences. 90% of programming tasks are pretty trivial and has
standard solutions in any language. Its incompatibility of libraries
and object code, even between Visual C++ and C++ Builder. So I already
desided to move on .Net and only waits for right moment.

> And if memory serves me well this was the (or at least one) initial
> concern that sparked the development of Ada :-)

I will be glad to use one language for all tasks. Language of my taste
with how much power as possible and with my full responcibility for
safety of my feet. But I think most of us would disagree. So we have
to separate problem domains most appropriated for various kinds of
languages but preserve our ability to cooperate seamlessly.

I read here several times how good libraries and nice IDE can help
Ada. IMHO At best it would become new Delphi with zero chances to
broad success. I think to be successful the project should be
magnitudes more ambitious. Multi-languge, multi-platform, multi-target
on any platform and beating crap out of Net and Java (hm, something
more to pile?)

It strange, but I think it can be done. Certainly not by me but I like
to participate.

The ideas of intermediate code and standardizated portable format of
executable is trivial and not new. As is non-textual representation of
program source. As are both combined (Smalltalk). But while not use
all this more widely?

http://www174.pair.com/yamir/programming/textdead.htm

Amir Yantimirov

RE: One language environment don't have future

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Preben Randhol [mailto:randhol+news@pvv.org]

spam@not.come wrote:
>> I think what time of traditional language system is gone. 
>> The successfull future systems will be like .Net - one development 
>> environment for many call-compatible languages, with single runtime, 
>> single language-neitral set of libraries, single language-neitral 
>> OS interface. 

> Sounds to me like you are talking about several languages one executable
> standard?
>
> Besides how will your VB programmer be able to change a part of a
> project written in C++/Ada/whatever unless he also learns this language?

I think he's talking about the development environment and not the language.
Sort of like what DEC did with their systems.  If memory serves me correctly,
every language (Fortran, C, Pascal, Ada, ...) compiled to an intermediate
language.  Their debugger looked and worked the same no matter which one you
were using.  So, when you switched languages, all you really had to learn
was the new language.

So, I guess you would come in, select a language, develop with it, and then
compile to the intermediate.

Frank

RE: One language environment don't have future

[Larry Kilgallen]

In article <mailman.15.1044364570.3911.comp.lang.ada@ada.eu.org>, "Beard, Frank Randolph CIV" <frank.beard@navy.mil> writes:

> I think he's talking about the development environment and not the =
> language.
> Sort of like what DEC did with their systems.  If memory serves me =
> correctly,
> every language (Fortran, C, Pascal, Ada, ...) compiled to an =
> intermediate
> language.  Their debugger looked and worked the same no matter which one =
> you
> were using.  So, when you switched languages, all you really had to =
> learn
> was the new language.

While VMS has a common debugger, it is the object language (from which
executable programs are linked) that is guaranteed standardized.  The
intermediate language within a compiler can be anything the compiler
author chooses.  On VAX there were many code generators although
some language front ends had code generators from the same heritage
(and thus a common intermediate language).  On Alpha, DEC built a
single code generator (GEM) to which their various front ends were
adapted.  On Itanium, the first compiler effort for most languages
is based on an Itanium-targeted GEM, but Intel will later release
a VMS C compiler using the Intel backend for Itanium.

The VMS debugger has a SET LANGUAGE command so that expressions can
be entered in a form "native" to the programming language.  That gets
set automatically if the programmer does nothing, but a programmer
who has stopped at a breakpoint in a Macro or Bliss routine might
want to have their expressions evaluated in Ada or Fortran style.

Currently the GNAT compiler for Alpha VMS uses the GDB debugger
rather than the standard VMS debugger (at DEC's insistance when
they signed the contract to have GNAT ported).  There have been
customer complaints to VMS Development about that, and responses
have been at least that having GNAT use the regular VMS debugger
on Itanium is "under consideration".  In DEC parlance that likely
means "not a p0" (priority).  Doing that on Itanium might be
easier for the GNAT developers since Itanium VMS uses ELF and
DWARF rather than a traditional VMS object format and DST records.

Re: One language environment don't have future

[Thierry Lelegard]

Larry Kilgallen wrote:

> Currently the GNAT compiler for Alpha VMS uses the GDB debugger
> rather than the standard VMS debugger (at DEC's insistance when
> they signed the contract to have GNAT ported).  There have been
> customer complaints to VMS Development about that,

I am part of those

> and responses
> have been at least that having GNAT use the regular VMS debugger
> on Itanium is "under consideration".

Great, great idea. GDB on OpenVMS is a real pain (first, gdb has less
features than VMS Debug; second, the VMS port of GDB is deficient).

> In DEC parlance that likely
> means "not a p0" (priority).  Doing that on Itanium might be
> easier for the GNAT developers since Itanium VMS uses ELF and
> DWARF rather than a traditional VMS object format and DST records.

-Thierry

Re: One language environment don't have future

[Volkert]

> Great, great idea. GDB on OpenVMS is a real pain (first, gdb has less
> features than VMS Debug; second, the VMS port of GDB is deficient).

Of what version of gdb for OpenVMS you are talking. 
Can you give some examples.

Volkert

Re: One language environment don't have future

[Thierry Lelegard]

> > Great, great idea. GDB on OpenVMS is a real pain (first, gdb has less
> > features than VMS Debug; second, the VMS port of GDB is deficient).
> 
> Of what version of gdb for OpenVMS you are talking.

The GDB which comes with GNAT 3.15 and 5.00 is 4.17. I am not aware
of a more recent GNAT-aware GDB for OpenVMS.

> Can you give some examples.

- The only GUI is gdbtk
- Break points, trace points mostly work, sometimes they don't
- Watch points do not work
- Multithreaded debug is a pain
- No multi-language support (with DEC compilers)
- Etc...

-Thierry

Re: One language environment don't have future

[Preben Randhol]

Thierry Lelegard wrote:
> - The only GUI is gdbtk

GVD cannot be used?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: One language environment don't have future

[Volkert]

Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnb41rmo.el.randhol+news@kiuk0152.chembio.ntnu.no>...
> Thierry Lelegard wrote:
> > - The only GUI is gdbtk
> 
> GVD cannot be used?
No, not on VMS. i think the needed Gtk-Lib is not
ported ... may be there are future plans from ACT
to do this ... 

Volkert

Re: One language environment don't have future

[Preben Randhol]

Volkert wrote:
> No, not on VMS. i think the needed Gtk-Lib is not
> ported ... may be there are future plans from ACT
> to do this ... 

Ah of course I forgot. *BONK* Maybe you can do remote debugging from a
Linux/Unix machine?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: One language environment don't have future

[Volkert]

Thierry Lelegard <thierry.lelegard@canal-plus.fr> wrote in message news:<3E40E76D.DF8A112F@canal-plus.fr>...
> > > Great, great idea. GDB on OpenVMS is a real pain (first, gdb has less
> > > features than VMS Debug; second, the VMS port of GDB is deficient).
> > 
> > Of what version of gdb for OpenVMS you are talking.
> 
> The GDB which comes with GNAT 3.15 and 5.00 is 4.17. I am not aware
> of a more recent GNAT-aware GDB for OpenVMS.
> 
> > Can you give some examples.
> 
> - The only GUI is gdbtk
Yes, that's a pain. We hope to use GVD under NT with
the a gdbserver on OpenVMS (remote debugging).

> - Break points, trace points mostly work, sometimes they don't
> - Watch points do not work
> - Multithreaded debug is a pain
> - No multi-language support (with DEC compilers)
> - Etc
We have the GNU gdb 4.17.gnat.3.16w.41. installed here.
A person from ACT said that this new version is much better than
the old one. I try to reprocedure your examples and post the result
here ...

Volkert

One language environment don't have future

[spam]

Actually, I will not argue the subject. 
I am sure participants of C.L.A already know both pros and cons. 
Lets just 'and so'.

I think what time of traditional language system is gone. 
The successfull future systems will be like .Net - one development 
environment for many call-compatible languages, with single runtime, 
single language-neitral set of libraries, single language-neitral 
OS interface. But I prefer something more lightweight, more low-level
and more revolutionary than .Net, may be portable and open-source as 
well. 

I publish some ideas on my site. This is a view of C++ man with 
assembler mind, damaged by Fortran in youth (easily recognizable by 
I, J, K, L identifiers). To add a good cup of Ada-spirit may be worthy.

Amir Yantimirov
http://www174.pair.com/yamir/programming/



 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Re: One language environment don't have future

[Preben Randhol]

spam@not.come wrote:
> I think what time of traditional language system is gone. 
> The successfull future systems will be like .Net - one development 
> environment for many call-compatible languages, with single runtime, 
> single language-neitral set of libraries, single language-neitral 
> OS interface. 

Sounds to me like you are talking about several languages one executable
standard?

Besides how will your VB programmer be able to change a part of a
project written in C++/Ada/whatever unless he also learns this language?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: One language environment don't have future

[Karel Miklav]

spam@not.come wrote:
> I think what time of traditional language system is gone. 
> The successfull future systems will be like .Net - one development 
> environment for many call-compatible languages, with single runtime, 
> single language-neitral set of libraries, single language-neitral 
> OS interface. But I prefer something more lightweight, more low-level
> and more revolutionary than .Net, may be portable and open-source as 
> well. 

What I hope is, that speaking in computer tongues will become extinct in 
the near future and that logic described once will be durable and 
reusable. Something like executable UML.

Regards,
Karel Miklav

Re: One language environment don't have future

[Stephen Leake]

Karel Miklav <karel@inetis.spppambait.com> writes:

> What I hope is, that speaking in computer tongues will become extinct
> in the near future and that logic described once will be durable and
> reusable. Something like executable UML.

UML is just another "computer tongues". It's partly graphical, but
that's not really such a big deal!

-- 
-- Stephe

Re: One language environment don't have future

[Karel Miklav]

Stephen Leake wrote:
 > UML is just another "computer tongues". It's partly graphical, but
 > that's not really such a big deal!

The IT tower of Babel may never be built, but UML and tools around it 
are a step forward. And there is a difference between modeling and 
coding; I guess we're not going to rewrite data structures in all sorts 
of languages forever? Or watch compilers fuck us with cryptic messages? 
There must be evolution even in IT.

I can't say that one language environment has a future, but 95% out of 
thousands of languages surely doesn't, because orders of magnitude of 
users do matter. And even then, I'm not sure that textual representation 
of logic is the best there can be.

--

Regards,
Karel Miklav

Re: One language environment don't have future

[Kevin Cline]

Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<nrv0a.654$wK6.41205@news.siol.net>...
> Stephen Leake wrote:
>  > UML is just another "computer tongues". It's partly graphical, but
>  > that's not really such a big deal!
> 
> The IT tower of Babel may never be built, but UML and tools around it 
> are a step forward. 

The software development community seems to disagree. 
After many years on the market, graphical programming systems
are still not widely used.

> And there is a difference between modeling and 
> coding; I guess we're not going to rewrite data structures in all sorts 
> of languages forever?

In any interesting computer program there are thousands
of details that must be specified.  The details don't come
from the programming language, they come from the customer.
The programmer's job is to translate the customer's wants
into some sort of executable specification.  Regardless of
programming language, that job will remain, and it will require
close attention to detail.  And some programmers will be vastly
better at the job than others.  So far, the best programmers
haven't found much value in graphical programming environments.

> 
> I can't say that one language environment has a future, but 95% out of 
> thousands of languages surely doesn't, because orders of magnitude of 
> users do matter. 
> And even then, I'm not sure that textual representation 
> of logic is the best there can be.

Well, considering that most of the information in books is currently
textual, and has been for many centuries, it seems unlikely that
pictorial representations of program logic will prove superior
within our lifetimes.

Re: One language environment don't have future

[Amir Yantimirov]

kcline17@hotmail.com (Kevin Cline) wrote in message news:<ba162549.0302061237.919b409@posting.google.com>...
> Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<nrv0a.654$wK6.41205@news.siol.net>...
> > I can't say that one language environment has a future, but 95% out of 
> > thousands of languages surely doesn't, because orders of magnitude of 
> > users do matter. 
> > And even then, I'm not sure that textual representation 
> > of logic is the best there can be.
> 
> Well, considering that most of the information in books is currently
> textual, and has been for many centuries, it seems unlikely that
> pictorial representations of program logic will prove superior
> within our lifetimes.

I am sure program logic should be _represented_ as text but it's not
necessary being such under surface. And raw text is not good for
representing rich hierarchical structures. Something like Word's
"Structured view" would be far more appropriate.

Units dependance diagram is only case what comes to mind where
graphics makes sense. With connection lines of various width. Exactly
as in circuits placement editor I had writing at DOS times :))

http://www174.pair.com/yamir/programming/textdead.htm

Amir Yantimirov

Re: One language environment don't have future

[Karel Miklav]

Kevin Cline wrote:
> Karel Miklav wrote:
>> Stephen Leake wrote:
>>> UML is just another "computer tongues". It's partly graphical,
>>> but that's not really such a big deal!
>> 
>> The IT tower of Babel may never be built, but UML and tools around
>> it are a step forward.
> 
> The software development community seems to disagree. After many
> years on the market, graphical programming systems are still not
> widely used.

I agree, but it proves nothing. And it's shure not the case in my business.

>> And there is a difference between modeling and coding; I guess
>> we're not going to rewrite data structures in all sorts of
>> languages forever?
> 
> In any interesting computer program there are thousands of details
> that must be specified.  The details don't come from the programming
> language, they come from the customer. The programmer's job is to
> translate the customer's wants into some sort of executable
> specification.  Regardless of programming language, that job will
> remain, and it will require close attention to detail.

Ok, but how popular are assemblers today? Modeling tools are able to
produce code out of a skillfuly crafted model in any language and 
they'll sonner or later have a Compile button. And you will be able to 
tweak the generated code as much as you want. It's not that I'm 
interested in science fiction, I'm just asking myself what benefit do I 
have from learning ada or is it just an obstacle from being a part of a 
bigger picture?

> And some programmers will be vastly better at the job than others.

You're talking about automata, right?

> So far, the best programmers haven't found much value in graphical
> programming environments.

Are you speaking in the name of the Best Programmers Association? I 
might be impolite but you can't pull cards out of your sleeve like that, 
you're not Colin Powell, man :)

>> I can't say that one language environment has a future, but 95% out
>> of thousands of languages surely doesn't, because orders of
>> magnitude of users do matter. And even then, I'm not sure that
>> textual representation of logic is the best there can be.
> 
> Well, considering that most of the information in books is currently 
> textual, and has been for many centuries, it seems unlikely that 
> pictorial representations of program logic will prove superior within
> our lifetimes.

Kevin, It's not about disagreing with you, I just wish to see some
progress in IT. And I'm little frustrated as I can't change the tiniest
bit :)

Thank you,
Karel Miklav

Re: One language environment don't have future

[AG]

"Karel Miklav" <karel@inetis.spppambait.com> wrote in message
news:JzJ0a.667$wK6.41550@news.siol.net...

> Ok, but how popular are assemblers today? Modeling tools are able to
> produce code out of a skillfuly crafted model in any language and
> they'll sonner or later have a Compile button.

Really? OK, they can generate the framework (which is mostly
useless and contributes to code-bloat) but real code?

> And you will be able to  tweak the generated code as much as you want.

Say what? :) All you need that tool for is to be able to tweak
it's generated code?

Re: One language environment don't have future

[Karel Miklav]

AG wrote:
> "Karel Miklav" <karel@inetis.spppambait.com> wrote in message
>>Ok, but how popular are assemblers today? Modeling tools are able to
>>produce code out of a skillfuly crafted model in any language and
>>they'll sonner or later have a Compile button.
> 
> Really? OK, they can generate the framework (which is mostly
> useless and contributes to code-bloat) but real code?
> 
>>And you will be able to  tweak the generated code as much as you want.
> 
> Say what? :) All you need that tool for is to be able to tweak
> it's generated code?

We're not on the same wavelength, so it's best I stop here. I'm learning 
Ada and I hope I'm not wasting my time; thanks for reassuring me about that.

Karel Miklav

Re: One language environment don't have future

[Kevin Cline]

Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<JzJ0a.667$wK6.41550@news.siol.net>...
> Kevin Cline wrote:
> > Karel Miklav wrote:
> >> Stephen Leake wrote:
> >>> UML is just another "computer tongues". It's partly graphical,
> >>> but that's not really such a big deal!
> >> 
> >> The IT tower of Babel may never be built, but UML and tools around
> >> it are a step forward.
> > 
> > The software development community seems to disagree. After many
> > years on the market, graphical programming systems are still not
> > widely used.
> 
> I agree, but it proves nothing. And it's shure not the case in my business.
> 
> >> And there is a difference between modeling and coding; I guess
> >> we're not going to rewrite data structures in all sorts of
> >> languages forever?
> > 
> > In any interesting computer program there are thousands of details
> > that must be specified.  The details don't come from the programming
> > language, they come from the customer. The programmer's job is to
> > translate the customer's wants into some sort of executable
> > specification.  Regardless of programming language, that job will
> > remain, and it will require close attention to detail.
> 
> Ok, but how popular are assemblers today? Modeling tools are able to
> produce code out of a skillfuly crafted model in any language and 
> they'll sonner or later have a Compile button. 

Right, but for real-world problems there is an essential complexity
that is not readily expressed graphically.  The boxes and arrows
take up lots of screen space but don't provide much information.
The important information is captured by rules like:

Set shipping date two days after order date, skipping weekends and 
bank holidays.

If the customer lives in a jurisdiction where we have a retail store,
then add sales tax for that jurisdiction.



> And you will be able to 
> tweak the generated code as much as you want. 

I don't want to.  Then I'm stuck working in two languages and worse,
have to understand the mapping between them.

> It's not that I'm interested in science fiction, 
> I'm just asking myself what benefit do I 
> have from learning ada or is it just an obstacle from being a part of a 
> bigger picture?

No, it's a necessary step in being able to see the big picture.  You
won't
have the big picture until you know several languages and have written
a considerable amount of code in each.

> > And some programmers will be vastly better at the job than others.
> 
> You're talking about automata, right?

No, automata have little or no understanding of the external world.  
They have no idea what it means when someone says "be sure to add
sales tax where applicable."

> 
> > So far, the best programmers haven't found much value in graphical
> > programming environments.
> 
> Are you speaking in the name of the Best Programmers Association? I 
> might be impolite but you can't pull cards out of your sleeve like that, 
> you're not Colin Powell, man :)

I mean that they aren't very popular, and seem to be even less popular
among the more effective developers I know.
 
> Kevin, It's not about disagreing with you, I just wish to see some
> progress in IT. And I'm little frustrated as I can't change the tiniest
> bit :)

Sure you can.  You can build a graphical programming environment
that really works.  Or you can design a better language.  I can think
of three very popular languages, C++, Perl, and Java, that were
essentially created by a single person.

Re: One language environment don't have future

[AG]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0302061237.919b409@posting.google.com...
> Karel Miklav <karel@inetis.spppambait.com> wrote in message
news:<nrv0a.654$wK6.41205@news.siol.net>...
> > Stephen Leake wrote:
> >  > UML is just another "computer tongues". It's partly graphical, but
> >  > that's not really such a big deal!
> >
> > The IT tower of Babel may never be built, but UML and tools around it
> > are a step forward.
>
> The software development community seems to disagree.
> After many years on the market, graphical programming systems
> are still not widely used.

And not surprisingly. Compare it with normal languages:
Historically, they seem to have migrated from pictorials
to hieroglyphics to alphabet and plain text. The reason?
Well, more flexibility, generality and more expressive power.
Try to come up with a picture for the previous sentence
for example ...

For some reason, computerese seems to be going
in exactly the opposite way - having started with a sort
of literate language it now drifts more and more towards
simple [not to say stupid] pictures.

[...]

> Well, considering that most of the information in books is currently
> textual, and has been for many centuries, it seems unlikely that
> pictorial representations of program logic will prove superior
> within our lifetimes.

Also, attempts to do that have been made decades ago:
Block diagrams anyone? I'm still waiting for a compiler
or IDE to draw that diagram and have the code generated
which would be equivalent to say a few hundred classes
written in text [well, I'm not - sarcasm y'know]

Re: One language environment don't have future

[Stephen Leake]

Karel Miklav <karel@inetis.spppambait.com> writes:

> Stephen Leake wrote:
>  > UML is just another "computer tongues". It's partly graphical, but
>  > that's not really such a big deal!
> 
> The IT tower of Babel may never be built, but UML and tools around it
> are a step forward. And there is a difference between modeling and
> coding; 

I can write "models" in Ada or in UML; there is not much semantic
difference. 

> I guess we're not going to rewrite data structures in all sorts of
> languages forever? 

Why should UML be the last one?

> Or watch compilers fuck us with cryptic messages? 

What are the error messages like from a typical UML compiler? I
confess I have not seen any yet. But I have no a priori reason to
believe they will be better than the ones from GNAT.

> There must be evolution even in IT.

Yes. That's how we got Ada 95. (thanks for the straight line :).

> I can't say that one language environment has a future, but 95% out
> of thousands of languages surely doesn't, because orders of
> magnitude of users do matter. 

That sounds like the DoD argument for Ada. That particular argument
appears to have failed, but Ada is still thriving.

> And even then, I'm not sure that textual representation of logic is
> the best there can be.

You may not be sure, but I'm sure Ada 95 is better than UML for
"logic". State charts are nice for systems that have lots of states,
and use cases are nice for all requirements analysis. The rest of UML
I can easily live without.

-- 
-- Stephe

Re: One language environment don't have future

[Simon Wright]

Stephen Leake <Stephen.A.Leake@nasa.gov> writes:

> What are the error messages like from a typical UML compiler? I
> confess I have not seen any yet. But I have no a priori reason to
> believe they will be better than the ones from GNAT.

Possibly not .. mine are at 
http://www.pushface.org/coldframe/error-messages.html

-S

Re: One language environment don't have future

[Kevin Cline]

Karel Miklav <karel@inetis.spppambait.com> wrote in message news:<Ex20a.602$wK6.38487@news.siol.net>...
> spam@not.come wrote:
> > I think what time of traditional language system is gone. 
> > The successfull future systems will be like .Net - one development 
> > environment for many call-compatible languages, with single runtime, 
> > single language-neitral set of libraries, single language-neitral 
> > OS interface. But I prefer something more lightweight, more low-level
> > and more revolutionary than .Net, may be portable and open-source as 
> > well. 
> 
> What I hope is, that speaking in computer tongues will become extinct in 
> the near future and that logic described once will be durable and 
> reusable. Something like executable UML.

Then you'll just have one more language, targeted for another virtual
machine.
Presumably a very high-level virtual machine.  Programmed by someone
in
a lower-level language.  And when that high-level machine is too
high-level to produce the desired performance, then someone will have
to write a new component in a lower-level language.

Re: One language environment don't have future

[Stephen Leake]

spam@not.come writes:

> The successfull future systems will be like .Net - one development 
> environment for many call-compatible languages, with single runtime, 
> single language-neitral set of libraries, single language-neitral 
> OS interface. 

Sounds like VMS. Nothing new here.

-- 
-- Stephe

Re: One language environment don't have future

[Larry Kilgallen]

In article <u3cn27hrt.fsf@nasa.gov>, Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
> spam@not.come writes:
> 
>> The successfull future systems will be like .Net - one development 
>> environment for many call-compatible languages, with single runtime, 
>> single language-neitral set of libraries, single language-neitral 
>> OS interface. 
> 
> Sounds like VMS. Nothing new here.

I was under the impression that .NET, like the Java Bytecode Engine,
constrained what languages are able to do.  I felt this was confirmed
by the release of "A#" rather than "Ada95" for .NET.

In that sense, I would say the .NET environment represents quite
a degradation from what is provided by VMS (and has been for about
25 years).

Re: One language environment don't have future

[Georg Bauhaus]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
 
: I was under the impression that .NET, like the Java Bytecode Engine,
: constrained what languages are able to do.

I think Eiffel fans will disagree; Eiffel# doesn't exist
any longer, because full (new) Eiffel is supported for .NET.

: In that sense, I would say the .NET environment represents quite
: a degradation from what is provided by VMS (and has been for about
: 25 years).

Given Dave Cutler has led Windows developement, shouldn't there
be some things that looks familiar under the hood?

Re: One language environment don't have future

[Larry Kilgallen]

In article <b1uf7u$8dc$3@a1-hrz.uni-duisburg.de>, Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> Larry Kilgallen <Kilgallen@spamcop.net> wrote:
>  
> : I was under the impression that .NET, like the Java Bytecode Engine,
> : constrained what languages are able to do.
> 
> I think Eiffel fans will disagree; Eiffel# doesn't exist
> any longer, because full (new) Eiffel is supported for .NET.
> 
> : In that sense, I would say the .NET environment represents quite
> : a degradation from what is provided by VMS (and has been for about
> : 25 years).
> 
> Given Dave Cutler has led Windows developement, shouldn't there
> be some things that looks familiar under the hood?

Whatever is "under the hood" would seem to have little influence
on the published interfaces, which are patterned after prior
Microsoft Windows implementations.