Waiting further for the Even Better Languge then... ;)
(Fortunately I'm not in a desperate need for it right now...)

Eiffel, Ruby, D, this new group of emerging "post-C++,
almost there" languages are the guarantee to me that
eventually someone will pick the best of them all and
come up with something like, er, an Even Better Language.

(Anyone interested in a project to formulate some sort
of "Common Language Platform" of widely established
components of syntax/semantics? Would it be nice to
standardize -- not a full language, but only some generic
features, so specific languages (e.g. for scripting, or system
programming) could be designed building on that common
platform, not reinventing the damn' wheel all the time on
and again... 1. Language desing could be easier. 2. Porting
code could be easier, and 3. the "language barrier" would
be much lower... Damn, sounds like Esperanto... Bad
omen... ;) But this would not be a language, only a set of
building blocks for languages. Mmm... Still too fantastic...
Maybe 20 years later...)

Good luck everyone,
Sab

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:atl6cm$212c$1@digitaldaemon.com...
> My main fear is that everyone will make their very own typedef for bool
and
> enum for true and false, and the conflicts could cause a world of grief.
>
> Even if there's no special low level type, at least the language should
have
> the typedef and enums be part of the standard.  But once you have that,
what
> makes bool powerful is when the comparison operators return bool, and bool
> is not implicitly convertible to int, and the if (), while (), clauses
take
> bool.
>
> If you ask me, having a bool type actually aids the implementor because
it's
> the only type that can fit into a flags register bit.  While it's in the flags register it can be negated etc "for free" by changing the sense of
the
> tests.
>
> Sean
>
> "hojtsy AT NOSPAM index.hu" <hojtsy_member@pathlink.com> wrote in message news:atkksj$1igt$1@digitaldaemon.com...
> > I agree with you. I took part in that previous discussion. Seems that
> Walter
> > don't want implement new types which has the same asm level
implementation
> as
> > some other type. Because users don't need it? Who are we if not the
users
> of the
> > language?
> >
> > Sandor Hojtsy
>

Sab wrote:
> Waiting further for the Even Better Languge then... ;)
> (Fortunately I'm not in a desperate need for it right now...)
> 
> Eiffel, Ruby, D, this new group of emerging "post-C++,
> almost there" languages are the guarantee to me that
> eventually someone will pick the best of them all and
> come up with something like, er, an Even Better Language.
> 
> (Anyone interested in a project to formulate some sort
> of "Common Language Platform" of widely established
> components of syntax/semantics? Would it be nice to
> standardize -- not a full language, but only some generic
> features, so specific languages (e.g. for scripting, or system
> programming) could be designed building on that common
> platform, not reinventing the damn' wheel all the time on
> and again... 1. Language desing could be easier. 2. Porting
> code could be easier, and 3. the "language barrier" would
> be much lower... Damn, sounds like Esperanto... Bad
> omen... ;) But this would not be a language, only a set of
> building blocks for languages. Mmm... Still too fantastic...
> Maybe 20 years later...)
> 

That's a really fascinating idea.   I'm not sure how one would go about getting it to work.   It would require something like a metacompiler/compiler generator though, which is what I would see as the sticking point.  It would be an amazing piece of software that could take even an amazingly detailed language spec and then produce a prototype compler from it.  It would open up language design to the masses, though.

Evan

Sab wrote:
> Waiting further for the Even Better Languge then... ;)
> (Fortunately I'm not in a desperate need for it right now...)
> 
> Eiffel, Ruby, D, this new group of emerging "post-C++,
> almost there" languages are the guarantee to me that
> eventually someone will pick the best of them all and
> come up with something like, er, an Even Better Language.
> 
> (Anyone interested in a project to formulate some sort
> of "Common Language Platform" of widely established
> components of syntax/semantics? Would it be nice to
> standardize -- not a full language, but only some generic
> features, so specific languages (e.g. for scripting, or system
> programming) could be designed building on that common
> platform, not reinventing the damn' wheel all the time on
> and again... 1. Language desing could be easier. 2. Porting
> code could be easier, and 3. the "language barrier" would
> be much lower... Damn, sounds like Esperanto... Bad
> omen... ;) But this would not be a language, only a set of
> building blocks for languages. Mmm... Still too fantastic...
> Maybe 20 years later...)

It's something worth considering.  Trouble is, the fundamental semantics of a language can vary greatly.  For instance, how can you define shared semantics between compiled, typesafe languages (like the C family) and interpreted, type-unsafe languages (like most scripting langages)?  It's hard to define "int is a 32bit integer" if the internal representation is not a literal representation like that.

Perhaps I'm thinking too low level?  Much of the things we debate here on this newsgroup are fairly high-level details.  I've been thinking that what we need is a standardized translation grammar that will allow a tool to convert a language from one for to another.

Such a tool would allow Walter to implement a very minimal form of D, and then add a layer of translation above it.  Call it "Core D" and "Standard D".  A program written in Standard D could be converted automatically (at compile time) to Core D.  This would greatly simplify compilers.

Going further, you could use such a tool for actually translating a lanugage altogether; you could write a spec file that converts D to C, and (perhaps) even convert C to assembly.  These spec files would be in some sort of human-readable format, meaning that you could edit them by hand.

If they are human readable, then we also have other possiblilites.  For instance, generics (that is, templates or similar things) could be constructed entirely by inlining a translation spec into the source. This would allow the programmer not only to add generics, but also whole new language features.  One could even go so far as embedding source code from several languages into the same source file.  You could write a D program but code a portion of it in Perl.  The compiler, if it had a Perl->D translator, it could translate that fragment into D at compile time, or if it had both D->C and Perl->C translators, then it could transform the entire program to C and compile it that way.

Anyhow, various thoughts...

Going even further, this sort of spec could be used as a JIT compiler technology.  What if you could publish an executable, written in an arbitrary laguage, in source form, with the spec for the compiler included with it in the same file?  The OS on the user's machine could JIT compile it according to the specification built into the file.

Or, better yet, set up a repository of open-source translation specs; the user computer would download specs only when needed, caching both the spec and the compiled executable.

>
>Eiffel, Ruby, D, this new group of emerging "post-C++,
>almost there" languages are the guarantee to me that
>eventually someone will pick the best of them all and
>come up with something like, er, an Even Better Language.

And don't forget OCaml!
http://caml.inria.fr/
http://caml.inria.fr/users_comments-eng.html

I got the following private comments from a computer scientist.

"...my experience has been that only OCaml offers the speed of execution, ease of foreign language [i.e. non-OCaml code] interfacing, and high-level functional syntax, needed for real-world application development. Next to Lisp, OCaml is my next choice for rapid prototyping. But for robust released code, OCaml is first on the list because of the type safety.

"Yes, I have been following Eiffel for quite some time. About 12 years ago I read Bertrand Meyer's book on Object Oriented Program Design, and I was enthralled by his ideas. I subsequently got some copies of Eiffel and started using it for semi-production work in a lab control environment. What I found in practice was that Eiffel, with all of its tower of classes, became quite confusing to program, and had a rather poor foreign language interface. Newer versions may be much better in that regard. But the versions I used did not yet have COM/OLE capabilities.

"All of these problems vanished the moment I got into OCaml. I am a strong believer in OCaml for a lot of reasons, not the least of which is foreign function interfacing. We almost never use a monolithic toolset here. We have spreadsheets in Excel (VBA), Visual Basic written by the engineers, Mathcad, Mathematica, Matlab, Lisp, Fortran, C, C++, COM/OLE, and on and on... So interfacing to other modules is very high on my list."

Russell Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3E0388A8.8050103@deming-os.org:

> Such a tool would allow Walter to implement a very minimal form of D, and then add a layer of translation above it.  Call it "Core D" and "Standard D".  A program written in Standard D could be converted automatically (at compile time) to Core D.  This would greatly simplify compilers.
> 

Take a look in C-- project.

Mark Evans wrote:
>>Eiffel, Ruby, D, this new group of emerging "post-C++,
>>almost there" languages are the guarantee to me that
>>eventually someone will pick the best of them all and
>>come up with something like, er, an Even Better Language.
It's a herd choice. Look at C++. A load of features doesn't make it a good, styled and balanced language.


> And don't forget OCaml!
> http://caml.inria.fr/
> http://caml.inria.fr/users_comments-eng.html
> 
> I got the following private comments from a computer scientist.
I know Ocaml very well and i like it but i simply CAN'T use it in projects were other people are involved. It is quite hard to grasp, or at least seems so. I bet i can move a few C and C++ coders to switch to D and help me out, but NEVER into OCaml.

> 
> "...my experience has been that only OCaml offers the speed of execution, ease
> of foreign language [i.e. non-OCaml code] interfacing, and high-level functional
Interfacing *any* language from OCaml is a REAL PAIN, since data structures in C and OCaml differ to 100% - this inevitably means that you can only stop gaps in OCaml with bits of C code - not lead concurrent multi-language development in one project, "reuse" would be unappropriate since the C code has to be completely rewritten to work with OCaml.

> syntax, needed for real-world application development. Next to Lisp, OCaml is my
> next choice for rapid prototyping. But for robust released code, OCaml is first
> on the list because of the type safety.
OK. OCaml types promise a great flexibility, unless you need something like a dual-linked list... then you're trapped and it starts working against you and complicating things.

> 
> "Yes, I have been following Eiffel for quite some time. About 12 years ago I
> read Bertrand Meyer's book on Object Oriented Program Design, and I was
> enthralled by his ideas. I subsequently got some copies of Eiffel and started
> using it for semi-production work in a lab control environment. What I found in
> practice was that Eiffel, with all of its tower of classes, became quite
> confusing to program, and had a rather poor foreign language interface. Newer
> versions may be much better in that regard. But the versions I used did not yet
> have COM/OLE capabilities.
I've seen a bit more people comfused by OCaml then by Eiffel. I like Eiffel a lot. But i can't used it in a project where everyone has C/C++/Java experience. It doesn't make easy many things that are useful in my craft - interfacing all kinds of all libraries, file formats, ets, which can be well done in a "dirty" C-way. D disencourages such things a bit, but doesn't make them hard or even impossible like many do. And thinking in 2 languages while working on 1 project is a BIG PAIN. I tried to code in BCX and C once, to enable both BASIC and C developers to contribute to the project. It was simply horrible. D and C are not different languages, they are dialects, most C code would work in D with little changes, and can be improved incrementally. To be frank I hate C syntax, but there's simply no other choise because it is simply too widespread.

COM/OLE Capabilities? The developer who writes this doesn't seem to be experienced. An OO language is not requiered at all to access them. They can be accessed even through C. As far as i'm conserned, there might be no automatic tool to do that, but wrapping COM C interface into an Eiffel class should be a snap.

> 
> "All of these problems vanished the moment I got into OCaml. I am a strong
> believer in OCaml for a lot of reasons, not the least of which is foreign
> function interfacing. We almost never use a monolithic toolset here. We have
> spreadsheets in Excel (VBA), Visual Basic written by the engineers, Mathcad,
> Mathematica, Matlab, Lisp, Fortran, C, C++, COM/OLE, and on and on... So
> interfacing to other modules is very high on my list."
It requieres quite a bit of fiddling around in OCaml, and is only justified if you *know exactly* that you need this library and not another one. D is very similar to C, and automatic converters will arrive, enabling to try one or another C library out fast without writing an unterface to it.

-i.

I was the angry guy who replied to the message a minute ago. :)

The last message didn't contain my name and e-mail adress. This one does. Just for case you want to reply me.

Best Regards,
-i./MIDICLUB
currently coding volunteer for NUMEDIA CYCLOPS.

hojtsy AT NOSPAM index.hu wrote:
> In article <atk0q6$sng$1@digitaldaemon.com>, Roberto Mariottini says...
> 
>>"Sab" <sab@neuropolis.org> wrote...
>>

Just take a second and THINK! What happens it you apply binary "boolean" oberation to a bit? and now apply logical "boolean" operations. Guys, since it's only one bit it's THE SAME. To my opinion, using bit as a boolean type is natural ynd justified - unlike the use of int as boolean type which is a CATASTROPHE, which can lead to expression like ((bitmask&bitmask) == TRUE), where bitmask&bitmask yields boolean true, but when compared to a constant it yields FALSE!!! it would drive beginners insane and cost professionals hours of debugging. And please note, since data is always "aligned", it is not a consern of a programmer whether it's stored as an int or as a bit, important is that it WORKS JUST LIKE BOOL in pascal and alike and prevents bugs. I think the underlying types should be both simple and powerful, and bit is THE BEST EXAMPLE of such a combination!!! It replaces a fairly powerful pascal "set" and a lot of other things in a wonderful manner, you don't need to worry about bugs in such essential code anymore, not cluttering the language with keywords or libraries with stuff. I bet such a smart definition saves thousands of library code lines.

A language which is not cluttered parses well, and is hence not only sutable for native code generation, but also for interpreting, bytecode, JIT, and so on. Don't limit the future use of D!!!

>>>I may not be familiar enough with the D bool stuff, but
>>>the issue is generic anyway. Bit and bool are two different
>>>concepts. Bit is a numerical entity which is sometimes
>>>good to represent bools, which is a logical entity. But
>>>sometimes not. Sometimes int is better for that purpose.
>>>Either way, I see it a big mistake to blur bit and bool.
>>>Blurring int and bool is an equally big mistake -- in C++
>>>they have fixed that eventually, but as coding is translating
>>>concepts and ideas to a formal language, coding anomalies
>>>have been there in most languages that don't treat bool
>>>as it should be treated: as a concept (type) on its own.
there are no anomalies: a bit is GUARANTEED to behave as a bool!!!

>>
>>There were a big discussion about this, and I agree you.
>>But Walter seems to not agre with us, so I think we won't
>>have a boolean type in D.
>>
>>What a pity.
>>
>>Ciao
> 
> 
> I agree with you. I took part in that previous discussion. Seems that Walter
> don't want implement new types which has the same asm level implementation as
> some other type. Because users don't need it? Who are we if not the users of the
> language?
> 
> Sandor Hojtsy

>The developer who writes this doesn't seem to be experienced.

He's a Ph.D. computer scientist working as a high-level consultant for a large corporation, with a working knowledge of probably a dozen languages, and at least two decades of experience.  He coordinates with various engineers across his company in many disciplines.  So he has serious real-world experience.

>I've seen a bit more people comfused by OCaml then by Eiffel.

OCaml is a hybrid functional/imperative language.  Functional style often throws off C/C++/Java/FORTRAN programmers.  Those are imperative languages with a completely different feel to them.

Hybrid languages ask even more than pure functional languages.  They expect the user to know when to employ the functional style, and when the imperative.  This means the user must think in two different ways at the same time, constantly deciding which paradigm is most appropriate.  Yet for those who can do it, this combination yields real programming power.

Mathematica offers hybrid features and I've certainly heard people complain about it being "hard" and "confusing."  But I know it as one of the most productive tools in my chest.  The best Mathematica programs are roughly 80% functional and 20% imperative.  I've personally instructed engineers and mathematicians in Mathematica and learned, to my dismay, that some folks simply have a mental block toward functional programming.  I find them writing the equivalent of FORTRAN in Mathematica.  When it reaches that point, they might as well use FORTRAN instead.  In those cases, the deficiency is really in the programmer, not the language.  It's a bit like someone using a wrench as a hammer and a hammer as a screwdriver.

I expect the same holds true of OCaml.  Software gurus who grok hybrid programming use Mathematica and love it.  That's why I find it on the shelf of software experts.  Then I walk across the aisle and find klunky old MATLAB on the shelves of EEs who don't know programming very well. It's more "friendly" but a whole lot less powerful, too.

What all of this means for D is that functional features are good, and OCaml may have some things to offer in terms of specific implementation concepts.  I'm sure the syntax could be improved but its heart is in the right place.

Mark

OCaml performance second only to C http://www.bagley.org/~doug/shootout/craps.shtml

OCaml rapid application development
http://www.ocaml.org/
"10/2002. An Objective Caml program wins first prize at the ICFP 2002
programming contest....09/2000. Two Objective Caml programs win first and second
prizes at the ICFP programming contest. "

http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
"This paper is an attempt to demonstrate to the 'real world' that functional
programming is vitally important, and also to help functional programmers
exploit its advantages to the full by making it clear what those advantages
are."

http://www.mysternetworks.com/gmarceau/functional-programming.html
"If functional programming style is not more widely used, it is mostly because
of its higher bar of entry. As natural as they become, recursion, lambda's and
currying are challenging concepts the first time you meat them - not unlike
pointers (which most visual basic programmer still struggle with)."

http://www.cs.ait.ac.th/~kitt/caml/
"You might be surprised if I tell you that ML/OCaml is quite popular and being
used to develop software in many leading companies. Nortel, AT&T, Ericsson use
ML or some other functional languages to implement their telephone switching
firmware. Motorola uses ML to develop a symbolic simulation tool. They throwed
their original 3500-line fragile C code away, and rewrote the whole program in
ML. The result was 700-line ML code performing the same functions without bugs.
The process spent only a couple of weeks. Most people start to write ML without
knowing how to debug ML programs, but they still get bug-free programs."

"Functional programming is quite difficult for me, how is it important? ... This is the classic question; students from all batches ask this question.... In the past, you have learnt to program using imperative languages. Now, we change to functional language, which is completely different programming paradigm. That's why it is difficult -- if you already know some imperative language, you have to change the way of thinking to write a program using functional language."

Newbie comments http://opensource.lineo.com/~beppu/prose/ocaml.html

OCaml and COM
http://caml.inria.fr/camlidl/

Developing with OCaml (online book, discusses functional style) http://caml.inria.fr/oreilly-book/html/index.html