Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

Hi folks!

I'm a CS student and I often need to write number-crunching code dealing 
with combinatorial optimization problems.
What I do usually is implementing ad-hoc algorithms and testing their 
performance against other previously-known solutions, including general 
solvers.

In the past I used C, but now I have decided to change language.
I'm looking for a "better" one.

Here follow the features it should have, ranked approximately by relevance:

0) open-source support and an alive community
1) directly compiled to efficient code
2) statically typed and object-oriented, better if multi-paradigm
3) general-purpose libraries (possibly standardized, either by standard 
or de facto), including containers and some math abstractions.
4) garbage collected. As an alternative, provide memory management 
policies via libraries (e.g. memory pools and such)
5) optional run-time checks and some kind of control over compilation 
and low-level issues
6) "relatively simple and consistent"

So I have considered these alternatives: FreePascal, Eiffel, Ada and 
Modula-3.
I have taken a look at all of them and I'm still undecided. Below are 
the impressions I got for each language.
Can you help me? Feel free to recommend other languages as well.

TIA
    
--> Impressions I got for each language

     - FreePascal is a safe and modular alternative to C and C++,  but 
it is also close to the latter in terms of expressiveness. Moreover it 
doesn't seem to have the libraries I need.
==>Qualifies for 0,1,2,5. Not sure about 3 and 4

     - Eiffel is geared toward application programming in 
medium/large-sized teams relying heavily on OO modelling. It is designed 
for (re)usability, correctness and efficiency in this order.  
My needs are somewhat different though.
The main gripe I have with Eiffel is the lack of a well-documented 
standard gpl'ed library.
GOBO and EiffelBase seem to have incomplete or non-free documentation 
and I couldn't find tutorials; as such, I couldn't get a clear picture 
about them.
==> Qualifies for 0,1,2,4,5 and 6.  Not sure about 3.

     - Ada is best suited for large teams and/or critical software, thus 
it may be overkill for my work, OTH it could have anything I might 
happen to need.
What holds me from jumping onto Ada is the potential complexity
It would be interesting  to hear the experience of other people learning 
Ada from the C/Java background.
As for memory management (requirement 4), I heard there are different 
takes on the matter:
 (a) Ada uses dynamic stack allocation a lot, and in a transparent way, 
reducing the need of manual management (MM)
 (b) Ada libraries adopt idioms that further simplifies MM issues
 (c) Conservative garbage collectors such as Bohem's can be used with 
Ada, and they are supposed to work "better" with Ada than with unsafe 
languages such as C and C++

So can MM be said to be easier in Ada than in C? I hope Ada-ers will 
mercifully shed some light on the issue.

There seems to be a lot of Ada95 free documentation on the net, I guess 
it's suitable for Ada05 as well.
==> Qualifies for 0,1,2,3,5 and, partially, 4

     - Modula-3 is simpler/smaller than Ada and has been successfully 
used for system/application programming.
It seems to be the most consistent, simple and easy to grok, but I 
couldn't find any container/math library ready to use.
==> Qualifies for 0,1,2,4,5,6.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Richard Harter]

On Sat, 18 Jul 2009 16:19:40 +0200, Andrea Taverna
<a.tavs.NOSPAM@libero.it.invalid> wrote:

>Hi folks!
>
>I'm a CS student and I often need to write number-crunching code dealing 
>with combinatorial optimization problems.
>What I do usually is implementing ad-hoc algorithms and testing their 
>performance against other previously-known solutions, including general 
>solvers.
>
>In the past I used C, but now I have decided to change language.
>I'm looking for a "better" one.
>
>Here follow the features it should have, ranked approximately by relevance:
>
>0) open-source support and an alive community
>1) directly compiled to efficient code
>2) statically typed and object-oriented, better if multi-paradigm
>3) general-purpose libraries (possibly standardized, either by standard 
>or de facto), including containers and some math abstractions.
>4) garbage collected. As an alternative, provide memory management 
>policies via libraries (e.g. memory pools and such)
>5) optional run-time checks and some kind of control over compilation 
>and low-level issues
>6) "relatively simple and consistent"
>
>So I have considered these alternatives: FreePascal, Eiffel, Ada and 
>Modula-3.
>I have taken a look at all of them and I'm still undecided. Below are 
>the impressions I got for each language.
>Can you help me? Feel free to recommend other languages as well.
>
>TIA

You might also consider modern fortran.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
If I do not see as far as others, it is because
I stand in the footprints of giants. 

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Francois PIETTE]

> I'm a CS student and I often need to write number-crunching code dealing 
> with combinatorial optimization problems.
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by 
> relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard or 
> de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management 
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation and 
> low-level issues
> 6) "relatively simple and consistent"
>
> So I have considered these alternatives: FreePascal, Eiffel, Ada and 
> Modula-3.

You said you are a student. So probably your goal is to get a job after your 
studies. If this is the case, you forgot the most important thing regarding 
language selection: The possibility to get a job !

In that context, I wouldn't use any of the language you mentionned ! Ok, 
maybe FreePascal which would be replaced by Delphi or Delphi Prism once you 
are in a company for a real work. If it is not Delphi, then use C# or Java. 
It is likely that Delphi would be the fastest regarding number crunching.

Delphi has a large and alive community. You can find a lot of opensource and 
freeware for Delphi.

--
francois.piette@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

Francois PIETTE wrote:
> > I'm a CS student and I often need to write number-crunching code dealing
> > with combinatorial optimization problems.
> > In the past I used C, but now I have decided to change language.
> > I'm looking for a "better" one.
>
> > Here follow the features it should have, ranked approximately by
> > relevance:
>
> > 0) open-source support and an alive community
> > 1) directly compiled to efficient code
> > 2) statically typed and object-oriented, better if multi-paradigm
> > 3) general-purpose libraries (possibly standardized, either by standard or
> > de facto), including containers and some math abstractions.
> > 4) garbage collected. As an alternative, provide memory management
> > policies via libraries (e.g. memory pools and such)
> > 5) optional run-time checks and some kind of control over compilation and
> > low-level issues
> > 6) "relatively simple and consistent"
>
> > So I have considered these alternatives: FreePascal, Eiffel, Ada and
> > Modula-3.
>
> You said you are a student. So probably your goal is to get a job after your
> studies. If this is the case, you forgot the most important thing regarding
> language selection: The possibility to get a job !
>
> In that context, I wouldn't use any of the language you mentionned ! Ok,
> maybe FreePascal which would be replaced by Delphi or Delphi Prism once you
> are in a company for a real work. If it is not Delphi, then use C# or Java.
> It is likely that Delphi would be the fastest regarding number crunching.
>
> Delphi has a large and alive community. You can find a lot of opensource and
> freeware for Delphi.

The OP already knows C, so he will not have any problem finding a job.

Choosing a language based on perceived demand is a bad idea.  A CS
student is supposed to learn as many languages as possible so as to be
able to compare them later, and not become captive of any one
language.  Even more importantly, you need to learn paradigms; this
makes it easy to pick up any language that a job requires later on.

Conversely, hiring people based on the languages they know is an
equally bad idea.  If you think knowledge of a particular language is
a must for an engineering position, you are wrong.  Better criteria
include (but are not limited to) knowledge of sofware design (not just
"design patterns"; the real thing), algorithms, version control
systems, ability to work in teams, understanding of software
maintenance and general attitude towards software quality.

I think the OP understands all this very well; that's why he did not
mention job opportunities or market demand in his criteria for
language selection.

Banks and insurance companies also understand this; they train their
new hires in COBOL or Ada and don't care what languages they knew
previously.

(PS. comp.lang.pascal trimmed because it's archived now).

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

> Francois PIETTE wrote:
>
> > You said you are a student. So probably your goal is to get a job after your
> > studies. If this is the case, you forgot the most important thing regarding
> > language selection: The possibility to get a job !
>

Ludovic Brenta wrote:
> I think the OP understands all this very well; that's why he did not
> mention job opportunities or market demand in his criteria for
> language selection.
>

Let me expand on this: I don't care for the language to get a job.
I've studied less widespread languages and that's been a rewarding
experience so far. I learnt a lot and my skills at coding and problem-
solving improved considerably. Moreover, some job interviewers were
pleasantly surprised by the that  I "knew"  "unpopular" languages.
Apart from this, I'll be writing scientific algorithms for at least
the next two years and the only thing I care about is avoiding the
unnecessary headaches that I can get for using unsafe languages.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal Obry]

Andrea Taverna a �crit :
> Apart from this, I'll be writing scientific algorithms for at least
> the next two years and the only thing I care about is avoiding the
> unnecessary headaches that I can get for using unsafe languages.

Just for this the most suited languages are probably Ada and Eiffel.
Modula3 is probably also a good candidate, but I do not know the current
status (Open Source compiler? libraries? user community?) of this language.

Ada has the advantage of a standard and built-in concurrency.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hendrik Boom]

On Sat, 18 Jul 2009 20:46:27 +0200, Pascal Obry wrote:


> Modula3 is probably also a good candidate, but I do not know the current
> status (Open Source compiler? libraries? user community?) of this
> language.

Modula 3 has open source, but not GPL's compilers and libraries.
There should be a link to current development activities on its Wikipedia 
article.

> 
> Ada has the advantage of a standard and built-in concurrency.

Modula 3 also has built-in concurrency.  And a garbage collector.  And 
they get along.

-- hendrik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Hendrik Boom wrote:
> On Sat, 18 Jul 2009 20:46:27 +0200, Pascal Obry wrote:
>> Ada has the advantage of a standard and built-in concurrency.
> 
> Modula 3 also has built-in concurrency.  And a garbage collector.  And
> they get along.

Do any Modula 3 implementations have concurrent garbage collectors?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

>... and the /only/ thing I care about is avoiding the
> unnecessary headaches that I can get for using unsafe languages.

bad wording, should be:

and the /most important/ thing I care about...

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Andrea Taverna <a.tavs.NOSPAM@libero.it.invalid> writes:

> Hi folks!
>
> I'm a CS student and I often need to write number-crunching code
> dealing with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including
> general solvers.
>
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by
> standard or de facto), including containers and some math
> abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"

Have a look at Haskell.


> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.

Of those, I'd use Modula-3.
(you may also consider: Objective Modula-2)


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

On 18 Lug, 17:18, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Of those, I'd use Modula-3.
>
Are there m3 libraries that satisfy requirement 3?

Andrea

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Andrea Taverna <a.tavs@hotmail.it> writes:

> On 18 Lug, 17:18, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Of those, I'd use Modula-3.
>>
> Are there m3 libraries that satisfy requirement 3?

Check the Modula-3 FAQ.

Like all the other 'rare' programming language, you don't necessarily
have big and redundant libraries of variable quality (of which you may
spend time to choose wisely the one of best quality of course), but if
you're autonomous, you usually can find what you need, or develop it
more easily (remember, these unpopular programming languages are
unpopular also in part because it's easier to develop with them, so
the absence of a "library" is not usually a problem when you have a
concrete program to write).  And finally, while it's not a tasty
solution (because you lose in part the advantages of your advanced but
rare programming language), there's always the possibility of FFI
(Foreign Function Interface), letting you call functions in libraries
written in C or any other programming language following the C ABI.


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

On 2009-07-18, Pascal J. Bourguignon <pjb@informatimago.com> wrote:

|-----------------------------------------------------------------------------|
|"[..]                                                                        |
|                                                                             |
|Of those, I'd use Modula-3.                                                  |
|(you may also consider: Objective Modula-2)"                                 |
|-----------------------------------------------------------------------------|

This is the first I have heard of Objective Modula-2. Thank you.

Unfortunately, Wirthian languages tend to use structural equivalence
of types instead of occurrence equivalence, such as Modula-3 according
to
HTTP://web.archive.org/web/20051001044031/http://archive.dstc.edu.au/AU/staff/crawley/ada/m3-vs-ada.html#section4.1
and many interpretations of an early Pascal definition, so I suspect
that Modula-2 also had this weakness. The following excerpt from
HTTP://Objective.Modula2.net/
- "[..]
The base language is Modula-2 as defined by Niklaus Wirth in the
fourth edition of Programming in Modula-2 with the following omissions
and restrictions:

Omissions
[..]
* No subrange types
[..]" -
seems to indicate that it is even worse.

Ada allows you to choose for some types to be treated with occurrence
equivalence (called types in Ada:
WWW.AdaIC.org/standards/05rm/html/RM-3-2-1.html
) and for other types to be treated as
structurally equivalent (called subtypes in Ada:
WWW.AdaIC.org/standards/05rm/html/RM-3-2-2.html
) as you deem to be appropriate. Unlike for example Eiffel's Design by
Contract, this is not something which is activated or deactivated by a
compiler switch: a single Ada function can exploit both approaches at
the same time without being recompiled.

Regards,
Nicholas Paul Collin Gloucester

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hendrik Boom]

On Mon, 20 Jul 2009 10:13:31 +0000, Nicholas Paul Collin Gloucester wrote:

> 
> Unfortunately, Wirthian languages tend to use structural equivalence of
> types instead of occurrence equivalence, such as Modula-3 according to
> HTTP://web.archive.org/web/20051001044031/http://archive.dstc.edu.au/AU/
staff/crawley/ada/m3-vs-ada.html#section4.1

Modula 3 uses structural equivalence unless you specify otherwise.  You 
specify otherwise by using a BRANDED type.  That's actually a very 
effective compromise.

-- hendrik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Pascal J. Bourguignon wrote:
> Have a look at Haskell.

He said performance was important.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mark T.B. Carroll]

Jon Harrop <jon@ffconsultancy.com> writes:

> Pascal J. Bourguignon wrote:
>> Have a look at Haskell.
>
> He said performance was important.

And it's achievable in Haskell, especially with a bunch of the work
that's been done in GHC 6.6, 6.8, 6.10, and especially if you have
multiple cores. (I'm not just talking about things like short cut
fusion, but a bunch of library improvements like in ByteStrings.)

The caveat - and you may consider it a showstopper, but I don't - is
that it's easy for a newbie to write grossly inefficient Haskell. It
takes some understanding of what GHC's up to and what fancy stuff is
available, and some use of the profiler, to really be able to eke good
performance out of the system, and you may not think it acceptable that
(a) it's not easy for new users to figure out how to get good
performance from it and (b) if a part of the code has to be much changed
to make it fast, that part often ends up looking rather ugly. (I'd be
interested to see if Haskell fans can rebut me on those points, but
I bet some of the language shootout code still looks horrifying.)

Admittedly, the last I looked, it may be that Data.HashTable is still
slower than I'd have thought reasonable. But if I figure that if I
use it anyway then someone'll fix it and I'll notice the improvement
when I upgrade GHC. (-:

[ followups trimmed ]

Mark

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

Andrea Taverna wrote:
[...]
> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.
[...]
>      - Ada is best suited for large teams and/or critical software, thus
> it may be overkill for my work, OTH it could have anything I might
> happen to need.

I don't think it is overkill; Ada is not only an engineer's dream but
also an engineering student's dream because of its clear separation of
concerns (e.g. between inheritance (derived types) and encapsulation
(packages).

> What holds me from jumping onto Ada is the potential complexity

You don't have to learn all of the language all at once; you can start
with Ada as a "Pascal done right" (i.e. with separate compilation
built in and the "dangling else" problem fixed).  You can learn the OO
and generic features later, as you need them.

> It would be interesting  to hear the experience of other people learning
> Ada from the C/Java background.
> As for memory management (requirement 4), I heard there are different
> takes on the matter:
>  (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> reducing the need of manual management (MM)
>  (b) Ada libraries adopt idioms that further simplifies MM issues
>  (c) Conservative garbage collectors such as Bohem's can be used with
> Ada, and they are supposed to work "better" with Ada than with unsafe
> languages such as C and C++

I have to add:
  (d) controlled types allow you to control allocation and
deallocation without a garbage collector.

> So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> mercifully shed some light on the issue.

Yes, MM is definitely easier in Ada than in C; my experience with
Java's garbage collector is that (a) you never learn to manage memory,
and (b) is is very easy to run out of memory and get the infamous
OutOfMemoryError.  That has never happened to me in Ada, simply
because Ada forces me to think about this problem.

Another reason why Ada is easier than C is because you use pointers
only for what they were designed: dynamic allocation and
deallocation.  As a consequence, each time you introduce a pointer you
naturally think about memory management.  Contrast this to C where
simple parameter passing often requires pointers, and with Eiffel or
Java where everything is a pointer whether you like it or not.

> There seems to be a lot of Ada95 free documentation on the net, I guess
> it's suitable for Ada05 as well.

Yes indeed, thanks to backward compatibility.  Also there are now
several textbooks on Ada 2005, inclusing the free Wikibook "Ada
programming".

Finally, since strong static typing is one of your criteria, Ada has
the strongest and most powerful typing system I've ever seen in any
language, and it also has "escape hatches" to allow you to circumvent
it in extreme situations like interfacing directly to hardware.  This
typing system comes complete with compile-time and run-time checks
which you can selectively disable at the few places where performance
is critical.

I would perhaps add another criterion to your list: ease of
installation of the compiler and associated tools on your preferred
platform.  In one extreme, you have to bootstrap the compiler yourself
and then build all libraries from source; at the other end of the
spectrum, there are complete binary distributions ready to use.

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 18 juil, 17:50, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> [...] Contrast this to C where
> simple parameter passing often requires pointers, and with Eiffel or
> Java where everything is a pointer whether you like it or not.

There is not such a thing as pointers in Eiffel, there is only
references. A reference may be implemented as a pointer, but must not
be supposed so. An object in Eiffel, may be instanciated on the local
machine, or in a remote mahine over a network, or anything else one
may imagine. This is a abstract reference.

I was to reply to the original poster as well, but will come back
later for that.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Ludovic Brenta wrote:

> Contrast [Ada parameter passing] to C where
> simple parameter passing often requires pointers, and with Eiffel or
> Java where everything is a pointer whether you like it or not.

Neither is true: Eiffel has expanded objects and expanded
classes (if they work in an implementations). A name of a
variable will NOT be attached to some object (a reference)
but denotes exactly one object.  Also, expanded objects
Eiffel prevent the aliasing that is possible with pointers
of references.

Java has had basic types that have no references forever.
Wrappers were added later.  However, in this case neither
seems a good compensation for the other.

I do not mean these remarks to be a statement favoring
these or others languages.

*

Is number crunching going to be done in parallel?  Eiffel's
separate classes (whose objects execute on a conceptual
"processor") is not fully available yet.  I'd think that control
of fundamentals of concurrent execution is, however, readily
available with Ada's concurrent types.

Ada's base type system---like Modula's it features name
equivalence---should help abstracting your numeric types
most efficiently, and precisely, as you decide yourself
about bits, ranges, and optionally representation.



-- 
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

Ludovic Brenta posted:
|--------------------------------------------------------------------------|
|"[..]                                                                     |
|                                                                          |
|Finally, since strong static typing is one of your criteria, Ada has      |
|the strongest and most powerful typing system I've ever seen in any       |
|language, and it also has "escape hatches" to allow you to circumvent     |
|it in extreme situations like interfacing directly to hardware.  This     |
|typing system comes complete with compile-time and run-time checks        |
|[..]                                                                      |
|                                                                          |
|[..]"                                                                     |
|--------------------------------------------------------------------------|

It is not necessary to circumvent the type system when interfacing to
hardware. An Ada fixed type (which unlike a FORTRAN fixed type does
not necessarily need to be an integer) can be used with a
representation clause for strongly typed memory-mapped I/O.

With kind regards,
Nicholas Paul Collin Gloucester

A few Ada questions

[Andrea Taverna]

I've got a few questions about Ada, generated from discussion
<h3sln0$rhm$2@news.eternal-september.org>.

I apologize for my annoying newbieness :D

On 18 Lug, 17:50, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Andrea Taverna wrote:
>
> [...]
>
> > So I have considered these alternatives: FreePascal, Eiffel, Ada and
> > Modula-3
[....]
> > As for memory management (requirement 4), I heard there are different
> > takes on the matter:
> >  (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> > reducing the need of manual management (MM)
> >  (b) Ada libraries adopt idioms that further simplifies MM issues
> >  (c) Conservative garbage collectors such as Bohem's can be used with
> > Ada, and they are supposed to work "better" with Ada than with unsafe
> > languages such as C and C++
>
> I have to add:
>   (d) controlled types allow you to control allocation and
> deallocation without a garbage collector.
>
> > So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> > mercifully shed some light on the issue.
>
> Yes, MM is definitely easier in Ada than in C; my experience with
> Java's garbage collector is that (a) you never learn to manage memory,
> and (b) is is very easy to run out of memory and get the infamous
> OutOfMemoryError.  That has never happened to me in Ada, simply
> because Ada forces me to think about this problem.
>
> Another reason why Ada is easier than C is because you use pointers
> only for what they were designed: dynamic allocation and
> deallocation.  As a consequence, each time you introduce a pointer you
> naturally think about memory management.  Contrast this to C where
> simple parameter passing often requires pointers, and with Eiffel or
> Java where everything is a pointer whether you like it or not.
>

So I took a deeper look at Ada, and if I'm not mistaken, the MM
support in Ada boils down to
1)  dynamic stack allocation
2) malloc/free with Unchecked_Allocation
3) Controlled types that allow you implement constructors and
destructors
4) Storage pools.

Apart from (1) and (4), (2) and (3) seem to provide the same
functionality of corresponding C++ features, with the notable
exception that (3) requires tagging the type (*).

As for (4), I couldn't find a practical example of storage pools usage
on the net, I'd really like to see one.
The storage pool I have in mind is the one used in ObjC/Cocoa, i.e. a
storage pool with ref-counted objects. Users can send retain/release
messages to increment/decrement the pool-allocated object's reference
count. In which way does this differ from storage pools in Ada?

I know that they have several benefits compared with pool-less
storage, you can define a homogeneously typed/sized pool improving the
memory management for associated types, and you can implement MM more
easily, but, still, the problems I have with MM (at least in C) are :
- application-specific code is intertwined with MM and vice versa. It
complicates interfaces and hinders reusability.
- objects have a graph-like relationship on which MM depends that
could not be easy to foresee.
- due to the graph relationship, refactoring MM code, which can ease
MM itself, gets harder.
How is Ada supposed to help with this?

(*) besides, I infer that  the visibility checks required for
controlled types exposed at inner levels can be disabled at run-time,
right?

Finally, I'd have a question about the standard container library. I'm
probably a bit confused since I've recently been hopping from a
language to the other, but I saw that Containers do not define
interfaces and Cursors types are not tagged.
As such I'm not sure whether I can extend new containers from standard
ones, including defining new cursors, while having polymorphic
behaviour.
For example, can I define a linked-list implemented with an array by
deriving a standard container?

thanks,

Andrea

Re: A few Ada questions

[Ludovic Brenta]

Andrea Taverna wrote on comp.lang.ada:
> I've got a few questions about Ada, generated from discussion
> <h3sln0$rh...@news.eternal-september.org>.
>
> I apologize for my annoying newbieness :D
>
> On 18 Lug, 17:50, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>
>
> > Andrea Taverna wrote:
>
> > [...]
>
> > > So I have considered these alternatives: FreePascal, Eiffel, Ada and
> > > Modula-3
> [....]
> > > As for memory management (requirement 4), I heard there are different
> > > takes on the matter:
> > >  (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> > > reducing the need of manual management (MM)
> > >  (b) Ada libraries adopt idioms that further simplifies MM issues
> > >  (c) Conservative garbage collectors such as Bohem's can be used with
> > > Ada, and they are supposed to work "better" with Ada than with unsafe
> > > languages such as C and C++
>
> > I have to add:
> >   (d) controlled types allow you to control allocation and
> > deallocation without a garbage collector.
>
> > > So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> > > mercifully shed some light on the issue.
>
> > Yes, MM is definitely easier in Ada than in C; my experience with
> > Java's garbage collector is that (a) you never learn to manage memory,
> > and (b) is is very easy to run out of memory and get the infamous
> > OutOfMemoryError.  That has never happened to me in Ada, simply
> > because Ada forces me to think about this problem.
>
> > Another reason why Ada is easier than C is because you use pointers
> > only for what they were designed: dynamic allocation and
> > deallocation.  As a consequence, each time you introduce a pointer you
> > naturally think about memory management.  Contrast this to C where
> > simple parameter passing often requires pointers, and with Eiffel or
> > Java where everything is a pointer whether you like it or not.
>
> So I took a deeper look at Ada, and if I'm not mistaken, the MM
> support in Ada boils down to
> 1)  dynamic stack allocation
> 2) malloc/free with Unchecked_Allocation
> 3) Controlled types that allow you implement constructors and
> destructors
> 4) Storage pools.
>
> Apart from (1) and (4), (2) and (3) seem to provide the same
> functionality of corresponding C++ features, with the notable
> exception that (3) requires tagging the type (*).

There are three ways for a type to be controlled: (a) be publicly
tagged and extend Ada.Finalization.Controlled; (b) be privately tagged
and extend Ada.Finalization.Controlled; (c) be untagged and contain a
controlled object.

Here is an example of (b):

with Ada.Finalization;
package P is
   type T is private;
   -- primitive operations here
private
   type T is new Ada.Finalization.Controlled with record ... end
record;
   overriding procedure Initialize (This : in out T);
   overriding procedure Adjust (This : in out T);
   overriding procedure Finalize (This : in out T);
end P;

In this situation, clients can use the type and its primitive
operations but cannot further extend it (compare to a "final" class in
Java).

(c) is more advanced, here is an example:

package P is
   type T is private;
   -- primitive operations here
private
   type Controller (Enclosing : access T) is new
Ada.Finalization.Controlled with null record;
   overriding procedure Initialize (This : in out Controller);
   overriding procedure Adjust (This : in out Controller);
   overriding procedure Finalize (This : in out Controller);

   type T is record -- note: untagged record
     C : Controller (Enclosing => T'Access);
   end record;
end P;

The procedures Initialize, Adjust and Finalize can see their
parameter's enclosing object (and therefore all other components) by
simply dereferencing This.Enclosing.

This pattern is useful for reference counting, among other things.

Note that T *may* be tagged for reasons unrelated to controlledness
and even extend another type.

> As for (4), I couldn't find a practical example of storage pools usage
> on the net, I'd really like to see one.
> The storage pool I have in mind is the one used in ObjC/Cocoa, i.e. a
> storage pool with ref-counted objects. Users can send retain/release
> messages to increment/decrement the pool-allocated object's reference
> count. In which way does this differ from storage pools in Ada?

Ada's storage pools are orthogonal to ref-counted objects.  One
example is in the GNAT run-time library, see:

http://gcc.gnu.org/viewcvs/trunk/gcc/ada/g-debpoo.ads?view=markup

> I know that they have several benefits compared with pool-less
> storage, you can define a homogeneously typed/sized pool improving the
> memory management for associated types, and you can implement MM more
> easily, but, still, the problems I have with MM (at least in C) are :
> - application-specific code is intertwined with MM and vice versa. It
> complicates interfaces and hinders reusability.
> - objects have a graph-like relationship on which MM depends that
> could not be easy to foresee.
> - due to the graph relationship, refactoring MM code, which can ease
> MM itself, gets harder.
> How is Ada supposed to help with this?

I guess you'll have to see for yourself how the combination of
features listed above helps with the problem. However, you still have
to manage memory in Ada; the problem does not magically disappear.

> (*) besides, I infer that  the visibility checks required for
> controlled types exposed at inner levels can be disabled at run-time,
> right?

This is compiler-specific but, in general, yes.

> Finally, I'd have a question about the standard container library. I'm
> probably a bit confused since I've recently been hopping from a
> language to the other, but I saw that Containers do not define
> interfaces and Cursors types are not tagged.
> As such I'm not sure whether I can extend new containers from standard
> ones, including defining new cursors, while having polymorphic
> behaviour.
> For example, can I define a linked-list implemented with an array by
> deriving a standard container?

I'm not an expert on this subject to I'll defer to someone else to
enlighten both of us :)

HTH

--
Ludovic Brenta.

Re: A few Ada questions

[AdaMagica]

Hu Ludovic,

that's dangerous what you proposed:
-----------------------------------
private with Ada.Finalization;

package Ludovic is

  type T is private;

  -- primitive operations here
  procedure Show (X: in T);

private

  type Controller (Enclosing: access T) is new
Ada.Finalization.Controlled with null record;

  overriding procedure Initialize (This: in out Controller);
  overriding procedure Adjust     (This: in out Controller);
  overriding procedure Finalize   (This: in out Controller);

  type T is record -- note: untagged record
    C: Controller (Enclosing => T'Access);
    I: Integer;
  end record;

end Ludovic;
with Ada.Text_IO;
use  Ada.Text_IO;

package body Ludovic is

  I: Integer := 0;

  overriding procedure Initialize (This: in out Controller) is
  begin
    I := I + 1;
    This.Enclosing.I := I;
  end Initialize;

  overriding procedure Adjust (This: in out Controller) is
  begin
    This.Enclosing.I := This.Enclosing.I + 1;
  end Adjust;

  overriding procedure Finalize (This: in out Controller) is
  begin
    null;
  end Finalize;

  procedure Show (X: in T) is
  begin
    Put_Line (Integer'Image (X.I) & Integer'Image (X.C.Enclosing.I));
  end Show;

end Ludovic;
with Ada.Text_IO;
use  Ada.Text_IO;

with Ludovic;

procedure Brenta is

  X, Y: Ludovic.T;

begin

  Ludovic.Show (X);
  Ludovic.Show (Y);
  New_Line;

  X := Y;
  Ludovic.Show (X);  -- X.C points to Y - that's surely not what you
want.
  Ludovic.Show (Y);
  New_Line;

end Brenta;

Making a nonlimited type controlled by means of a controlled component

[Ludovic Brenta]

AdaMagica wrote on comp.lang.ada:
> Hu Ludovic ,
>
> that's dangerous what you proposed:
> -----------------------------------
> private with Ada.Finalization;
>
> package Ludovic is
>
>   type T is private;
>
>   -- primitive operations here
>   procedure Show (X: in T);
>
> private
>
>   type Controller (Enclosing: access T) is new
> Ada.Finalization.Controlled with null record;
>
>   overriding procedure Initialize (This: in out Controller);
>   overriding procedure Adjust     (This: in out Controller);
>   overriding procedure Finalize   (This: in out Controller);
>
>   type T is record -- note: untagged record
>     C: Controller (Enclosing => T'Access);
>     I: Integer;
>   end record;
>
> end Ludovic;
> with Ada.Text_IO;
> use  Ada.Text_IO;
>
> package body Ludovic is
>
>   I: Integer := 0;
>
>   overriding procedure Initialize (This: in out Controller) is
>   begin
>     I := I + 1;
>     This.Enclosing.I := I;
>   end Initialize;
>
>   overriding procedure Adjust (This: in out Controller) is
>   begin
>     This.Enclosing.I := This.Enclosing.I + 1;
>   end Adjust;
>
>   overriding procedure Finalize (This: in out Controller) is
>   begin
>     null;
>   end Finalize;
>
>   procedure Show (X: in T) is
>   begin
>     Put_Line (Integer'Image (X.I) & Integer'Image (X.C.Enclosing.I));
>   end Show;
>
> end Ludovic;
> with Ada.Text_IO;
> use  Ada.Text_IO;
>
> with Ludovic;
>
> procedure Brenta is
>
>   X, Y: Ludovic.T;
>
> begin
>
>   Ludovic.Show (X);
>   Ludovic.Show (Y);
>   New_Line;
>
>   X := Y;
>   Ludovic.Show (X);  -- X.C points to Y - that's surely not what you
> want.
>   Ludovic.Show (Y);
>   New_Line;
>
> end Brenta;

Darn, you're right. I hadn't thought of that. Now I understand why Ada
95 requires T to be limited (in this case the problem goes away, since
assignment is forbidden).  What worries me the most is that AI402,
which allowed access discriminants on nonlimited types, does not
mention this issue at all.

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00402.txt?rev=1.5

Randy, do you have an opinion on this, or should I raise the problem
with the ARG?

--
Ludovic Brenta.

Re: Making a nonlimited type controlled by means of a controlled component

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:31bb0f0b-9655-4bda-81c3-e8f7855a1ee9@c14g2000yqm.googlegroups.com...
...
> Randy, do you have an opinion on this, or should I raise the problem
> with the ARG?

I'm not sure. The problem is that the assignment ought to raise 
Constraint_Error, because the discriminants don't match, and the components 
are constrained:

   X := Y; -- Ought to raise Constraint_Error.

   X.C.Enclosing = X'Access
   Y.C.Enclosing = Y'Access

But I'm not sure if the language actually requires making such a check 
(generally, implementations assume that the constraints on subcomponents 
have to be OK - whether the language says this or not I'm not sure).

An implementation that changes the discriminant X.C.Enclosing is surely 
wrong (can't change a constrained discriminant!). But one could imagine just 
copying the contents without copying the discriminant.

So there might be benefit of a comment in order to look at the issue in more 
detail.

                                              Randy.

P.S. The original example was:

private with Ada.Finalization;

package Ludovic is

  type T is private;

  -- primitive operations here
  procedure Show (X: in T);

private

  type Controller (Enclosing: access T) is new
Ada.Finalization.Controlled with null record;

  overriding procedure Initialize (This: in out Controller);
  overriding procedure Adjust     (This: in out Controller);
  overriding procedure Finalize   (This: in out Controller);

  type T is record -- note: untagged record
    C: Controller (Enclosing => T'Access);
    I: Integer;
  end record;

end Ludovic;
with Ada.Text_IO;
use  Ada.Text_IO;

package body Ludovic is

  I: Integer := 0;

  overriding procedure Initialize (This: in out Controller) is
  begin
    I := I + 1;
    This.Enclosing.I := I;
  end Initialize;

  overriding procedure Adjust (This: in out Controller) is
  begin
    This.Enclosing.I := This.Enclosing.I + 1;
  end Adjust;

  overriding procedure Finalize (This: in out Controller) is
  begin
    null;
  end Finalize;

  procedure Show (X: in T) is
  begin
    Put_Line (Integer'Image (X.I) & Integer'Image (X.C.Enclosing.I));
  end Show;

end Ludovic;
with Ada.Text_IO;
use  Ada.Text_IO;

with Ludovic;

procedure Brenta is

  X, Y: Ludovic.T;

begin

  Ludovic.Show (X);
  Ludovic.Show (Y);
  New_Line;

  X := Y; -- What happens here?? X.C.Enclosing must not be changed, right?
  Ludovic.Show (X);
  Ludovic.Show (Y);
  New_Line;

end Brenta; 

Re: Making a nonlimited type controlled by means of a controlled component

[Adam Beneschan]

On Aug 14, 3:21 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > Randy, do you have an opinion on this, or should I raise the problem
> > with the ARG?
>
> I'm not sure. The problem is that the assignment ought to raise
> Constraint_Error, because the discriminants don't match, and the components
> are constrained:
>
>    X := Y; -- Ought to raise Constraint_Error.
>
>    X.C.Enclosing = X'Access
>    Y.C.Enclosing = Y'Access
>
> But I'm not sure if the language actually requires making such a check
> (generally, implementations assume that the constraints on subcomponents
> have to be OK - whether the language says this or not I'm not sure).

I looked over the Dynamic Semantics of assignment, and I don't think
there's anything in the language that requires a check.  The value is
converted to the target's subtype, which doesn't do anything here
since the source and target have the same subtypes (obviously if T
were a discriminated type, this conversion would check the
discriminant, but it isn't).  Then the converted value "becomes" the
value of the target.  I don't see anything to the effect that
assignment of a record recursively involves "assignment" of the
components; it seems to work on the entire record only.

So this looks like an error in the language to me.

                                         -- Adam

Re: A few Ada questions

[Dmitry A. Kazakov]

On Thu, 23 Jul 2009 15:58:21 -0700 (PDT), Andrea Taverna wrote:

> As for (4), I couldn't find a practical example of storage pools usage
> on the net, I'd really like to see one.

http://www.dmitry-kazakov.de/ada/components.htm

> The storage pool I have in mind is the one used in ObjC/Cocoa, i.e. a
> storage pool with ref-counted objects. Users can send retain/release
> messages to increment/decrement the pool-allocated object's reference
> count. In which way does this differ from storage pools in Ada?

The above link has several implementations of storage pools as well as
reference counted objects. Storage pools implementations there are used for
areas (for example to allocate nodes of a parsing tree) and for
implementation of doubly-linked lists (list nodes are obtained per
allocation rather than per inheritance or aggregation). Reference counting
GC is a related but different story.

> I know that they have several benefits compared with pool-less
> storage, you can define a homogeneously typed/sized pool improving the
> memory management for associated types, and you can implement MM more
> easily, but, still, the problems I have with MM (at least in C) are :
> - application-specific code is intertwined with MM and vice versa. It
> complicates interfaces and hinders reusability.

Arguably, object scopes when not nested are application-specific.

> - objects have a graph-like relationship on which MM depends that
> could not be easy to foresee.

Like above, the relation uses-required should come from the application
domain. I think in most cases difficulties arise when these get intermixed
with some implementation artefacts.

> - due to the graph relationship, refactoring MM code, which can ease
> MM itself, gets harder.

I have a suspicion that MM code should not be refactored at all. In
particular I am strongly against GC.

> How is Ada supposed to help with this?

By avoiding pointers. Ada offers various ways to do things without explicit
memory allocation.

> As such I'm not sure whether I can extend new containers from standard
> ones, including defining new cursors, while having polymorphic
> behaviour.

That won't work because Ada does not have multiple dispatch (MI). When you
derive from the container and from the cursor then to have it polymorphic
you need operations dispatching in both container and cursor. This is MI,
which is absent, alas.

> For example, can I define a linked-list implemented with an array by
> deriving a standard container?

No, because interface inheritance from concrete types is also absent in
Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: A few Ada questions

[Colin Paul Gloster]

On Fri, 24 Jul 2009, Dmitry A. Kazakov wrote:

|---------------------------------------------------------------------------|
|"[..]                                                                      |
|                                                                           |
|That won't work because Ada does not have multiple dispatch (MI). When you |
|derive from the container and from the cursor then to have it polymorphic  |
|you need operations dispatching in both container and cursor. This is MI,  |
|which is absent, alas.                                                     |
|                                                                           |
|[..]"                                                                      |
|---------------------------------------------------------------------------|

The particular example give involves multiple inheritance, but in
general I do not believe that multiple inheritance is needed for
multiple dispatch (multimethods).

Regards,
Colin Paul

Re: A few Ada questions

[Dmitry A. Kazakov]

On Fri, 24 Jul 2009 15:26:05 +0000, Colin Paul Gloster wrote:

> On Fri, 24 Jul 2009, Dmitry A. Kazakov wrote:
> 
>|---------------------------------------------------------------------------|
>|"[..]                                                                      |
>|                                                                           |
>|That won't work because Ada does not have multiple dispatch (MI). When you |
>|derive from the container and from the cursor then to have it polymorphic  |
>|you need operations dispatching in both container and cursor. This is MI,  |
>|which is absent, alas.                                                     |
>|                                                                           |
>|[..]"                                                                      |
>|---------------------------------------------------------------------------|
> 
> The particular example give involves multiple inheritance, but in
> general I do not believe that multiple inheritance is needed for
> multiple dispatch (multimethods).

Yes, you are right it was a typo error, should be "MD".

Interestingly, for the container - cursor case as in many other cases, one
actually needs only a "half" of MD.. It is not the whole matrix of possible
combinations container type x cursor type, but rather its diagonal, which
has targets. Physically it is still single dispatch which only appears as
multiple dispatch.

I don't know if one could take any advantage or simplification from this.
For multi-methods Ada already has this sort of dispatch. One can declare a
primitive operation with two controlling arguments of same type:

   type Container is tagged ...;
   procedure Copy (From : Container; To : in out Container):
      -- This OK since Ada 95

If tagged Cursor could derive its tags from the corresponding container's
tag, we could have "same" case. Considering:

   type Container is tagged ...;
   type Cursor is tagged ...;
   for Cursor'Tag use new Container'Tag; -- This is not Ada

   procedure Index (List : Container; Index : Cursor) return Element;

Allowed because Container'Tag and Cursor'Tag are same / synchronous.
Overriding Index would be possible only when both Container and Index are
synchronously derived from the base.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[BGB / cr88192]

"Andrea Taverna" <a.tavs.NOSPAM@libero.it.invalid> wrote in message 
news:h3sln0$rhm$2@news.eternal-september.org...
> Hi folks!
>
> I'm a CS student and I often need to write number-crunching code dealing 
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their 
> performance against other previously-known solutions, including general 
> solvers.
>
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>

("better" is debatable... some define it in terms of more subjective 
aspects, and others are more pragmatic about the matter...).


> Here follow the features it should have, ranked approximately by 
> relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard or 
> de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management 
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation and 
> low-level issues
> 6) "relatively simple and consistent"
>
> So I have considered these alternatives: FreePascal, Eiffel, Ada and 
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are the 
> impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.
>

although I don't personally use it (for varried and numerous reasons), have 
you considered Java?...

afaik, modern Java involves a fair amount of JIT-time optimization, and so 
for carefully written code can be performance-competative with C and C++...

it is a similar situation with C#.

(the big cost in my case, however, is not performance, but that they depend 
on these particular VMs...).


for my uses though, I typically use C and C++ (and ASM...). these languages 
are just best suited for what I do with them.


of those listed, FreePascal and Ada seem like ok bets.

the main cost is that they have far smaller development communities than C 
and Java and like, and like I have seen with many smaller languages, the 
developer communities often tend to have a kind of fanatical zeal... (in 
place of a more pragmatic outlook...).

Delphi may be worth looking into, given it is similar to FreePascal, and has 
(AFAIK) a larger developer base.


> TIA
>    --> Impressions I got for each language
>
>     - FreePascal is a safe and modular alternative to C and C++,  but it 
> is also close to the latter in terms of expressiveness. Moreover it 
> doesn't seem to have the libraries I need.
> ==>Qualifies for 0,1,2,5. Not sure about 3 and 4
>
>     - Eiffel is geared toward application programming in 
> medium/large-sized teams relying heavily on OO modelling. It is designed 
> for (re)usability, correctness and efficiency in this order.  My needs are 
> somewhat different though.
> The main gripe I have with Eiffel is the lack of a well-documented 
> standard gpl'ed library.
> GOBO and EiffelBase seem to have incomplete or non-free documentation and 
> I couldn't find tutorials; as such, I couldn't get a clear picture about 
> them.
> ==> Qualifies for 0,1,2,4,5 and 6.  Not sure about 3.
>
>     - Ada is best suited for large teams and/or critical software, thus it 
> may be overkill for my work, OTH it could have anything I might happen to 
> need.
> What holds me from jumping onto Ada is the potential complexity
> It would be interesting  to hear the experience of other people learning 
> Ada from the C/Java background.
> As for memory management (requirement 4), I heard there are different 
> takes on the matter:
> (a) Ada uses dynamic stack allocation a lot, and in a transparent way, 
> reducing the need of manual management (MM)
> (b) Ada libraries adopt idioms that further simplifies MM issues
> (c) Conservative garbage collectors such as Bohem's can be used with Ada, 
> and they are supposed to work "better" with Ada than with unsafe languages 
> such as C and C++
>
> So can MM be said to be easier in Ada than in C? I hope Ada-ers will 
> mercifully shed some light on the issue.
>

conservative GC typically works plenty well in C, at least as long as people 
refrain from esoteric trickery ("oh I can't xor pointers or store them in a 
file, thus GC is useless", ...).

granted, conservative GC does work better in single-threaded C and C++ than 
in multithreaded code...


> There seems to be a lot of Ada95 free documentation on the net, I guess 
> it's suitable for Ada05 as well.
> ==> Qualifies for 0,1,2,3,5 and, partially, 4
>
>     - Modula-3 is simpler/smaller than Ada and has been successfully used 
> for system/application programming.
> It seems to be the most consistent, simple and easy to grok, but I 
> couldn't find any container/math library ready to use.
> ==> Qualifies for 0,1,2,4,5,6. 

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ben Bacarisse]

Andrea Taverna <a.tavs.NOSPAM@libero.it.invalid> writes:
<snip>
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by
> standard or de facto), including containers and some math
> abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"
>
> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.

Other people have been adding to your list but Objective Caml is still
missing.  It ticks all you boxes.

-- 
Ben.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

On 2009-07-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

|-----------------------------------------------------------------------------|
|"Andrea Taverna <a.tavs.NOSPAM@libero.it.invalid> writes:                    |
|<snip>                                                                       |
|> In the past I used C, but now I have decided to change language.           |
|> I'm looking for a "better" one.                                            |
|>                                                                            |
|> Here follow the features it should have, ranked approximately by relevance:|
|>                                                                            |
|> 0) open-source support and an alive community                              |
|> 1) directly compiled to efficient code                                     |
|> 2) statically typed and object-oriented, better if multi-paradigm          |
|> 3) general-purpose libraries (possibly standardized, either by             |
|> standard or de facto), including containers and some math                  |
|> abstractions.                                                              |
|> 4) garbage collected. As an alternative, provide memory management         |
|> policies via libraries (e.g. memory pools and such)                        |
|> 5) optional run-time checks and some kind of control over compilation      |
|> and low-level issues                                                       |
|> 6) "relatively simple and consistent"                                      |
|>                                                                            |
|> So I have considered these alternatives: FreePascal, Eiffel, Ada and       |
|> Modula-3.                                                                  |
|                                                                             |
|Other people have been adding to your list but Objective Caml is still       |
|missing.  It ticks all you boxes."                                           |
|-----------------------------------------------------------------------------|

Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;
CeML; or Gaml?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ben Bacarisse]

Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:

> On 2009-07-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> |-----------------------------------------------------------------------------|
> |"Andrea Taverna <a.tavs.NOSPAM@libero.it.invalid> writes:                    |
> |<snip>                                                                       |
> |> In the past I used C, but now I have decided to change language.           |
> |> I'm looking for a "better" one.                                            |
> |>                                                                            |
> |> Here follow the features it should have, ranked approximately by relevance:|
> |>                                                                            |
> |> 0) open-source support and an alive community                              |
> |> 1) directly compiled to efficient code                                     |
> |> 2) statically typed and object-oriented, better if multi-paradigm          |
> |> 3) general-purpose libraries (possibly standardized, either by             |
> |> standard or de facto), including containers and some math                  |
> |> abstractions.                                                              |
> |> 4) garbage collected. As an alternative, provide memory management         |
> |> policies via libraries (e.g. memory pools and such)                        |
> |> 5) optional run-time checks and some kind of control over compilation      |
> |> and low-level issues                                                       |
> |> 6) "relatively simple and consistent"                                      |
> |>                                                                            |
> |> So I have considered these alternatives: FreePascal, Eiffel, Ada and       |
> |> Modula-3.                                                                  |
> |                                                                             |
> |Other people have been adding to your list but Objective Caml is still       |
> |missing.  It ticks all you boxes."                                           |
> |-----------------------------------------------------------------------------|
>
> Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;
> CeML; or Gaml?

No reason at all if these all meet the OP's needs.  I don't know them
so I could not reasonably suggest them.  OCaml is the only ML-like
language I know that is object oriented as asked for.  A quick look at
some of your list suggests that not all of them are.

-- 
Ben.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Nicholas Paul Collin Gloucester wrote:
> Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;
> CeML; or Gaml?

None of them have alive communities except Bigloo which is a Scheme
implementation and, therefore, is not statically typed.

In contrast, OCaml has a substantial community, lots of libraries and offers
superb performance with one of the most expressive static type systems in
existence. OCaml's proprietary cousin at Microsoft, F#, is also a superb
high-performance language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Jon Harrop wrote:

|----------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester wrote:                               |
|> Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;|
|> CeML; or Gaml?                                                      |
|                                                                      |
|[..] Bigloo which is a Scheme                                         |
|implementation and, therefore, is not statically typed.               |
|                                                                      |
|[..]"                                                                 |
|----------------------------------------------------------------------|

I am sorry for making that mistake.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrew Reilly]

On Tue, 21 Jul 2009 14:40:39 +0000, Colin Paul Gloster wrote:

> On Tue, 21 Jul 2009, Jon Harrop wrote:
> 
> |----------------------------------------------------------------------|
> |"Nicholas Paul Collin Gloucester wrote:                               |
> |> Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;|
> |> CeML; or Gaml?                                                      |
> |                                                                      |
> |[..] Bigloo which is a Scheme                                         |
> |implementation and, therefore, is not statically typed.               |
> |                                                                      |
> |[..]"                                                                 |
> |----------------------------------------------------------------------|
> 
> I am sorry for making that mistake.

It's not that much of a mistake, I believe.  My understanding was that 
Manuel Serrano started bigloo with the intention of making a compilation 
back-end that had both ML and scheme front-ends.  Only the scheme front-
end survives, and bigloo-scheme is fairly unique in how thoroughly it 
allows and encourages type annotations (which it uses for optimization 
purposes, I believe.)  It also has a JVM-bytecode back-end, fwiw, but the 
native (via C) back-end is said to produce better/faster code.  [Bigloo 
also does classes and objects, so it could tick all of the OP's boxes, 
except for the Wirthian syntax one...]

Cheers,

-- 
Andrew

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrew Reilly]

On Sat, 18 Jul 2009 16:19:40 +0200, Andrea Taverna wrote:

> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language. Can you help me? Feel free to
> recommend other languages as well.

These are all fine choices of languages, but I wonder how much benefit 
you will be getting for yourself, as a sole-coder programming to produce 
results, rather than code?

I think that you should consider stretching yourself a bit further: 
others have suggested Ocaml and Hascall.  I'd add that modern Common Lisp 
(eg SBCL) ticks all of your boxes too.  You might be surprised that there 
are some scheme implementations that will fit, too, and both of those are 
perhaps more "multi-paradigm" than the languages that you've got on your 
short list.

In the end, though, you really need to check your decision criteria:

1: how fast is fast enough?  Will you be waiting weeks for a run to 
complete, or will you be coding for weeks and then running for ten 
minutes?  If the latter, something more expressive but perhaps a little 
further from "speed of light" ASM might be more helpful.  Also, if your 
code will be spending most of its time in optimized library matrix 
algebra code (eg atlas) then it doesn't matter much how the language 
itself fares.  (eg Matlab is slow but expressive unless you use it as a 
wrapper around BLAS/LAPAC, in which case it's hard to get close to.)

2: How much do you really need object orientation?  Inheritance isn't 
necessarily particularly useful for a lot of numerical code, and there 
are lighter-weight strategies that support modular and safe coding.

3: Libraries are good to have.  You'll find that C and Fortran still have 
the lions share of the numerical ones, though.

4: Garbage collection is really nice to have, as a programmer.  Leave 
this one in, but recognize that (a) you can do it in C if you want to and 
(b) doing without involves more pain but can be made to work.  See (1).

5: C and Fortran don't give you much of this out of the box, it's true, 
but C has assert(), and used wisely and extensively in your own code will 
give you some of the same "catch mistakes early" benefit of language-
supported checks, and you can turn it off with -DNDEBUG.  The lisps and 
schemes typically have a very wide range of "knobs" to control the amount 
of run-time checking that they do.

6: C is simple and consistent.

When I had my own "C ennui" experience a couple of years ago, I picked 
scheme, on the understanding that sometimes I would probably have to 
still write some C and assembler to support C-using colleagues and for 
ultimate performance.  (And I wanted to learn something really different 
from C.)  I've been happy with the outcome, so far.

Cheers,

-- 
Andrew

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[mockturtle]

On Jul 19, 3:04 am, Andrew Reilly <andrew-newsp...@areilly.bpc-
users.org> wrote:
> On Sat, 18 Jul 2009 16:19:40 +0200, Andrea Taverna wrote:
> > So I have considered these alternatives: FreePascal, Eiffel, Ada and
> > Modula-3.
> > I have taken a look at all of them and I'm still undecided. Below are
> > the impressions I got for each language. Can you help me? Feel free to
> > recommend other languages as well.
>
(snip)
>
> 1: how fast is fast enough?  Will you be waiting weeks for a run to
> complete, or will you be coding for weeks and then running for ten
> minutes?  If the latter, something more expressive but perhaps a little
> further from "speed of light" ASM might be more helpful.  Also, if your
> code will be spending most of its time in optimized library matrix
> algebra code (eg atlas) then it doesn't matter much how the language
> itself fares.  (eg Matlab is slow but expressive unless you use it as a
> wrapper around BLAS/LAPAC, in which case it's hard to get close to.)
>

Just my 2c...

If you need to do heavy number-crunching, I would suggest Matlab or
its open-source brother Octave (http://www.gnu.org/software/octave/).
My main professional interests are in DSP and the three languages that
I use most are Matlab (for number-crunching problems) and Ruby (for
F&D scripts and/or text processing) and Ada (for everything else).
Since Matlab is not compiled, you do not reach the full theoretical
computational speed that you could achieve with your computer, but if
you write your code with a little care (that is, avoiding loops and
trying to write your problem as "vectorized" as possible) you can
achieve very good performances (your mileage can vary depend on your
specific problem, though).   The advantage of Matlab/Octave is that
you have a very large library of numerical algorithm and development
can be quite fast.  On the cons side, since it is easy to write "fast
and dirty" matlab scripts, matlab code can turn out more difficult to
mantain (this depends on your "style" too).

Hope this helps.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

I'm going to reply about OCaML, Haskell and CL via Andrew's post

On 19 Lug, 03:04, Andrew Reilly <andrew-newsp...@areilly.bpc-
users.org> wrote:
> I think that you should consider stretching yourself a bit further:
> others have suggested Ocaml and Hascall.  I'd add that modern Common Lisp
> (eg SBCL) ticks all of your boxes too.  You might be surprised that there
> are some scheme implementations that will fit, too, and both of those are
> perhaps more "multi-paradigm" than the languages that you've got on your
> short list.

I'm still learning CL and that's been enlightening so far.
I implemented Prim's MSTP algorithm with that, getting pretty
satisfying performance for large instances (thansk to
declare&friends).
However CL is dynamically typed, and my algorithms will hardly need
(its) dynamic typing. Out of curiosity, I've already planned to
reimplement an algorithm of mine, a branch-and-bound one, in CL to
see, among other things, how it compares in terms of effciency. In
future I'd like to write a neural-network toolbox similar to Mathlabs'
for CL as well. Note that these are *plans*, something I think of and
that I'll be sitting on for a long time ;^)

I looked at O'CaML a few times, and I've heard different opinions on
the usenet. I can't remember exactly, but it felt like having some
annoying idiosyncrasies both at language and implementation level.
I ruled it out because differs a lot from other languages (i.e.
algol's heirs) and I wanted a more familiar language, one I can
currently trust given my cultural preparation.

Finally Haskell. It requires a significant mental shift, something I
can't afford now. And I fear that lazy evaluation may cause a
disastrous performance loss with my algorithms when used improperly.
Too risky for now.

On 19 Lug, 03:04, Andrew Reilly <andrew-newsp...@areilly.bpc-
users.org> wrote:
> These are all fine choices of languages, but I wonder how much benefit
> you will be getting for yourself, as a sole-coder programming to produce
> results, rather than code?
>
For various reasons, that's not a problem. There are projects for
which I'll be alone anyway.

> 1: how fast is fast enough?  
It may be "just enough" or "as much as possible". For most of the
heuristic approaches the former, for exact ones the latter.

> 2: How much do you really need object orientation?  
None of the languages I listed prevents me from using modularity in
place of OO.

> 3: Libraries are good to have.  You'll find that C and Fortran still have
> the lions share of the numerical ones, though.
I can interface to both with any of the languages above IIRC.

> 4: Garbage collection is really nice to have, as a programmer.  Leave
> this one in, but recognize that (a) you can do it in C if you want to and
> (b) doing without involves more pain but can be made to work.  See (1).
>
Still, as I learnt with CL and C, the problem always reduces to these
recommendations:
- if you need dynamic memory, don't use it
- Manage memory as rarely as possible
- standard allocators suck

> 5: C and Fortran don't give you much of this out of the box,
I don't know Fortran, unfortunately
As for C, been there, done that. I never used assert because I strived
to organize the code in a more structured way, and that, together with
bug-fixing and writing comments to explain the code, took most of the
time.
In other terms, I recognized I was reimplementing what Ada, M3,
Eiffel.... give and optimize for free.
Now I want to check if what they offer is true. Eventually, less may
still be more, or not, who knows?

Andrea

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Andrea Taverna <a.tavs@hotmail.it> writes:
> I'm still learning CL and that's been enlightening so far.

Given that you have notions of CL, then you could postpone your choice
of programming language.  

You're interested in algorithms, so just write your algorithms in
s-exp forms.

I understand that it might be fun to let the computer execute the
algorithms to see how they work out (I assume you prove your
algorithms independantly of any execution, which I'll remind you can
only prove that you have errors, not that your algorithm is correct).

So you could write in Common Lisp the DSL (Domain Specific Language)
able to interpret or translate your algorithms into CL, for animation
purposes.


Later, when you have a collection of proven algorithms, you may write
(still in Common Lisp, why reject a winning team?), a translator to
convert your algorithmic s-exps into the target language of your
choice, be it Ada, Pascal, C, Eiffel, Fortran, Haskell, Modula-2 or
Modula-3, whatever you need.  It's almost trivial to generate such
code from a DSL expressed in s-exps.


C/USER1[602]> (algorithm gcd
                  (parameters (input a integer)
                              (input b integer))
                  (result integer)
                (cases
                 when (= a b) then (return a)
                 when (< a b) then (return (gcd (- b a) a))
                 when (> a b) then (return (gcd (- a b) b))))
GCD
C/USER1[603]> (gcd 42 12)
6
C/USER1[686]> (translate-to-c '(algorithm gcd
                                (parameters (input a integer)
                                 (input b integer))
                                (result integer)
                                (cases
                                 when (= a b) then (return a)
                                 when (< a b) then (return (gcd (- b a) a))
                                 when (> a b) then (return (gcd (- a b) b)))))

int gcd(int a,int b)
{
if((a)==(b)){
return(a);
}
else if((a)<(b)){
return(gcd((b)-(a),a));
}
else if((a)>(b)){
return(gcd((a)-(b),b));
}
}




-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

Andrea,

Sorroy for beeing late to reply, here is my little contribution.

I would like to say that if you are mainly to deal with algorithmics,
you may also add Lisp to your list (not joking, althought these words
together are a bit funny I know).

Here is an article I deeply agree with, except in some aspects :
http://www.paulgraham.com/icad.html

Well, the limitation is that if you need to be aware of some real-
world aspects, like the fact that no machine has an infinite register
width, then Lisp may not be the best solution (the author seems to
forget sometime about real-life).

But it your main scope is complexe structures and “ intelligent ” and
plastic-malleable algorithms, then Lisp may be a good idea, while it
would not be if data typing and real life range-limitations is one of
your concern (as an exemple).

Note: if I'm not wrong, there is a plan to add some lambda-expressions
like stuff in the next Ada revision (at least something which made me
think it was a bit looking like).

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Pascal J. Bourguignon wrote:

> Later, when you have a collection of proven algorithms, you may write
> (still in Common Lisp, why reject a winning team?), a translator to
> convert your algorithmic s-exps into the target language of your
> choice, be it Ada, Pascal, C, Eiffel, Fortran, Haskell, Modula-2 or
> Modula-3, whatever you need.  It's almost trivial to generate such
> code from a DSL expressed in s-exps.

How can a translation can be trivial unless it is but a
mere syntactic rewrite?  This way one dismisses both an
essential constraint and an opportunity: the programmed
algorithm, the computation, is performed in steps, by a
human, by a Lisp machine, by a von Neumann PU, or by
some innovative parallel computer, each having known
formal properties.  Is it possible to let these influence
the s-expressions (the algorithm, that is) such that
the "target language"'s features will be effective?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 19 juil, 20:02, Georg Bauhaus <see.reply...@maps.futureapps.de>
wrote:
> Pascal J. Bourguignon wrote:
> > Later, when you have a collection of proven algorithms, you may write
> > (still in Common Lisp, why reject a winning team?), a translator to
> > convert your algorithmic s-exps into the target language of your
> > choice, be it Ada, Pascal, C, Eiffel, Fortran, Haskell, Modula-2 or
> > Modula-3, whatever you need.  It's almost trivial to generate such
> > code from a DSL expressed in s-exps.
Oops, the previous was already about it

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Georg Bauhaus <see.reply.to@maps.futureapps.de> writes:

> Pascal J. Bourguignon wrote:
>
>> Later, when you have a collection of proven algorithms, you may write
>> (still in Common Lisp, why reject a winning team?), a translator to
>> convert your algorithmic s-exps into the target language of your
>> choice, be it Ada, Pascal, C, Eiffel, Fortran, Haskell, Modula-2 or
>> Modula-3, whatever you need.  It's almost trivial to generate such
>> code from a DSL expressed in s-exps.
>
> How can a translation can be trivial unless it is but a
> mere syntactic rewrite?  This way one dismisses both an
> essential constraint and an opportunity: the programmed
> algorithm, the computation, is performed in steps, by a
> human, by a Lisp machine, by a von Neumann PU, or by
> some innovative parallel computer, each having known
> formal properties.  Is it possible to let these influence
> the s-expressions (the algorithm, that is) such that
> the "target language"'s features will be effective?

Of course, it depends on your algorithmic language (DSL), and on the
target languages.

But mostly, it will be trivial, because the target languages are
themselves "algorithmic" languages.  Nominally, apart from Haskell,
all the language mentionned above are mere procedural languages in
which imperative algorithms will be trivial to transcribe, yes,
basically just a syntactic operation.

If we targetted Haskell, Lisp or Prolog, indeed it would be more
complex, since procedural algorithms don't translate well there (well
for Common Lisp, it would still translate well since Common Lisp is
really multi-paradigm a language which includes imperative procedural
code (it even has GOTO!), even if an experienced lisp programmer would
normally rewrite the imperative algorithms in more idiomatic (higher
level) lisp).


Moreover, notice how Pr. Knuth use a rather low level language to
describe his algorithms (a virtual machine language actually).  He
doesn't expect anything fancy  semantically from his algorithmic
language. http://www-cs-faculty.stanford.edu/~knuth/taocp.html


Therefore I stand on my affirmation, such a transformation is trivial.

-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Pascal J. Bourguignon wrote:

> Moreover, notice how Pr. Knuth use a rather low level language to
> describe his algorithms (a virtual machine language actually).  He
> doesn't expect anything fancy  semantically from his algorithmic
> language. http://www-cs-faculty.stanford.edu/~knuth/taocp.html

Actually, a paradigmatic counter-example of Knuths' is, I think,
Algorithm T (Topological sort in �2.2.3), which is I guess not
targeted at number crunching, but serves as an example of
ingenious use of hardware properties.  While the description,
"taking away nodes from a graph", is in a sense high level,
the data structures used, and the runnable program are just
about as far away from high level Lisp as can be, I'd think ;-)
So how could this be achieved in a general fashion, using
syntax transformation?
So a translation that yields this proven un-functional
data layout doesn't look so trivial to me; wouldn't
you end up writing algorithm-specific optimizer macros
or some such if you wanted the same efficiency to be gained
from a Lisp DSL?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 18 Jul., 16:19, Andrea Taverna <a.tavs.NOS...@libero.it.invalid>
wrote:
> Hi folks!
>
> I'm a CS student and I often need to write number-crunching code dealing
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including general
> solvers.
>
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.

Did you take a look at Seed7?

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jean-Pierre Rosen]

Andrea Taverna a écrit :
[...]
>     - Ada is best suited for large teams and/or critical software, thus
> it may be overkill for my work, OTH it could have anything I might
> happen to need.
> What holds me from jumping onto Ada is the potential complexity
As a long time teacher of Ada, let me elaborate on this particular issue.

1) More than complex, Ada is feature-rich, with some properties that do
not exist in most other languages (user defined elementary types,
discriminants, stack-allocated dynamic structures ...). Of course,
you'll have to learn about these features - if you want to use them.

2) Ada is extremely consistent. You'll have to learn the basic
principles, but once you've got them, you'll discover that all the
features follow the same logic. Therefore, the first step might be
higher than for other languages, but then everything appears logical and
easy to grasp.

3) Ada is simple to use, because difficulty of implementation has never
been an excuse for forbidding something that the user would expect to
work. However, that makes the language complex to compile, and part of
the alledged complexity of Ada refers to complexity of implementation,
not complexity of use. Of course, as a user, you don't care about this,
since you have compilers, even free ones, that implement the language
correctly, and this is checked by passing the validation suite (AKA ACATS).
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 20 juil, 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> 1) More than complex, Ada is feature-rich,
And its feature are logically or mathematically justified, that's what
make them easy to understand when needed. Trying to use some of its
features when they are not needed, is perhaps more difficult. That's
another good reason for the “ Pascal subset ” approach. This will also
imply that a too much lecture oriented course may not be well suited.
In some way, perhaps the traditional university approach is not well
suited (not all time).

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 20 Jul., 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Andrea Taverna a écrit :
> [...]>     - Ada is best suited for large teams and/or critical software, thus
> > it may be overkill for my work, OTH it could have anything I might
> > happen to need.
> > What holds me from jumping onto Ada is the potential complexity
>
> As a long time teacher of Ada, let me elaborate on this particular issue.
>
> 1) More than complex, Ada is feature-rich, with some properties that do
> not exist in most other languages (user defined elementary types,
> discriminants, stack-allocated dynamic structures ...). Of course,
> you'll have to learn about these features - if you want to use them.
>
> 2) Ada is extremely consistent. You'll have to learn the basic
> principles, but once you've got them, you'll discover that all the
> features follow the same logic. Therefore, the first step might be
> higher than for other languages, but then everything appears logical and
> easy to grasp.
>
> 3) Ada is simple to use, because difficulty of implementation has never
> been an excuse for forbidding something that the user would expect to
> work. However, that makes the language complex to compile, and part of
> the alledged complexity of Ada refers to complexity of implementation,

That is exactly the area where Ada left the path of Pascal. Pascal
was designed to be easy to implement. Nicklaus Wirth had good
reasons to keep the implementation simple. He once said (IIRC):

  What can be parsed easily by a compiler can also be
  parsed easily by a human and this can be an asset.

He probably did not use exactly this words, but they hopefully
describe his intentions.

Many languages try to make the job of writing a program easier
and at the same time make the job of reading programs is
harder. All this wonderful "do what I mean" concepts used by
many languages fail in some cases.

IMHO complex compilation processes are an indication
of hard-to-understand concepts or hard-to-read constructs.
As such a complex compilation process only seemingly
(and not really) makes programming easier.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jean-Pierre Rosen]

tm a �crit :
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
> 
>   What can be parsed easily by a compiler can also be
>   parsed easily by a human and this can be an asset.
Parsing is not the difficult part of an Ada compiler.
> [...] 

> Many languages try to make the job of writing a program easier
> and at the same time make the job of reading programs is
> harder. All this wonderful "do what I mean" concepts used by
> many languages fail in some cases.
True, but this does not apply to Ada. Ada was designed with requirements
that explicitely required ease of reading over ease of writing.

> IMHO complex compilation processes are an indication
> of hard-to-understand concepts or hard-to-read constructs.
> As such a complex compilation process only seemingly
> (and not really) makes programming easier.
> 
Not at all. Let me take an example to show you what I meant. If you have
a record (in Pascal) or struct (in C), you are not allowed to compare
them directly. Why? because records may contain gaps that shouldn't be
compared, and skipping the gaps was deemed too much work for the
compiler. In Ada, there is no problem writing:
   if Rec1 = Rec2 then ....

would you argue that it is /less/readable than writing:
   if Rec1.F1 = Rec2.F1 and Rec1.F2 = Rec2.F2 and Rec1.F2 = Rec2.F3...


-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 20 Jul., 17:14, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> tm a écrit :> That is exactly the area where Ada left the path of Pascal. Pascal
> > was designed to be easy to implement. Nicklaus Wirth had good
> > reasons to keep the implementation simple. He once said (IIRC):
>
> >   What can be parsed easily by a compiler can also be
> >   parsed easily by a human and this can be an asset.
>
> Parsing is not the difficult part of an Ada compiler.

I once met somebody, who wrote the front end of an Ada compiler, and
he told me a different story. E.g.: He said that a special function
needs to read ahead just to find out the semantic of a parenthesis.
In Pascal such read ahead is not necessary. Another friend told me
stories about a buggy early Ada compiler where it was necessary to
"code around" compiler bugs.

> > [...]
> > Many languages try to make the job of writing a program easier
> > and at the same time make the job of reading programs is
> > harder. All this wonderful "do what I mean" concepts used by
> > many languages fail in some cases.
>
> True, but this does not apply to Ada. Ada was designed with requirements
> that explicitely required ease of reading over ease of writing.

Agree, but not all things designed to ease reading do so.

> > IMHO complex compilation processes are an indication
> > of hard-to-understand concepts or hard-to-read constructs.
> > As such a complex compilation process only seemingly
> > (and not really) makes programming easier.
>
> Not at all. Let me take an example to show you what I meant. If you have
> a record (in Pascal) or struct (in C), you are not allowed to compare
> them directly. Why? because records may contain gaps that shouldn't be
> compared, and skipping the gaps was deemed too much work for the
> compiler. In Ada, there is no problem writing:
>    if Rec1 = Rec2 then ....

Neither in Seed7, which has the = and <> operators predefined for
all structs. Btw.: Why should gaps in a struct make problems? A
struct compare should call the compare functions of the elements
anyway.

IMHO such features do not make problems. I was referring to things
like overloading rules where the result of a function/operator is
taken into account.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm wrote:

> On 20 Jul., 17:14, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>>
>> Parsing is not the difficult part of an Ada compiler.
> 
> I once met somebody, who wrote the front end of an Ada compiler, and
> he told me a different story. E.g.: He said that a special function
> needs to read ahead just to find out the semantic of a parenthesis.

There is no need to know the semantics of parenthesis in order to parse
them. Semantic analysis is anther compilation phase.

The only moderately difficult part of Ada that requires short look ahead
are digraphs like "and then" (overloaded with "and"). There can be comments
and new lines between "and" and "then" in the digraph. However it does not
require any roll backs.

> Another friend told me
> stories about a buggy early Ada compiler where it was necessary to
> "code around" compiler bugs.

This problem still exist. (:-() This is not language specific, Delphi,
Borland C++, MSVC are no less buggy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Frank J. Lhota]

Dmitry A. Kazakov wrote:
> On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm wrote:
> 
>> On 20 Jul., 17:14, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>>> Parsing is not the difficult part of an Ada compiler.
>> I once met somebody, who wrote the front end of an Ada compiler, and
>> he told me a different story. E.g.: He said that a special function
>> needs to read ahead just to find out the semantic of a parenthesis.
> 
> There is no need to know the semantics of parenthesis in order to parse
> them. Semantic analysis is anther compilation phase.
> 
> The only moderately difficult part of Ada that requires short look ahead
> are digraphs like "and then" (overloaded with "and"). There can be comments
> and new lines between "and" and "then" in the digraph. However it does not
> require any roll backs.

IIRC "and then" is not that big an issue. The bigger issue is the two 
uses of single quotes: they delimit character constants, and they are 
used for qualified expressions. Consider an expression such as

      Foo'(',',',',',' ... )

Even with this complication, Ada is not a hard language to parse. C++ 
poses a considerably greater challenge, due to the dual use of < and > 
for both comparisons and for bracketing template parameters.

>> Another friend told me
>> stories about a buggy early Ada compiler where it was necessary to
>> "code around" compiler bugs.
> 
> This problem still exist. (:-() This is not language specific, Delphi,
> Borland C++, MSVC are no less buggy.
> 


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Sat, 25 Jul 2009 13:39:49 -0400, Frank J. Lhota wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm wrote:
>> 
>>> On 20 Jul., 17:14, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>>>> Parsing is not the difficult part of an Ada compiler.
>>> I once met somebody, who wrote the front end of an Ada compiler, and
>>> he told me a different story. E.g.: He said that a special function
>>> needs to read ahead just to find out the semantic of a parenthesis.
>> 
>> There is no need to know the semantics of parenthesis in order to parse
>> them. Semantic analysis is anther compilation phase.
>> 
>> The only moderately difficult part of Ada that requires short look ahead
>> are digraphs like "and then" (overloaded with "and"). There can be comments
>> and new lines between "and" and "then" in the digraph. However it does not
>> require any roll backs.
> 
> IIRC "and then" is not that big an issue. The bigger issue is the two 
> uses of single quotes: they delimit character constants, and they are 
> used for qualified expressions. Consider an expression such as
> 
>       Foo'(',',',',',' ... )

The context where the apostrophe introduces a character literal is where an
expression operand is expected, i.e. *before* an operand. The context where
the apostrophe starts an attribute is always *after* an operand. If the
parser is aware of the context there is no any problem at all, because only
the infix operations switch the context and they are all fixed (+, -, *, /
etc). No look ahead is needed, not in my parser of Ada 95.

(Well, I forgot to mention another minor case of short look ahead. When
matching integer literals the base may precede the value: 10#10#. I am too
lazy to verify if _ is legal in the base specification, i.e. whether
1_0#10# is OK. If not then that might be also a negligible problem.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Wolfgang Ehrhardt]

On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm <thomas.mertes@gmx.at>
wrote:

>I once met somebody, who wrote the front end of an Ada compiler, and
>he told me a different story. E.g.: He said that a special function
>needs to read ahead just to find out the semantic of a parenthesis.
>In Pascal such read ahead is not necessary. 

Of course a read ahead is necessary in Pascal (at least in a one-pass
compiler), otherwise the following would give an error:

procedure test (*comment*) (x: integer);

-- 
In order to e-mail me a reply to this message, you will have 
to remove PLEASE.REMOVE from the address shown in the header
or get it from http://home.netsurf.de/wolfgang.ehrhardt
(Free open source Crypto, AES, CRC, Hash for Pascal/Delphi)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[bartc]

"Wolfgang Ehrhardt" <Wolfgang.Ehrhardt.PLEASE.REMOVE@munich.netsurf.de> 
wrote in message news:4a6a2335.7649091@news.individual.net...
> On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm <thomas.mertes@gmx.at>
> wrote:
>
>>I once met somebody, who wrote the front end of an Ada compiler, and
>>he told me a different story. E.g.: He said that a special function
>>needs to read ahead just to find out the semantic of a parenthesis.
>>In Pascal such read ahead is not necessary.
>
> Of course a read ahead is necessary in Pascal (at least in a one-pass
> compiler), otherwise the following would give an error:
>
> procedure test (*comment*) (x: integer);

I think Pascal doesn't need lookahead if it's dealing with symbols rather 
than characters. Even with characters only a single character lookahead is 
needed. Possibly Ada may need to read multiple symbols ahead.

The Pascal design is elegant but I've done parsers where potentially 
thousands of tokens need to be processed after a parenthesis before it knows 
exactly what it's dealing with. It's not a problem.

-- 
Bart 

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 25 Jul., 00:29, "bartc" <ba...@freeuk.com> wrote:
> "Wolfgang Ehrhardt" <Wolfgang.Ehrhardt.PLEASE.REM...@munich.netsurf.de>
> wrote in messagenews:4a6a2335.7649091@news.individual.net...
>
> > On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm <thomas.mer...@gmx.at>
> > wrote:
>
> >>I once met somebody, who wrote the front end of an Ada compiler, and
> >>he told me a different story. E.g.: He said that a special function
> >>needs to read ahead just to find out the semantic of a parenthesis.
> >>In Pascal such read ahead is not necessary.
>
> > Of course a read ahead is necessary in Pascal (at least in a one-pass
> > compiler), otherwise the following would give an error:
>
> > procedure test (*comment*) (x: integer);
>
> I think Pascal doesn't need lookahead if it's dealing with symbols rather
> than characters. Even with characters only a single character lookahead is
> needed.

Agree.

> Possibly Ada may need to read multiple symbols ahead.
>
> The Pascal design is elegant but I've done parsers where potentially
> thousands of tokens need to be processed after a parenthesis before it knows
> exactly what it's dealing with. It's not a problem.

The problem is not that it is not doable.
The problem is that human readers must also process
thousands of tokens to know exactly what is going on.
When one symbol tells you, what is going on, reading is easier.
Complicated parsing with lookahead is IMHO an indication
for hard to read constructs. I think that Wirth had such things
in his mind when he compared human and compiler parsing.

The rules that make the syntax of Seed7 easier to parse
are described here:

http://seed7.sourceforge.net/manual/syntax.htm

Note that the syntax and semantic (types, overloading, ...)
of Seed7 are handled by different parts of the compiler. It is
never necessary to look at semantic information (e.g.: The
type of an expression) to decide which syntax is allowed.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[bartc]

"tm" <thomas.mertes@gmx.at> wrote in message
news:ffe34647-ed6d-4349-beb1-3f613351439d@v36g2000yqv.googlegroups.com...
> On 25 Jul., 00:29, "bartc" <ba...@freeuk.com> wrote:
>> "Wolfgang Ehrhardt" <Wolfgang.Ehrhardt.PLEASE.REM...@munich.netsurf.de>
>> wrote in messagenews:4a6a2335.7649091@news.individual.net...
>>
>> > On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm <thomas.mer...@gmx.at>
>> > wrote:
>>
>> >>I once met somebody, who wrote the front end of an Ada compiler, and
>> >>he told me a different story. E.g.: He said that a special function
>> >>needs to read ahead just to find out the semantic of a parenthesis.
>> >>In Pascal such read ahead is not necessary.
>>
>> > Of course a read ahead is necessary in Pascal (at least in a one-pass
>> > compiler), otherwise the following would give an error:
>>
>> > procedure test (*comment*) (x: integer);
>>
>> I think Pascal doesn't need lookahead if it's dealing with symbols rather
>> than characters. Even with characters only a single character lookahead
>> is
>> needed.
>
> Agree.
>
>> Possibly Ada may need to read multiple symbols ahead.
>>
>> The Pascal design is elegant but I've done parsers where potentially
>> thousands of tokens need to be processed after a parenthesis before it
>> knows
>> exactly what it's dealing with. It's not a problem.
>
> The problem is not that it is not doable.
> The problem is that human readers must also process
> thousands of tokens to know exactly what is going on.

This really means it needs to look ahead a complete expression, which can be
of arbitrary complexity, especially if expressions can include statements as
my design did. Examples:

 (expr)              # ordinary parenthesised expression
 (expr | a | b)      # if-then-else select
 (expr | a,b,c | z)  # n-way select
 (expr, a,b,c)       # list

 a[expr]             # normal indexing
 a[expr..expr]       # slicing
 etc...

In practice expr will be short and only a few symbols (such as n+1). If the 
user wants to put almost a whole program in there, that's up to him. And he 
could probably do similar things in Pascal and Seed7.

> When one symbol tells you, what is going on, reading is easier.
> Complicated parsing with lookahead is IMHO an indication
> for hard to read constructs.

You can't argue the above construct's aren't easy on the eye. On the other
hand:

switch n
when x then a
when y then b
else c
end [i]:=k

is probably ill-advised. It's not until the end that you realise it's an
assignment to an array element (ie. assigning k to one of a[i], b[i] or
c[i]).

So it all depends. Parsing this stuff is trivial. Might as well make it
available, and trust the user to use it sensibly.

-- 
Bart

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

"bartc" <bartc@freeuk.com> writes:

> "tm" <thomas.mertes@gmx.at> wrote in message
> news:ffe34647-ed6d-4349-beb1-3f613351439d@v36g2000yqv.googlegroups.com...
>> On 25 Jul., 00:29, "bartc" <ba...@freeuk.com> wrote:
>>> The Pascal design is elegant but I've done parsers where potentially
>>> thousands of tokens need to be processed after a parenthesis before it
>>> knows
>>> exactly what it's dealing with. It's not a problem.
>>
>> The problem is not that it is not doable.
>> The problem is that human readers must also process
>> thousands of tokens to know exactly what is going on.
>
> This really means it needs to look ahead a complete expression, which can be
> of arbitrary complexity, especially if expressions can include statements as
> my design did. Examples:
>
> (expr)              # ordinary parenthesised expression
> (expr | a | b)      # if-then-else select
> (expr | a,b,c | z)  # n-way select
> (expr, a,b,c)       # list
>
> a[expr]             # normal indexing
> a[expr..expr]       # slicing
> etc...
>
> In practice expr will be short and only a few symbols (such as
> n+1). If the user wants to put almost a whole program in there, that's
> up to him. And he could probably do similar things in Pascal and
> Seed7.
>
>> When one symbol tells you, what is going on, reading is easier.
>> Complicated parsing with lookahead is IMHO an indication
>> for hard to read constructs.
>
> You can't argue the above construct's aren't easy on the eye. On the other
> hand:
>
> switch n
> when x then a
> when y then b
> else c
> end [i]:=k
>
> is probably ill-advised. It's not until the end that you realise it's an
> assignment to an array element (ie. assigning k to one of a[i], b[i] or
> c[i]).

It's ill-advised, but because of the ill-definition of that language.
There's no reason why such an expression couldn't be written and read
easily.  You just need to design your language with prefix operators
(Polish Notation) so you always know up-front what you're parsing:

(setf (aref (switch n
              (x    a)
              (y    b)
              (else c)) i) k)

Which is even simplier than what Wirth was about.


> (expr)              # ordinary parenthesised expression

expr              ; if you take care of always parenthesize
                  ; expressions,  you simplify the syntax
                  ; rules and don't need to further parenthesize
                  ;  expressions.

> (expr | a | b)      # if-then-else select

(if expr a b)


> (expr | a,b,c | z)  # n-way select

(select expr a b c z)


> (expr, a,b,c)       # list

(list expr a b c)


> a[expr]             # normal indexing

(aref a expr)


> a[expr..expr]       # slicing

(slice a expr1 expr2


> etc...

etc...


> So it all depends. Parsing this stuff is trivial. Might as well make it
> available, and trust the user to use it sensibly.

-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[bartc]

Pascal J. Bourguignon wrote:
> "bartc" <bartc@freeuk.com> writes:
>> "tm" <thomas.mertes@gmx.at> wrote in message
>> news:ffe34647-ed6d-4349-beb1-3f613351439d@v36g2000yqv.googlegroups.com...
>>> On 25 Jul., 00:29, "bartc" <ba...@freeuk.com> wrote:
>>>> The Pascal design is elegant but I've done parsers where
>>>> potentially thousands of tokens need to be processed after a
>>>> parenthesis before it knows
>>>> exactly what it's dealing with. It's not a problem.
>>>
>>> The problem is not that it is not doable.
>>> The problem is that human readers must also process
>>> thousands of tokens to know exactly what is going on.
>>
>> This really means it needs to look ahead a complete expression,
>> which can be of arbitrary complexity, especially if expressions can
>> include statements as my design did. Examples:
>>
>> (expr)              # ordinary parenthesised expression
>> (expr | a | b)      # if-then-else select
>> (expr | a,b,c | z)  # n-way select
>> (expr, a,b,c)       # list
>>
>> a[expr]             # normal indexing
>> a[expr..expr]       # slicing
>> etc...
>>
>> In practice expr will be short and only a few symbols (such as
>> n+1). If the user wants to put almost a whole program in there,
>> that's
>> up to him. And he could probably do similar things in Pascal and
>> Seed7.
>>
>>> When one symbol tells you, what is going on, reading is easier.
>>> Complicated parsing with lookahead is IMHO an indication
>>> for hard to read constructs.
>>
>> You can't argue the above construct's aren't easy on the eye. On the
>> other hand:
>>
>> switch n
>> when x then a
>> when y then b
>> else c
>> end [i]:=k
>>
>> is probably ill-advised. It's not until the end that you realise
>> it's an assignment to an array element (ie. assigning k to one of
>> a[i], b[i] or c[i]).
>
> It's ill-advised, but because of the ill-definition of that language.
> There's no reason why such an expression couldn't be written and read
> easily.  You just need to design your language with prefix operators
> (Polish Notation) so you always know up-front what you're parsing:
>
> (setf (aref (switch n
>              (x    a)
>              (y    b)
>              (else c)) i) k)
>
> Which is even simplier than what Wirth was about.

If you're going to use Lisp-like syntax then you always know what to expect, 
ie. (, ) or a term.

But ultra simple parsing presents it's own problems when trying to read it, 
because of it's monotony. Richer syntax can make constructions stand out 
more.
>
>> (expr)              # ordinary parenthesised expression
>
> expr              ; if you take care of always parenthesize
>                  ; expressions,  you simplify the syntax
>                  ; rules and don't need to further parenthesize
>                  ;  expressions.
>
>> (expr | a | b)      # if-then-else select
>
> (if expr a b)
>
>
>> (expr | a,b,c | z)  # n-way select
>
> (select expr a b c z)
>
>
>> (expr, a,b,c)       # list
>
> (list expr a b c)
>
>
>> a[expr]             # normal indexing
>
> (aref a expr)
>
>
>> a[expr..expr]       # slicing
>
> (slice a expr1 expr2

> etc...

Sure, you have to do some of the language's work for it by telling it what's 
coming up. Those forms look more like an intermediate language than original 
source code. It's a bit like looking at plain text representing markup 
instructions, then looking at the output.

Clearly many people are happy working directly with s-expressions, but 
others aren't.

-- 
Bart

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

tm schrieb:

> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
> 
>   What can be parsed easily by a compiler can also be
>   parsed easily by a human and this can be an asset.
> 
> He probably did not use exactly this words, but they hopefully
> describe his intentions.

A human who has parsed some part of a program is far away from having
understood the part of the program:  Many concepts expressed "easily"
in "simple" languages hide the fact that a complex combination
of simple things needs to be studied (and made "conventional"
or idiomatic) in order to arrive at an understanding of what
is really going on, and what is intended, due to the combination.
Sometimes these lengthy combinations of "simply" expressed things
are equivalent to a simple builtin of less "simple" languages.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ben Bacarisse]

tm <thomas.mertes@gmx.at> writes:

> On 20 Jul., 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>> Andrea Taverna a écrit :
>> [...]>     - Ada is best suited for large teams and/or critical software, thus
>> > it may be overkill for my work, OTH it could have anything I might
>> > happen to need.
>> > What holds me from jumping onto Ada is the potential complexity
>>
>> As a long time teacher of Ada, let me elaborate on this particular issue.
>>
>> 1) More than complex, Ada is feature-rich, with some properties that do
>> not exist in most other languages (user defined elementary types,
>> discriminants, stack-allocated dynamic structures ...). Of course,
>> you'll have to learn about these features - if you want to use them.
>>
>> 2) Ada is extremely consistent. You'll have to learn the basic
>> principles, but once you've got them, you'll discover that all the
>> features follow the same logic. Therefore, the first step might be
>> higher than for other languages, but then everything appears logical and
>> easy to grasp.
>>
>> 3) Ada is simple to use, because difficulty of implementation has never
>> been an excuse for forbidding something that the user would expect to
>> work. However, that makes the language complex to compile, and part of
>> the alledged complexity of Ada refers to complexity of implementation,
>
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
>
>   What can be parsed easily by a compiler can also be
>   parsed easily by a human and this can be an asset.

That is a fine notion.

> He probably did not use exactly this words, but they hopefully
> describe his intentions.
>
> Many languages try to make the job of writing a program easier
> and at the same time make the job of reading programs is
> harder. All this wonderful "do what I mean" concepts used by
> many languages fail in some cases.

Does Ada have any of these though?  I don't know the language well,
but I have never heard that accusation levelled at it (yes, I know you
are not doing so, but it was Ada that prompted your thoughts on this).

> IMHO complex compilation processes are an indication
> of hard-to-understand concepts or hard-to-read constructs.
> As such a complex compilation process only seemingly
> (and not really) makes programming easier.

I don't agree with that at all.  There must be a germ of truth in it
(a hard to implement notion must be somewhat harder to understand than
an easy to implement one) but presumably you are arguing for the
reverse: that keeping the implementation simple ultimately helps the
programmer.

I'd cite higher-order functions and rendezvous as counter examples.
There are easier to implement alternatives to both but neither is
hard to read not particularly hard to understand.  Even if we grant
that they are hard to understand, the benefit to programmers is
significant.  In my view, certainly worth the effort needed to
understand them.

-- 
Ben.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Tetrahedral Quartz]

tm wrote:
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
> 
>   What can be parsed easily by a compiler can also be
>   parsed easily by a human and this can be an asset.

The converse, however, is not necessarily true: that which cannot be 
parsed easily by a compiler sometimes still can be parsed easily by a human.

This will remain so until strong AI is developed.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[wwilson]

On Mon, 20 Jul 2009 05:57:53 -0400, Jean-Pierre Rosen <rosen@adalog.fr>  
wrote:

> Andrea Taverna a ï¿œcrit :
> [...]
>>     - Ada is best suited for large teams and/or critical software, thus
>> it may be overkill for my work, OTH it could have anything I might
>> happen to need.
>> What holds me from jumping onto Ada is the potential complexity
> As a long time teacher of Ada, let me elaborate on this particular issue.
>
> 1) More than complex, Ada is feature-rich, with some properties that do
> not exist in most other languages (user defined elementary types,
> discriminants, stack-allocated dynamic structures ...). Of course,
> you'll have to learn about these features - if you want to use them.
>
> 2) Ada is extremely consistent. You'll have to learn the basic
> principles, but once you've got them, you'll discover that all the
> features follow the same logic. Therefore, the first step might be
> higher than for other languages, but then everything appears logical and
> easy to grasp.
>
> 3) Ada is simple to use, because difficulty of implementation has never
> been an excuse for forbidding something that the user would expect to
> work. However, that makes the language complex to compile, and part of
> the alledged complexity of Ada refers to complexity of implementation,
> not complexity of use. Of course, as a user, you don't care about this,
> since you have compilers, even free ones, that implement the language
> correctly, and this is checked by passing the validation suite (AKA  
> ACATS).



I agree that Ada can look daunting, but you can start with the "Pascal  
subset", a subset that pretty much matches the original Pascal.  From  
personal experience, this subset is very easy to learn and become  
comfortable with.  We taught over a thousand studnts using this subset and  
never had a single real problem.

Once the beginner masters the Pascal subset it is fairly easy to learn  
additional features, one at a time.  The real problem we found here was  
that some students had never seen problems that needed or could use these  
features.  In other words, we were trying to teach three year olds how to  
parse a sentence when they were still learning to talk.  On the other  
hand, students who were familiar with the kinds of problems these features  
were designed for had no difficulty with even some of the more esocteric  
parts of Ada.  For students lacking this background we spent some time  
furnishing it before intoducing the associated Ada feature.  Many  
students, for instance, required some exposure to tasking kinds of  
problems before we mentioned Ada tasking.

Conclusion, approach learning Ada one step at a time and don't try to  
master the whole thing at once. It is an easy language to learn and the  
benefits are great.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

On 2009-07-18, A. Taverna <a.tavs.NOSPAM@libero.it.invalid>
submitted for the newsgroups comp.lang.eiffel; comp.lang.ada;
comp.lang.modula3; comp.lang.pascal; and comp.programming ...
|---------------------------------------------------------------------------|
|"Hi folks!                                                                 |
|                                                                           |
|I'm a CS student and I often need to write number-crunching code dealing   |
|with combinatorial optimization problems.                                  |
|What I do usually is implementing ad-hoc algorithms and testing their      |
|performance against other previously-known solutions, including general    |
|solvers.                                                                   |
|                                                                           |
|In the past I used C, but now I have decided to change language.           |
|I'm looking for a "better" one.                                            |
|                                                                           |
|Here follow the features it should have, ranked approximately by relevance:|
|                                                                           |
|0) open-source support and an alive community                              |
|1) directly compiled to efficient code                                     |
|2) statically typed and object-oriented, better if multi-paradigm          |
|3) general-purpose libraries (possibly standardized, either by standard    |
|or de facto), including containers and some math abstractions.             |
|4) garbage collected. As an alternative, provide memory management         |
|policies via libraries (e.g. memory pools and such)                        |
|5) optional run-time checks and some kind of control over compilation      |
|and low-level issues                                                       |
|6) "relatively simple and consistent"                                      |
|                                                                           |
|So I have considered these alternatives: FreePascal, Eiffel, Ada and       |
|Modula-3.                                                                  |
|I have taken a look at all of them and I'm still undecided. Below are      |
|the impressions I got for each language.                                   |
|Can you help me? Feel free to recommend other languages as well.           |
|                                                                           |
|TIA                                                                        |
|                                                                           |
|--> Impressions I got for each language                                    |
|                                                                           |
|- FreePascal is a safe and modular alternative to C and C++,  but          |
|it is also close to the latter in terms of expressiveness. Moreover it     |
|doesn't seem to have the libraries I need.                                 |
|==>Qualifies for 0,1,2,5. Not sure about 3 and 4                           |
|                                                                           |
|- Eiffel is geared toward application programming in                       |
|medium/large-sized teams relying heavily on OO modelling. It is designed   |
|for (re)usability, correctness and efficiency in this order.               |
|My needs are somewhat different though.                                    |
|The main gripe I have with Eiffel is the lack of a well-documented         |
|standard gpl'ed library.                                                   |
|GOBO and EiffelBase seem to have incomplete or non-free documentation      |
|and I couldn't find tutorials; as such, I couldn't get a clear picture     |
|about them.                                                                |
|==> Qualifies for 0,1,2,4,5 and 6.  Not sure about 3.                      |
|                                                                           |
|- Ada is best suited for large teams and/or critical software, thus        |
|it may be overkill for my work, OTH it could have anything I might         |
|happen to need.                                                            |
|What holds me from jumping onto Ada is the potential complexity            |
|It would be interesting  to hear the experience of other people learning   |
|Ada from the C/Java background.                                            |
|As for memory management (requirement 4), I heard there are different      |
|takes on the matter:                                                       |
|(a) Ada uses dynamic stack allocation a lot, and in a transparent way,     |
|reducing the need of manual management (MM)                                |
|(b) Ada libraries adopt idioms that further simplifies MM issues           |
|(c) Conservative garbage collectors such as Bohem's can be used with       |
|Ada, and they are supposed to work "better" with Ada than with unsafe      |
|languages such as C and C++                                                |
|                                                                           |
|So can MM be said to be easier in Ada than in C? I hope Ada-ers will       |
|mercifully shed some light on the issue.                                   |
|                                                                           |
|There seems to be a lot of Ada95 free documentation on the net, I guess    |
|it's suitable for Ada05 as well.                                           |
|==> Qualifies for 0,1,2,3,5 and, partially, 4                              |
|                                                                           |
|- Modula-3 is simpler/smaller than Ada and has been successfully           |
|used for system/application programming.                                   |
|It seems to be the most consistent, simple and easy to grok, but I         |
|couldn't find any container/math library ready to use.                     |
|==> Qualifies for 0,1,2,4,5,6."                                            |
|---------------------------------------------------------------------------|

Ciao!

I agree that static typing is important, but Modula-3; Eiffel; and
many versions of Pascal perhaps including FreePascal are restricted to
structural equivalence of types only. This is not sufficient strong
typing.

I give an example showing that Ada is better than Eiffel (and Modula-3
and many versions of Pascal) in this regard, based on an example by
Bertrand Meyer in the second edition of the book "Object-oriented
software construction". In that book, Dr. Meyer claimed that Ada's
overloading is inferior to Eiffel's overloading. He called Ada's
overloading syntactic overloading. He called Eiffel's overloading
semantic overloading. I believe that he was being sincere, but he was
definitely mistaken. He claimed that it would not be possible to
sensibly discriminate between overloaded subprograms for a point if
the real-number parameters could be in any of Cartesian notation and
polar notation.

This is refuted by the following Ada code...

procedure Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is
   type Horizontal_Coordinate is new Float;
   type Vertical_Coordinate is new Float;
   procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
   begin
      null; --Whatever.
   end;

   type Magnitude is new Float;
   type Radians is new Float range -3.14*2.0 .. 3.14*2.0;
   procedure Point(R : Magnitude; Theta : Radians) is
   begin
      null; --Whatever.
   end;

   X : Horizontal_Coordinate;
   Y : Vertical_Coordinate;
   R : Magnitude;
   Theta : Radians;
begin
   X := 1.1;
   Y := 2.2;
   R := 3.3;
   Theta := 0.5;
   Point(X, Y);
   Point(R, Theta);
   
   --The above is all legal Ada. However, the following mistakes would
   --be legal in Eiffel but would be rejected by an Ada compiler...
   
   R := X;
   --An example compiler complaint...
   --"Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:29:09: expected type "Magnitude" defined at line 9
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:29:09: found type "Horizontal_Coordinate" defined at line 2
   --gnatmake: "Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb" compilation error".

   Point(X, Theta);
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:04: no candidate interpretations match the actuals:
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:10: expected type "Magnitude" defined at line 9
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:10: found type "Horizontal_Coordinate" defined at line 2
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:10:   ==> in call to "Point" at line 11
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:13: expected type "Vertical_Coordinate" defined at line 3
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:13: found type "Radians" defined at line 10
   --Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb:35:13:   ==> in call to "Point" at line 4
   --gnatmake: "Syntactic_overloading_example_based_on_an_example_by_Bertrand_Meyer.adb" compilation error
end;

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mark T.B. Carroll]

Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:

> I agree that static typing is important, but Modula-3; Eiffel; and
> many versions of Pascal perhaps including FreePascal are restricted to
> structural equivalence of types only. This is not sufficient strong
> typing.

Modula-3's BRANDED keyword overrides the structural equivalence.

[ followups trimmed ]

Mark

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

On 2009-07-20, Mark T.B. Carroll <Mark.Carroll@Aetion.com> wrote:

|------------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:   |
|                                                                        |
|> I agree that static typing is important, but Modula-3; Eiffel; and    |
|> many versions of Pascal perhaps including FreePascal are restricted to|
|> structural equivalence of types only. This is not sufficient strong   |
|> typing.                                                               |
|                                                                        |
|Modula-3's BRANDED keyword overrides the structural equivalence."       |
|------------------------------------------------------------------------|

Thank you for the response.

The author of
HTTP://web.archive.org/web/20051001044031/http://archive.dstc.edu.au/AU/staff/crawley/ada/m3-vs-ada.html#section4.1
warned that he did not know Modula-3 well, so was his claim
"Branding only applies to reference types"
untrue?

Could you show us a Modula-3 version of the code in
news:h41n4c$pm0$1@news.eternal-september.org
which is better than Eiffel and at least as good as Ada?

Thanks again,
N. P. C.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mark T.B. Carroll]

Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:

> On 2009-07-20, Mark T.B. Carroll <Mark.Carroll@Aetion.com> wrote:
>
> |------------------------------------------------------------------------|
> |"Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:   |
> |                                                                        |
> |> I agree that static typing is important, but Modula-3; Eiffel; and    |
> |> many versions of Pascal perhaps including FreePascal are restricted to|
> |> structural equivalence of types only. This is not sufficient strong   |
> |> typing.                                                               |
> |                                                                        |
> |Modula-3's BRANDED keyword overrides the structural equivalence."       |
> |------------------------------------------------------------------------|
>
> Thank you for the response.
>
> The author of
> HTTP://web.archive.org/web/20051001044031/http://archive.dstc.edu.au/AU/staff/crawley/ada/m3-vs-ada.html#section4.1
> warned that he did not know Modula-3 well, so was his claim
> "Branding only applies to reference types"
> untrue?

I think that's true. However, that is not equivalent to Modula-3 being
"restricted to structural equivalence of types only", which is why I
corrected you. (Note that you can have reference types of even integers
or whatever, it's not just objects.)

> Could you show us a Modula-3 version of the code in
> news:h41n4c$pm0$1@news.eternal-september.org
> which is better than Eiffel and at least as good as Ada?

I don't know Eiffel at all and barely remember Ada, so probably not I'm
afraid.

Mark

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ANSI_X3.4-1968, Size: 3800 bytes --]

On 2009-07-20, Mark T.B. Carroll <Mark.Carroll@Aetion.com> wrote:

|---------------------------------------------------------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:                                                |
|                                                                                                                     |
|> On 2009-07-20, Mark T.B. Carroll <Mark.Carroll@Aetion.com> wrote:                                                  |
|>                                                                                                                    |
|> |------------------------------------------------------------------------|                                         |
|> |"Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:   |                                         |
|> |                                                                        |                                         |
|> |> I agree that static typing is important, but Modula-3; Eiffel; and    |                                         |
|> |> many versions of Pascal perhaps including FreePascal are restricted to|                                         |
|> |> structural equivalence of types only. This is not sufficient strong   |                                         |
|> |> typing.                                                               |                                         |
|> |                                                                        |                                         |
|> |Modula-3's BRANDED keyword overrides the structural equivalence."       |                                         |
|> |------------------------------------------------------------------------|                                         |
|>                                                                                                                    |
|> Thank you for the response.                                                                                        |
|>                                                                                                                    |
|> The author of                                                                                                      |
|> HTTP://web.archive.org/web/20051001044031/http://archive.dstc.edu.au/AU/staff/crawley/ada/m3-vs-ada.html#section4.1|
|> warned that he did not know Modula-3 well, so was his claim                                                        |
|> "Branding only applies to reference types"                                                                         |
|> untrue?                                                                                                            |
|                                                                                                                     |
|I think that's true. However, that is not equivalent to Modula-3 being                                               |
|"restricted to structural equivalence of types only", which is why I                                                 |
|corrected you. (Note that you can have reference types of even integers                                              |
|or whatever, it's not just objects.)                                                                                 |
|                                                                                                                     |
|[..]"                                                                                                                |
|---------------------------------------------------------------------------------------------------------------------|

Touch�.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Nicholas Paul Collin Gloucester escreveu:
[snipped]

> 
> I give an example showing that Ada is better than Eiffel (and Modula-3
> and many versions of Pascal) in this regard, based on an example by
> Bertrand Meyer in the second edition of the book "Object-oriented
> software construction". In that book, Dr. Meyer claimed that Ada's
> overloading is inferior to Eiffel's overloading. He called Ada's
> overloading syntactic overloading. He called Eiffel's overloading
> semantic overloading. I believe that he was being sincere, but he was
> definitely mistaken. He claimed that it would not be possible to
> sensibly discriminate between overloaded subprograms for a point if
> the real-number parameters could be in any of Cartesian notation and
> polar notation.
> 
> This is refuted by the following Ada code...
> 
Not it's not, your code only changed the problem appearance but not
substance:

> procedure Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is
>    type Horizontal_Coordinate is new Float;
>    type Vertical_Coordinate is new Float;
>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>    begin
>       null; --Whatever.
>    end;

Here you create two "subtypes" which are only nicknames for Float in
order to help the Ada compiler to discriminate the signature. BTW, why
the need of two subtypes for coordinates?

> 
>    type Magnitude is new Float;
>    type Radians is new Float range -3.14*2.0 .. 3.14*2.0;
>    procedure Point(R : Magnitude; Theta : Radians) is

Ditto with two more "subtypes", and for no reason creating a new mess as
you made a design decision that Radians can only go from -6.28 to +6.28,
so you leave to the poor programmers that shall use this code the task
of normalizing the angles before creating points else runtime exceptions?


>    begin
>       null; --Whatever.
>    end;
> 
>    X : Horizontal_Coordinate;
>    Y : Vertical_Coordinate;
>    R : Magnitude;
>    Theta : Radians;
> begin
>    X := 1.1;
>    Y := 2.2;
>    R := 3.3;
>    Theta := 0.5;
>    Point(X, Y);
>    Point(R, Theta);
>    
>    --The above is all legal Ada. However, the following mistakes would
>    --be legal in Eiffel but would be rejected by an Ada compiler...
>    
>    R := X;

Careful reading of this line of code shows the 'protection' against
mistakes occurs only after the 'subtype' has been initialized, but this:

     X := 3.3;  -- for the sake of argument programmer
     Y := 0.5;  -- wrote the GUI code backwards
     R := 1.1;
     Theta := 2.2;
     Point(X, Y);
     Point(R, Theta);

Happy compiler and code runs, albeit with unexpected results...

--
Cesar Rabak

PS.: for some reason could not set the Followup-To so I trimmed to the
pertaining language NGs.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Here you create two "subtypes" which are only nicknames for Float in
> order to help the Ada compiler to discriminate the signature. BTW, why
> the need of two subtypes for coordinates?
Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
both are differents.

A type does not only designate a range of allowed values, it also
designate a source, which in turn, associate design property to it
(this can be asserted relying on type matching rules).

If you want to be sure what a function recieve only come from a
defined set of functions, then you define a type, some functions
returning value of this types, or procedure modifying this type. Two
types may seem similar at a quick sight, but types are not only used
to define ranges.

Types allow to define the valid flow of some objects or values, it
allows to make assertions about where it come from and where it can go
(thus, what was done with on/with it). This as to deal with the
overall design, the whole usage of a library, and not only with the
set of value allowed for a given type.

This is not a kind of nickname, this is a difference written in the
stone

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Hibou57 (Yannick Duch�ne) escreveu:
> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>> Here you create two "subtypes" which are only nicknames for Float in
>> order to help the Ada compiler to discriminate the signature. BTW, why
>> the need of two subtypes for coordinates?
> Not � subtype � but � type �, which is not the same. Ada has both, and
> both are differents.

They are *considered* different in Ada technology, I respect that, but 
from a OO point of view, they are not: a new type would define a new set 
of operations on it.

> 
> A type does not only designate a range of allowed values, it also
> designate a source, which in turn, associate design property to it
> (this can be asserted relying on type matching rules).

In Ada language, defined as such.

> 
> If you want to be sure what a function recieve only come from a
> defined set of functions, then you define a type, some functions
> returning value of this types, or procedure modifying this type. Two
> types may seem similar at a quick sight, but types are not only used
> to define ranges.

Which is syntatic sugar for allowing signatures and allowing for 
internal consistency in the program *after* the variables have been 
initialized from a primitive type.

> 
> Types allow to define the valid flow of some objects or values, it
> allows to make assertions about where it come from and where it can go
> (thus, what was done with on/with it). This as to deal with the
> overall design, the whole usage of a library, and not only with the
> set of value allowed for a given type.

After have been initialized by primitive types (as your own example shows).

> 
> This is not a kind of nickname, this is a difference written in the
> stone

 From a practical matter it is only a nickname, see my example you snipped.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Cesar Rabak wrote:
> Hibou57 (Yannick Duch�ne) escreveu:
>> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>>> Here you create two "subtypes" which are only nicknames for Float in
>>> order to help the Ada compiler to discriminate the signature. BTW, why
>>> the need of two subtypes for coordinates?
>> Not � subtype � but � type �, which is not the same. Ada has both, and
>> both are differents.
> 
> They are *considered* different in Ada technology, I respect that, but
> from a OO point of view, they are not: a new type would define a new set
> of operations on it.

Could, I'd say. A derived type could (1) define a new set of
operations, or it could (2) just create a different kind of
fruit exhibiting the same behavior (operation-wise),
or (2a) override an operation,
or it could (3) defer (Eiffel) or abstract (Ada) some operations.
Except, perhaps, that Eiffel's elementary types are frozen,
that is, cannot be subclassed at all (last time I checked).

If Ada had an explicit unit system in addition to it's
type properties (the 'First and so on), then I could imagine
a case for requiring (2) to become (2a). Define a new (an own)
floting point type derived from some other floating point
type and make explicit where you expect them to be different,
for example in their units.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Mon, 20 Jul 2009 16:35:26 -0300, Cesar Rabak wrote:

> Hibou57 (Yannick Duchêne) escreveu:
>> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>>> Here you create two "subtypes" which are only nicknames for Float in
>>> order to help the Ada compiler to discriminate the signature. BTW, why
>>> the need of two subtypes for coordinates?
>> Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
>> both are differents.
> 
> They are *considered* different in Ada technology, I respect that, but 
> from a OO point of view, they are not: a new type would define a new set 
> of operations on it.

It defines a new set of values, which automatically makes the operations
different even if they are numerically equivalent or their low-level
implementations are shared.

You know, two bottles of beer are numerically equivalent to two worn socks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Dmitry A. Kazakov escreveu:
> On Mon, 20 Jul 2009 16:35:26 -0300, Cesar Rabak wrote:
> 
>> Hibou57 (Yannick Duchêne) escreveu:
>>> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>>>> Here you create two "subtypes" which are only nicknames for Float in
>>>> order to help the Ada compiler to discriminate the signature. BTW, why
>>>> the need of two subtypes for coordinates?
>>> Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
>>> both are differents.
>> They are *considered* different in Ada technology, I respect that, but 
>> from a OO point of view, they are not: a new type would define a new set 
>> of operations on it.
> 
> It defines a new set of values, which automatically makes the operations
> different even if they are numerically equivalent or their low-level
> implementations are shared.

It defines a syntactic difference and as shown until now all the 
operations remain equal, even when the OO technique would suggest not: 
for example the new 'type' proposed for the angle measurement could make 
the wrapping automatically when operations made the results greater than 
2*pi.

> 
> You know, two bottles of beer are numerically equivalent to two worn socks.
> 

This is cardinality not equivalence, non sequitur for this discussion.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 3:30 pm, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Dmitry A. Kazakov escreveu:
>
>
>
> > On Mon, 20 Jul 2009 16:35:26 -0300, Cesar Rabak wrote:
>
> >> Hibou57 (Yannick Duchêne) escreveu:
> >>> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
> >>>> Here you create two "subtypes" which are only nicknames for Float in
> >>>> order to help the Ada compiler to discriminate the signature. BTW, why
> >>>> the need of two subtypes for coordinates?
> >>> Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
> >>> both are differents.
> >> They are *considered* different in Ada technology, I respect that, but
> >> from a OO point of view, they are not: a new type would define a new set
> >> of operations on it.
>
> > It defines a new set of values, which automatically makes the operations
> > different even if they are numerically equivalent or their low-level
> > implementations are shared.
>
> It defines a syntactic difference and as shown until now all the
> operations remain equal, even when the OO technique would suggest not:
> for example the new 'type' proposed for the angle measurement could make
> the wrapping automatically when operations made the results greater than
> 2*pi.

The user is free to define (override) the arithmetic operations to do
that.

As can happen with brief code snippets, one can erroneously infer that
language 'X' can not do something because a very small example does
not show that it can do it!

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Cesar Rabak schrieb:

>> procedure
>> Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is
>>    type Horizontal_Coordinate is new Float;
>>    type Vertical_Coordinate is new Float;
>>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>>    begin
>>       null; --Whatever.
>>    end;
> 
> Here you create two "subtypes" which are only nicknames for Float in
> order to help the Ada compiler to discriminate the signature. BTW, why
> the need of two subtypes for coordinates?

Horizontal_Coordinate and Vertical_Coordinate are specifically
*not* nicknames, not even informally.
Two new types derived from the same ancestor are definitely
*not* only nicknames for Float.  I see you are trying to
come up with an argument about the same literals  providing
values for objects of entirely different types, and that's
certainly formally true and a nice try.  But if you defer to
the programmers, I will, too, and suggest

   X := Vertical_Coordinate'(1.1);

so as to say what they mean.  Et voila,

     21.    X := Vertical_Coordinate'(1.1);
                                   |
        >>> expected type "Horizontal_Coordinate" defined at line 2
        >>> found type "Vertical_Coordinate" defined at line 3


I'm sure Gloucester will speak for himself, but it's tempting
to step in.

(Nitpick: he is introducing two new distinct types,
not subtypes as an Ada subtype is a type with a constraint
as in subset of values that are in the type).

Every one of the tricks you play below in your example
assigns values of literals of anonymous predefined type
'universal_real' to objects of distinct types.  There
is certainly an issue with literals not being silver
bullets.   Yes, some programmers do not define typed
constants of important values. Yes, they are not even
using C's untyped #define, they just sprinkle literals.


> Careful reading of this line of code shows the 'protection' against
> mistakes occurs only after the 'subtype' has been initialized, but this:
> 
>     X := 3.3;  -- for the sake of argument programmer
>     Y := 0.5;  -- wrote the GUI code backwards
>     R := 1.1;
>     Theta := 2.2;
>     Point(X, Y);
>     Point(R, Theta);
> 
> Happy compiler and code runs, albeit with unexpected results...

Well, there is no way to write full application programs in
type systems(*).  But what's your point?  If we add rigor to your
argument then we might just as well have but one type and make
the compilers even happier with that universal type...


(*) except Qi's, I should think.

--
Georg Bauhaus

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Georg Bauhaus escreveu:
> Cesar Rabak schrieb:
> 
>>> procedure
>>> Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is
>>>    type Horizontal_Coordinate is new Float;
>>>    type Vertical_Coordinate is new Float;
>>>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>>>    begin
>>>       null; --Whatever.
>>>    end;
>> Here you create two "subtypes" which are only nicknames for Float in
>> order to help the Ada compiler to discriminate the signature. BTW, why
>> the need of two subtypes for coordinates?
> 
> Horizontal_Coordinate and Vertical_Coordinate are specifically
> *not* nicknames, not even informally.
> Two new types derived from the same ancestor are definitely
> *not* only nicknames for Float.  I see you are trying to
> come up with an argument about the same literals  providing
> values for objects of entirely different types, and that's
> certainly formally true and a nice try. 

Yes, formally it is my gripe. Remember this is not a thread is running 
in Ada NG only, so recursing to Ada _terminology_ does not add to 
discourse here.

> But if you defer to
> the programmers, I will, too, and suggest
> 
>    X := Vertical_Coordinate'(1.1);
> 
> so as to say what they mean.  Et voila,
> 
>      21.    X := Vertical_Coordinate'(1.1);
>                                    |
>         >>> expected type "Horizontal_Coordinate" defined at line 2
>         >>> found type "Vertical_Coordinate" defined at line 3

Still, a pretense feeling of safety as the programmer had to work very 
hard to allow the compiler find the 'error'.

> 
> 
> I'm sure Gloucester will speak for himself, but it's tempting
> to step in.
> 
> (Nitpick: he is introducing two new distinct types,
> not subtypes as an Ada subtype is a type with a constraint
> as in subset of values that are in the type).

I comment this on other post.

> 
> Every one of the tricks you play below in your example
> assigns values of literals of anonymous predefined type
> 'universal_real' to objects of distinct types.  There
> is certainly an issue with literals not being silver
> bullets.   Yes, some programmers do not define typed
> constants of important values. Yes, they are not even
> using C's untyped #define, they just sprinkle literals.

I'm not playing tricks, just showing something may appear unnoticed if 
not debated.  Although the example has been on literals, I've noticed 
the bulk of problems happen when data is read from the outside of the 
program (file reading, GUI fields, etc.).

> 
> 
>> Careful reading of this line of code shows the 'protection' against
>> mistakes occurs only after the 'subtype' has been initialized, but this:
>>
>>     X := 3.3;  -- for the sake of argument programmer
>>     Y := 0.5;  -- wrote the GUI code backwards
>>     R := 1.1;
>>     Theta := 2.2;
>>     Point(X, Y);
>>     Point(R, Theta);
>>
>> Happy compiler and code runs, albeit with unexpected results...
> 
> Well, there is no way to write full application programs in
> type systems(*).  But what's your point?  If we add rigor to your
> argument then we might just as well have but one type and make
> the compilers even happier with that universal type...
> 
> 
> (*) except Qi's, I should think.

I avoided mentioning because this would open even more the discussion, 
but the OP could do its own research.

Yes your assertion goes in the Lisp direction, which for numerics could 
even be more interesting as numbers are stored in a more accurate way 
(if you avoid 'premature optimization' syndrome ;-)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Mon, 20 Jul 2009, Georg Bauhaus wrote:

|-------------------------------------------------------------|
|"[..]                                                        |
|                                                             |
|I'm sure Gloucester will speak for himself, but it's tempting|
|to step in.                                                  |
|                                                             |
|[..]"                                                        |
|-------------------------------------------------------------|

You are welcome to participate. Note that though I did respond that
time, often I do not have enough time to interact as much as I would
like with newsgroups and email lists, even if something merits or
needs a response.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Nicholas Paul Collin Gloucester]

On 2009-07-20, Cesar Rabak <csrabak@yahoo.com.br> wrote:

|----------------------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester escreveu:                                        |
|[snipped]                                                                         |
|                                                                                  |
|>                                                                                 |
|> I give an example showing that Ada is better than Eiffel (and Modula-3          |
|> and many versions of Pascal) in this regard, based on an example by             |
|> Bertrand Meyer in the second edition of the book "Object-oriented               |
|> software construction". In that book, Dr. Meyer claimed that Ada's              |
|> overloading is inferior to Eiffel's overloading. He called Ada's                |
|> overloading syntactic overloading. He called Eiffel's overloading               |
|> semantic overloading. I believe that he was being sincere, but he was           |
|> definitely mistaken. He claimed that it would not be possible to                |
|> sensibly discriminate between overloaded subprograms for a point if             |
|> the real-number parameters could be in any of Cartesian notation and            |
|> polar notation.                                                                 |
|>                                                                                 |
|> This is refuted by the following Ada code...                                    |
|>                                                                                 |
|Not it's not, your code only changed the problem appearance but not               |
|substance:                                                                        |
|                                                                                  |
|> procedure Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is|
|>    type Horizontal_Coordinate is new Float;                                     |
|>    type Vertical_Coordinate is new Float;                                       |
|>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is       |
|>    begin                                                                        |
|>       null; --Whatever.                                                         |
|>    end;                                                                         |
|                                                                                  |
|Here you create two "subtypes" which are only nicknames for Float in              |
|order to help the Ada compiler to discriminate the signature.""                   |
|----------------------------------------------------------------------------------|

As an Ada compiler would detect the difference and Bertrand Meyer was
unable to realize that the difference can be detected like this and
used that as his justification for his version of overloading, I
believe I have disproved the rationale of Dr. Meyer's.


|----------------------------------------------------------------------------------|
|" BTW, why                                                                        |
|the need of two subtypes for coordinates?"                                        |
|----------------------------------------------------------------------------------|

They might not be necessary, but they do no harm.

|----------------------------------------------------------------------------------|
|">                                                                                |
|>    type Magnitude is new Float;                                                 |
|>    type Radians is new Float range -3.14*2.0 .. 3.14*2.0;                       |
|>    procedure Point(R : Magnitude; Theta : Radians) is                           |
|                                                                                  |
|Ditto with two more "subtypes", and for no reason"                                |
|----------------------------------------------------------------------------------|

In this case there is a reason for having more types. An angle and a
length are simply not interchangable, so they should not be
represented both by Float. The amount of money equal to U.S.$1.00 is
not equal to the amount of money equal to 1.00 Canadian dollar, but
they are both written with the number 1.00.

|----------------------------------------------------------------------------------|
|"creating a new mess as                                                           |
|you made a design decision that Radians can only go from -6.28 to +6.28,          |
|so you leave to the poor programmers that shall use this code the task            |
|of normalizing the angles before creating points else runtime exceptions?"        |
|----------------------------------------------------------------------------------|

If you really want to be able to write values such as 390 degrees; 750
degrees; 1470 degrees; 1830 degrees; and 2190 degrees as was done in
Section 3.2 Case Study 3: Errors in the Direct Evaluation of the Sine
Series of the book William S. Dorn and Daniel D. McCracken, "Numerical
Methods with Fortran IV Case Studies", then you can do so without
normalization. Of course, to do so I would suggest a Degree type, and
yes, I would probably had written
type Degree is new Float range 0.0 .. 360.0;
or
type Degree is new Float range -180.0 .. 180.0;
instead of
type Degree is new Float;
as I would not had realized that this would distract you from the
emphasis that the Magnitude and angular types are very different, even
though they are both based on floating point types.

Even if we wanted to allow radians outside of the range I prescribed,
the restriction -6.28 to +6.28 might still be used internally with
normalization performed in a wrapper. Do you realize that when you
write a number with ASCII numerals, it is probably going to be
represented with something other than ASCII numerals before long?

With the type Radians as I had typed it,
Theta := 7.0;
would not result in a runtime exception. It would be rejected by a
compiler.

|----------------------------------------------------------------------------------|
|">   begin                                                                        |
|>       null; --Whatever.                                                         |
|>    end;                                                                         |
|>                                                                                 |
|>    X : Horizontal_Coordinate;                                                   |
|>    Y : Vertical_Coordinate;                                                     |
|>    R : Magnitude;                                                               |
|>    Theta : Radians;                                                             |
|> begin                                                                           |
|>    X := 1.1;                                                                    |
|>    Y := 2.2;                                                                    |
|>    R := 3.3;                                                                    |
|>    Theta := 0.5;                                                                |
|>    Point(X, Y);                                                                 |
|>    Point(R, Theta);                                                             |
|>                                                                                 |
|>    --The above is all legal Ada. However, the following mistakes would          |
|>    --be legal in Eiffel but would be rejected by an Ada compiler...             |
|>                                                                                 |
|>    R := X;                                                                      |
|                                                                                  |
|Careful reading of this line of code shows the 'protection' against               |
|mistakes occurs only after the 'subtype' has been initialized,"                   |
|----------------------------------------------------------------------------------|

What?

|----------------------------------------------------------------------------------|
|" but this:                                                                       |
|                                                                                  |
|X := 3.3;  -- for the sake of argument programmer                                 |
|Y := 0.5;  -- wrote the GUI code backwards                                        |
|R := 1.1;                                                                         |
|Theta := 2.2;                                                                     |
|Point(X, Y);                                                                      |
|Point(R, Theta);                                                                  |
|                                                                                  |
|Happy compiler and code runs, albeit with unexpected results..."                  |
|----------------------------------------------------------------------------------|

Nothing is foolproof, but I did prevent some accidents.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Nicholas Paul Collin Gloucester escreveu:
> On 2009-07-20, Cesar Rabak <csrabak@yahoo.com.br> wrote:
[snipped]
> |>                                                                                 |
> |> This is refuted by the following Ada code...                                    |
> |>                                                                                 |
> |Not it's not, your code only changed the problem appearance but not               |
> |substance:                                                                        |
> |                                                                                  |
> |> procedure Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is|
> |>    type Horizontal_Coordinate is new Float;                                     |
> |>    type Vertical_Coordinate is new Float;                                       |
> |>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is       |
> |>    begin                                                                        |
> |>       null; --Whatever.                                                         |
> |>    end;                                                                         |
> |                                                                                  |
> |Here you create two "subtypes" which are only nicknames for Float in              |
> |order to help the Ada compiler to discriminate the signature.""                   |
> |----------------------------------------------------------------------------------|
> 
> As an Ada compiler would detect the difference and Bertrand Meyer was
> unable to realize that the difference can be detected like this and
> used that as his justification for his version of overloading, I
> believe I have disproved the rationale of Dr. Meyer's.
> 
> 
> |----------------------------------------------------------------------------------|
> |" BTW, why                                                                        |
> |the need of two subtypes for coordinates?"                                        |
> |----------------------------------------------------------------------------------|
> 
> They might not be necessary, but they do no harm.
> 
> |----------------------------------------------------------------------------------|
> |">                                                                                |
> |>    type Magnitude is new Float;                                                 |
> |>    type Radians is new Float range -3.14*2.0 .. 3.14*2.0;                       |
> |>    procedure Point(R : Magnitude; Theta : Radians) is                           |
> |                                                                                  |
> |Ditto with two more "subtypes", and for no reason"                                |
> |----------------------------------------------------------------------------------|
> 
> In this case there is a reason for having more types. An angle and a
> length are simply not interchangable, so they should not be
> represented both by Float. The amount of money equal to U.S.$1.00 is
> not equal to the amount of money equal to 1.00 Canadian dollar, but
> they are both written with the number 1.00.
> 

I disagree strongly: an angle in radians is a real number as any other 
there is not any intrinsic difference in its *type* on ordinary 
Mathematics.  Dimensionally they are 'pure numbers' with no unit 
atached, your example on monetary units being fallacious, so non sequitur.


> |----------------------------------------------------------------------------------|
> |"creating a new mess as                                                           |
> |you made a design decision that Radians can only go from -6.28 to +6.28,          |
> |so you leave to the poor programmers that shall use this code the task            |
> |of normalizing the angles before creating points else runtime exceptions?"        |
> |----------------------------------------------------------------------------------|
> 
> If you really want to be able to write values such as 390 degrees; 750
> degrees; 1470 degrees; 1830 degrees; and 2190 degrees as was done in
> Section 3.2 Case Study 3: Errors in the Direct Evaluation of the Sine
> Series of the book William S. Dorn and Daniel D. McCracken, "Numerical
> Methods with Fortran IV Case Studies", then you can do so without
> normalization. 

I was not thinking on this, only on the 'ergonomy' of the solution, 
which I maintain happens due the desire to create 'type' (in Ada 
parlance [but in fact a nickname for Float]) so to allow the compiler to 
make critics in values *after have been initialized* with a primitive type.

My thinking was why one should restrict prematurely a range while it 
still make sense mathematically (1000 radians is a number that can come 
from some rotational routine or from an external data set, for example).

> Of course, to do so I would suggest a Degree type, and
> yes, I would probably had written
> type Degree is new Float range 0.0 .. 360.0;
> or
> type Degree is new Float range -180.0 .. 180.0;
> instead of
> type Degree is new Float;
> as I would not had realized that this would distract you from the
> emphasis that the Magnitude and angular types are very different, even
> though they are both based on floating point types.

They are not different at all both are real numbers, just that. Their 
*interpretation* in the program after they have been used in the Point 
object is different.

> 
> Even if we wanted to allow radians outside of the range I prescribed,
> the restriction -6.28 to +6.28 might still be used internally with
> normalization performed in a wrapper. Do you realize that when you
> write a number with ASCII numerals, it is probably going to be
> represented with something other than ASCII numerals before long?

Yes for your question, and of course I understand we are not discussing 
the design of the whole class/object, as we'd need to agree if magnitude 
can or not be negative, etc.

As for normalization, IMNHO it has to be done in the constructor of the 
class/object, and not as an (external) wrapper.

> 
> With the type Radians as I had typed it,
> Theta := 7.0;
> would not result in a runtime exception. It would be rejected by a
> compiler.

Because we are dealing with examples with literals, let the value come 
from an input...

> 
> |----------------------------------------------------------------------------------|
> |">   begin                                                                        |
> |>       null; --Whatever.                                                         |
> |>    end;                                                                         |
> |>                                                                                 |
> |>    X : Horizontal_Coordinate;                                                   |
> |>    Y : Vertical_Coordinate;                                                     |
> |>    R : Magnitude;                                                               |
> |>    Theta : Radians;                                                             |
> |> begin                                                                           |
> |>    X := 1.1;                                                                    |
> |>    Y := 2.2;                                                                    |
> |>    R := 3.3;                                                                    |
> |>    Theta := 0.5;                                                                |
> |>    Point(X, Y);                                                                 |
> |>    Point(R, Theta);                                                             |
> |>                                                                                 |
> |>    --The above is all legal Ada. However, the following mistakes would          |
> |>    --be legal in Eiffel but would be rejected by an Ada compiler...             |
> |>                                                                                 |
> |>    R := X;                                                                      |
> |                                                                                  |
> |Careful reading of this line of code shows the 'protection' against               |
> |mistakes occurs only after the 'subtype' has been initialized,"                   |
> |----------------------------------------------------------------------------------|
> 
> What?
> 
> |----------------------------------------------------------------------------------|
> |" but this:                                                                       |
> |                                                                                  |
> |X := 3.3;  -- for the sake of argument programmer                                 |
> |Y := 0.5;  -- wrote the GUI code backwards                                        |
> |R := 1.1;                                                                         |
> |Theta := 2.2;                                                                     |
> |Point(X, Y);                                                                      |
> |Point(R, Theta);                                                                  |
> |                                                                                  |
> |Happy compiler and code runs, albeit with unexpected results..."                  |
> |----------------------------------------------------------------------------------|
> 
> Nothing is foolproof, but I did prevent some accidents.

Yes, I agree on that and Ada has been a step forward on this direction, 
but as has been written elsewhere in this thread, Ada types do not form 
a 'type system' so it brings moderate safety against errors.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
> Nicholas Paul Collin Gloucester escreveu:
[...]
>> In this case there is a reason for having more types. An angle and a
>> length are simply not interchangable, so they should not be
>> represented both by Float. The amount of money equal to U.S.$1.00 is
>> not equal to the amount of money equal to 1.00 Canadian dollar, but
>> they are both written with the number 1.00.
>
> I disagree strongly: an angle in radians is a real number as any other
> there is not any intrinsic difference in its *type* on ordinary
> Mathematics.  Dimensionally they are 'pure numbers' with no unit
> atached, your example on monetary units being fallacious, so non
> sequitur.

Ada is not a language for mathematicians (mathematicians would rather
use e.g. Octave), it is a language for engineers.  In engineering,
there are very few pure numbers and quite a lot of dimensioned
numbers.  As an engineer, I certainly view angles, frequencies and
dimensionless constants (e.g. correction factors) as all having
different dimensions.

I would have declared the types for angles thus:
type Radians is new Float; -- no range restriction

You focused too much, IMHO, on the range restriction which is not the
important part.  The important part is that, in Ada, this declares a
new *type* (not a "subtype" or "nickname for Float"), which is
*incompatible* with Float or any other type.  This incompatibility has
two benefits: early detection of some errors (except, of course, those
involving literals of type universal_real) and documentation, to the
human reader, of what objects of the type represent in the real world.

[...]
> > Nothing is foolproof, but I did prevent some accidents.
>
> Yes, I agree on that and Ada has been a step forward on this direction,
> but as has been written elsewhere in this thread, Ada types do not form
> a 'type system' so it brings moderate safety against errors.

In Ada, floating-point literals (which were the crux of your argument)
belong to the type universal_real which allows implicit conversion to
any floating-point type.  If I understand your argument correctly, you
are suggesting that universal_real (and universal_integer) should
disappear and that the language should force the programmer to qualify
every literal, i.e.:

X : Radians := Radians'(3.0);

?

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Ludovic Brenta escreveu:
> Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
>> Nicholas Paul Collin Gloucester escreveu:
> [...]
>>> In this case there is a reason for having more types. An angle and a
>>> length are simply not interchangable, so they should not be
>>> represented both by Float. The amount of money equal to U.S.$1.00 is
>>> not equal to the amount of money equal to 1.00 Canadian dollar, but
>>> they are both written with the number 1.00.
>> I disagree strongly: an angle in radians is a real number as any other
>> there is not any intrinsic difference in its *type* on ordinary
>> Mathematics.  Dimensionally they are 'pure numbers' with no unit
>> atached, your example on monetary units being fallacious, so non
>> sequitur.
> 
> Ada is not a language for mathematicians (mathematicians would rather
> use e.g. Octave), it is a language for engineers.  In engineering,
> there are very few pure numbers and quite a lot of dimensioned
> numbers.  As an engineer, I certainly view angles, frequencies and
> dimensionless constants (e.g. correction factors) as all having
> different dimensions.
> 

Nice you bring this, Ludovic! However, remember the OP question:
<quote>
I'm a CS student and I often need to write number-crunching code dealing 
with combinatorial optimization problems.
What I do usually is implementing ad-hoc algorithms and testing their 
performance against other previously-known solutions, including general 
solvers.
</quote>

So your suggestion is to steer from Ada?

> I would have declared the types for angles thus:
> type Radians is new Float; -- no range restriction
> 
> You focused too much, IMHO, on the range restriction which is not the
> important part.  The important part is that, in Ada, this declares a
> new *type* (not a "subtype" or "nickname for Float"), which is
> *incompatible* with Float or any other type.  

More or less. It has all the operations of the derived type, uses the 
same representation on the machine.  The incompatibility is syntactic no 
in its essence.

For example: which type is the operation X^2 + Y^2, or Magnitude * 
cos(Theta)?

Does the subtyping in Ada complain if one makes an operation on two 
variables of type Length (here defined as 'type Length is new Float;') 
that there is not a compatible Length squared defined?

> This incompatibility has
> two benefits: early detection of some errors (except, of course, those
> involving literals of type universal_real) and documentation, to the
> human reader, of what objects of the type represent in the real world.

I agree this allows for some error protection, but as I showed already 
this only happens *after* the variable has been initialized with a value 
which for non trivial programs have to come from outside world.

> 
> [...]
>>> Nothing is foolproof, but I did prevent some accidents.
>> Yes, I agree on that and Ada has been a step forward on this direction,
>> but as has been written elsewhere in this thread, Ada types do not form
>> a 'type system' so it brings moderate safety against errors.
> 
> In Ada, floating-point literals (which were the crux of your argument)
> belong to the type universal_real which allows implicit conversion to
> any floating-point type.  If I understand your argument correctly, you
> are suggesting that universal_real (and universal_integer) should
> disappear and that the language should force the programmer to qualify
> every literal, i.e.:
> 
> X : Radians := Radians'(3.0);
> 
Why? Doesn't it make sense for you?

How would Ada gurus suggest the interfaces for reading data from outside 
the program (GUI, command line parameters, fields in files, etc.) be 
coded (in order to make full use of Ada features)?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

On Jul 21, 3:33 am, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Ludovic Brenta escreveu:
>
>
>
> > Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
> >> Nicholas Paul Collin Gloucester escreveu:
> > [...]
> >>> In this case there is a reason for having more types. An angle and a
> >>> length are simply not interchangable, so they should not be
> >>> represented both by Float. The amount of money equal to U.S.$1.00 is
> >>> not equal to the amount of money equal to 1.00 Canadian dollar, but
> >>> they are both written with the number 1.00.
> >> I disagree strongly: an angle in radians is a real number as any other
> >> there is not any intrinsic difference in its *type* on ordinary
> >> Mathematics.  Dimensionally they are 'pure numbers' with no unit
> >> atached, your example on monetary units being fallacious, so non
> >> sequitur.
>
> > Ada is not a language for mathematicians (mathematicians would rather
> > use e.g. Octave), it is a language for engineers.  In engineering,
> > there are very few pure numbers and quite a lot of dimensioned
> > numbers.  As an engineer, I certainly view angles, frequencies and
> > dimensionless constants (e.g. correction factors) as all having
> > different dimensions.
>
> Nice you bring this, Ludovic! However, remember the OP question:
> <quote>
> I'm a CS student and I often need to write number-crunching code dealing
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including general
> solvers.
> </quote>
>
> So your suggestion is to steer from Ada?

No, I would personally use Ada and make the number-crunching code into
generic units.  The user would then provide their application-defined
floating-point type as a generic parameter to instantiate the code.

> > I would have declared the types for angles thus:
> > type Radians is new Float; -- no range restriction
>
> > You focused too much, IMHO, on the range restriction which is not the
> > important part.  The important part is that, in Ada, this declares a
> > new *type* (not a "subtype" or "nickname for Float"), which is
> > *incompatible* with Float or any other type.  
>
> More or less. It has all the operations of the derived type, uses the
> same representation on the machine.  The incompatibility is syntactic no
> in its essence.
>
> For example: which type is the operation X^2 + Y^2, or Magnitude *
> cos(Theta)?

Simple.  In Ada, these expressions are illegal.  The user must
explicitly convert some of the values to a compatible type before
being allowed to mix objects of different types, e.g.

X : Horizontal_Coordinate := ...;
Y : Vertical_Coordinate := ...
R : Magnitude := Magnitude (X)**2 + Magnitude (Y)**2;
X := Horizontal_Coordinate (R) * Magnitude (cos (Theta));

You may say is it not "ergonomic" but, as an engineer, I see this as
"saying what you mean".  The best approach, of course, is to make the
above operations into application-specific operators, e.g.

function Magnitude_Of (X : Horizontal_Coordinate; Y :
Vertical_Coordinate)
  return Magnitude;

> Does the subtyping in Ada complain if one makes an operation on two
> variables of type Length (here defined as 'type Length is new Float;')
> that there is not a compatible Length squared defined?

No, unfortunately.  In Ada, Length squared is a Length.  There are
however libraries like [1] that allow full dimensioned computations.
They use compile-time checks where possible and run-time checks where
necessary.

[1] http://www.dmitry-kazakov.de/ada/units.htm

> > This incompatibility has
> > two benefits: early detection of some errors (except, of course, those
> > involving literals of type universal_real) and documentation, to the
> > human reader, of what objects of the type represent in the real world.
>
> I agree this allows for some error protection, but as I showed already
> this only happens *after* the variable has been initialized with a value
> which for non trivial programs have to come from outside world.

No.  The incompatibility between types is checked at compile time and
does not depend on values.  Indeed, it still works if all types are
declared as "new Float" with no range restriction.

> > [...]
> >>> Nothing is foolproof, but I did prevent some accidents.
> >> Yes, I agree on that and Ada has been a step forward on this direction,
> >> but as has been written elsewhere in this thread, Ada types do not form
> >> a 'type system' so it brings moderate safety against errors.
>
> > In Ada, floating-point literals (which were the crux of your argument)
> > belong to the type universal_real which allows implicit conversion to
> > any floating-point type.  If I understand your argument correctly, you
> > are suggesting that universal_real (and universal_integer) should
> > disappear and that the language should force the programmer to qualify
> > every literal, i.e.:
>
> > X : Radians := Radians'(3.0);
>
> Why? Doesn't it make sense for you?
>
> How would Ada gurus suggest the interfaces for reading data from outside
> the program (GUI, command line parameters, fields in files, etc.) be
> coded (in order to make full use of Ada features)?

The interfaces for reading from the outside already exist and they all
use typed input-output routines which check for range constraints (if
applicable) at run time. This makes is simply impossible to create
untyped values, or values of type universal_real, from outside the
program source. One example with streams:

   type Radians is new Float;
   F : Ada.Streams.Stream_IO.File_Type;
begin
   Ada.Streams.Stream_IO.Open (File => F,
                               Mode => Ada.Streams.Stream_IO.In_File,
                               Name => "foo.dat");
   declare
      S : constant Ada.Streams.Stream_IO.Stream_Access :=
        Ada.Streams.Stream_IO.Stream (F);
      R : Radians;
   begin
      Radians'Read (Stream => S, Item => R);
   end;
end;

(note : I wrote the above in an extra-verbose style to make context
unnecessary).

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Mon, 20 Jul 2009 22:33:59 -0300, Cesar Rabak wrote:

> Ludovic Brenta escreveu:
>> Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
>>> Nicholas Paul Collin Gloucester escreveu:
>> [...]
>>>> In this case there is a reason for having more types. An angle and a
>>>> length are simply not interchangable, so they should not be
>>>> represented both by Float. The amount of money equal to U.S.$1.00 is
>>>> not equal to the amount of money equal to 1.00 Canadian dollar, but
>>>> they are both written with the number 1.00.
>>> I disagree strongly: an angle in radians is a real number as any other
>>> there is not any intrinsic difference in its *type* on ordinary
>>> Mathematics.  Dimensionally they are 'pure numbers' with no unit
>>> atached, your example on monetary units being fallacious, so non
>>> sequitur.
>> 
>> Ada is not a language for mathematicians (mathematicians would rather
>> use e.g. Octave), it is a language for engineers.  In engineering,
>> there are very few pure numbers and quite a lot of dimensioned
>> numbers.  As an engineer, I certainly view angles, frequencies and
>> dimensionless constants (e.g. correction factors) as all having
>> different dimensions.
> 
> Nice you bring this, Ludovic! However, remember the OP question:
> <quote>
> I'm a CS student and I often need to write number-crunching code dealing 
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their 
> performance against other previously-known solutions, including general 
> solvers.
> </quote>
> 
> So your suggestion is to steer from Ada?

I don't think that Ludovic's example with dimensioned values was a good
argument. In fact there is no language with a good support of units. Ada is
not an exception here.

As for mathematics, Ada's type system is exactly right thing because it
supports ADTs. Mathematician would never talk about floats, but reals,
fields, rings etc. These mathematical structures are ADTs. An individual
number without specifying the structure where it belongs to is meaningless
in mathematics. The property of 1 of real and 1 of integer are different.
This is what the notion of type is about.
 
For number crunching it is even more important, because numerical methods
deal with different models of numbers. Even if the domain set is say real
(R), you might wish to consider to use something different than Long_Float,
because Long_Float is just a model of R, which might turn unsuitable for
your needs. Ada allows you to use various models, develop models of your
own, and design algorithms in terms of a specific model, as well as generic
ones in terms of some set of models.

Another important aspect is strong typing, which allows you to concentrate
on the problem rather than on debugging. Sometimes it is very difficult to
debug scientific applications like number crunching, because in many cases
you cannot tell whether the result is right. After all, the task of the
application is to give a result. If you knew it, you would not need to
crunch anything...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Dmitry A. Kazakov wrote:

|----------------------------------------------------------------------|
|"[..]                                                                 |
|                                                                      |
|[..] In fact there is no language with a good support of units. Ada is|
|not an exception here.                                                |
|                                                                      |
|[..]"                                                                 |
|----------------------------------------------------------------------|

Though Dmitry A. Kazakov and I both like Ada, we do not necessarily
agree as to what constitutes good support of units. Ada provides the
mapping
Type * Type -> Type
and ML provides the mapping
Type x Type -> (Type x Type)
and both of these can be worthy without being universally
desirable. It might be nice to have a language which supports both of
these kinds of mappings.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Tue, 21 Jul 2009 13:08:36 +0000, Colin Paul Gloster wrote:

> On Tue, 21 Jul 2009, Dmitry A. Kazakov wrote:
> 
>|----------------------------------------------------------------------|
>|"[..]                                                                 |
>|                                                                      |
>|[..] In fact there is no language with a good support of units. Ada is|
>|not an exception here.                                                |
>|                                                                      |
>|[..]"                                                                 |
>|----------------------------------------------------------------------|
> 
> Though Dmitry A. Kazakov and I both like Ada, we do not necessarily
> agree as to what constitutes good support of units. Ada provides the
> mapping
> Type * Type -> Type
> and ML provides the mapping
> Type x Type -> (Type x Type)
> and both of these can be worthy without being universally
> desirable. It might be nice to have a language which supports both of
> these kinds of mappings.

(If you consider static algebraic operations on types, then Ada supports
Cartesian product of types as well: that is standard record types.)

The problem with "good" units support is that you need both statically and
dynamically constrained (by the dimension) types, which are not only
numeric, but also containers. Ada (and any other language I know) lack
means to express the way dimension constraints propagate through (annotate)
type algebraic operations (like "A is array of T") rendering the operations
of the resulting types as unit-aware. Further these operations are normally
cross-typed (matrix of velocities multiplied by a vector of durations).
Ada's type system does not capture relations between types other than
inheritance. Maybe the algebra of dimensioned types can be expressed by
inheritance, maybe not. But Ada's inheritance is too weak for this.

And this is just a beginning, not even an end of the beginning. Consider
the thing other languages just ignore, I mean accuracy of the numeric
operation. In Ada we carefully specify the precision of the types we
declare. Now imagine these types annotated by dimensions. What happens with
the accuracy of computations of the data in inches performed in meters?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Tue, 21 Jul 2009, Dmitry A. Kazakov wrote:
> 
> |----------------------------------------------------------------------|
> |"[..]                                                                 |
> |                                                                      |
> |[..] In fact there is no language with a good support of units. Ada is|
> |not an exception here.                                                |
> |                                                                      |
> |[..]"                                                                 |
> |----------------------------------------------------------------------|
> 
> Though Dmitry A. Kazakov and I both like Ada, we do not necessarily
> agree as to what constitutes good support of units. Ada provides the
> mapping
> Type * Type -> Type
> and ML provides the mapping
> Type x Type -> (Type x Type)
> and both of these can be worthy without being universally
> desirable. It might be nice to have a language which supports both of
> these kinds of mappings.
Yes! but that means we'd need look after _another_ language :-(

--
Cesar Rabak

PS.: this post scriptum to circumvent the pesky news server that decided 
to censor the number of 'quoted lines' in message, but apparently makes 
it in a dumb way (perhaps computing some form of porcentage?).

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Dmitry A. Kazakov escreveu:
> On Mon, 20 Jul 2009 22:33:59 -0300, Cesar Rabak wrote:
> 
>> Ludovic Brenta escreveu:
>>> Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
>>>> Nicholas Paul Collin Gloucester escreveu:
>>> [...]
>>>>> In this case there is a reason for having more types. An angle and a
>>>>> length are simply not interchangable, so they should not be
>>>>> represented both by Float. The amount of money equal to U.S.$1.00 is
>>>>> not equal to the amount of money equal to 1.00 Canadian dollar, but
>>>>> they are both written with the number 1.00.
>>>> I disagree strongly: an angle in radians is a real number as any other
>>>> there is not any intrinsic difference in its *type* on ordinary
>>>> Mathematics.  Dimensionally they are 'pure numbers' with no unit
>>>> atached, your example on monetary units being fallacious, so non
>>>> sequitur.
>>> Ada is not a language for mathematicians (mathematicians would rather
>>> use e.g. Octave), it is a language for engineers.  In engineering,
>>> there are very few pure numbers and quite a lot of dimensioned
>>> numbers.  As an engineer, I certainly view angles, frequencies and
>>> dimensionless constants (e.g. correction factors) as all having
>>> different dimensions.
>> Nice you bring this, Ludovic! However, remember the OP question:
>> <quote>
>> I'm a CS student and I often need to write number-crunching code dealing 
>> with combinatorial optimization problems.
>> What I do usually is implementing ad-hoc algorithms and testing their 
>> performance against other previously-known solutions, including general 
>> solvers.
>> </quote>
>>
>> So your suggestion is to steer from Ada?
> 
> I don't think that Ludovic's example with dimensioned values was a good
> argument. In fact there is no language with a good support of units. Ada is
> not an exception here.
> 

I agree.

> As for mathematics, Ada's type system is exactly right thing because it
> supports ADTs. Mathematician would never talk about floats, but reals,
> fields, rings etc. These mathematical structures are ADTs. An individual
> number without specifying the structure where it belongs to is meaningless
> in mathematics. 

The support for ADTs in Ada is appropriate for its primary use but for 
mathematics it is not enough, except if you don't care of coding a lot 
of boilerplate code to have all the consistency you'll need (see 
Ludovic's reply to my observation about I/O for example).

> The property of 1 of real and 1 of integer are different.
> This is what the notion of type is about.

You did choose a very peculiar example :-) anyway for an [infinity] of 
values your assertion is reasonable true.

>  
> For number crunching it is even more important, because numerical methods
> deal with different models of numbers. Even if the domain set is say real
> (R), you might wish to consider to use something different than Long_Float,
> because Long_Float is just a model of R, which might turn unsuitable for
> your needs. Ada allows you to use various models, develop models of your
> own, and design algorithms in terms of a specific model, as well as generic
> ones in terms of some set of models.

Ada here is not as suitable as other languages, which Lisp is a better 
example because Floats ultimately map to the underlying HW (a case of 
premature optimization), whereas it could store the number as rationals 
increasing accuracy and avoiding numerical instability.

However, I agree if the OP is willing to develop the number crunching 
algorithms for similar languages (someone wrote in this thread 'Pascal 
like') them Ada is OK.

> 
> Another important aspect is strong typing, which allows you to concentrate
> on the problem rather than on debugging. Sometimes it is very difficult to
> debug scientific applications like number crunching, because in many cases
> you cannot tell whether the result is right. After all, the task of the
> application is to give a result. If you knew it, you would not need to
> crunch anything...
> 
After years working with both strong (and static) typed and more 
'dynamic' ones, I disagree on this.  Strong static typing plus the need 
of the signatures as we're discussing here brings a lot of artifacts 
that do not anything to do with the problem to be solved.

For doing experimental work (here as opposed to, say, writing a library 
for publishing) I suggest all be done in a dynamic language.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Tue, 21 Jul 2009 11:45:30 -0300, Cesar Rabak wrote:

> Dmitry A. Kazakov escreveu:
>> On Mon, 20 Jul 2009 22:33:59 -0300, Cesar Rabak wrote:

>> For number crunching it is even more important, because numerical methods
>> deal with different models of numbers. Even if the domain set is say real
>> (R), you might wish to consider to use something different than Long_Float,
>> because Long_Float is just a model of R, which might turn unsuitable for
>> your needs. Ada allows you to use various models, develop models of your
>> own, and design algorithms in terms of a specific model, as well as generic
>> ones in terms of some set of models.
> 
> Ada here is not as suitable as other languages, which Lisp is a better 
> example because Floats ultimately map to the underlying HW (a case of 
> premature optimization), whereas it could store the number as rationals 
> increasing accuracy and avoiding numerical instability.

Huh, numerical instability is a property of an algorithm. It is not one of 
rounding errors.

There is nothing in Ada which should prevent use of rational arithmetic, if 
that might be useful. Especially because one type of rational arithmetic is 
built in the language (see fixed point numbers). 

>> Another important aspect is strong typing, which allows you to concentrate
>> on the problem rather than on debugging. Sometimes it is very difficult to
>> debug scientific applications like number crunching, because in many cases
>> you cannot tell whether the result is right. After all, the task of the
>> application is to give a result. If you knew it, you would not need to
>> crunch anything...
>> 
> After years working with both strong (and static) typed and more 
> 'dynamic' ones, I disagree on this.  Strong static typing plus the need 
> of the signatures as we're discussing here brings a lot of artifacts 
> that do not anything to do with the problem to be solved.
> 
> For doing experimental work (here as opposed to, say, writing a library 
> for publishing) I suggest all be done in a dynamic language.

I am doing both scientific (fuzzy machine learning) and engineering 
(automation, SCADA) work in Ada. I never felt any need in making it more 
dynamic. In fact, I'd like to see much more static features in Ada, than it 
presently has. In my list are:

1. Contracted exceptions
2. Static pure functions
3. Compile time type constraints
4. Static pre-/postconditions and invariants

I don't buy Ada's current trend towards anonymous types, run-time checks, 
run-time pre-/post conditions, "functional style" of limited types 
initialization.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Dmitry A. Kazakov wrote:

|------------------------------------------------------------------------------|
|"[..]                                                                         |
|                                                                              |
|[..] In fact, I'd like to see much more static features in Ada, than it       |
|presently has. [..]"                                                          |
|------------------------------------------------------------------------------|

I also.

|------------------------------------------------------------------------------|
|"2. Static pure functions                                                     |
|[..]                                                                          |
|                                                                              |
|[..]"                                                                         |
|------------------------------------------------------------------------------|

The latest version of VHDL has these.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jean-Pierre Rosen]

Cesar Rabak a �crit :
> Ludovic Brenta escreveu:
>> You focused too much, IMHO, on the range restriction which is not the
>> important part.  The important part is that, in Ada, this declares a
>> new *type* (not a "subtype" or "nickname for Float"), which is
>> *incompatible* with Float or any other type.  
> 
> More or less. It has all the operations of the derived type, uses the
> same representation on the machine.  The incompatibility is syntactic no
> in its essence.
> 
Here is the crux of the misunderstanding: sure, at /machine/ level they
are the same, but in the /problem domain/ they are different. The big
difference between Ada an other languages is that types (even elementary
ones) reflect the problem domain, not machine types.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Jean-Pierre Rosen schrieb:
> Cesar Rabak a �crit :
>> Ludovic Brenta escreveu:
>>> You focused too much, IMHO, on the range restriction which is not the
>>> important part.  The important part is that, in Ada, this declares a
>>> new *type* (not a "subtype" or "nickname for Float"), which is
>>> *incompatible* with Float or any other type.  
>> More or less. It has all the operations of the derived type, uses the
>> same representation on the machine.  The incompatibility is syntactic no
>> in its essence.
>>
> Here is the crux of the misunderstanding: sure, at /machine/ level they
> are the same, but in the /problem domain/ they are different. The big
> difference between Ada an other languages is that types (even elementary
> ones) reflect the problem domain, not machine types.

It might be worth mentioning that derived elementary types
neet *not* have the same representation.  Gems #27 and #28
talk about opportunities and dangers of using two different
representations for the "same" derived type (as I am certain
you know):

http://www.adacore.com/category/developers-center/gems/

For example, the multiplications in a silly dummy below
use operands of different sizes, as expected.  So they are
really different, even at the machine level.

procedure Rep is

   package P is

      type T0 is range 0 .. 1_000;
      for T0'Size use 16;

      function From_String(Input: String) return T0;


      type T1 is new T0;
      for T1'Size use 64;

   end P;

   package body P is separate;
   use P;

   X0: T0;
   X1: T1;
   Y: T0;

begin

   X0 := P.From_String("3");
   X1 := P.From_String("5");

   X0 := X0 * X0;
   X1 := X1 * X1;

   Y := X0 + T0(X1);

   pragma Inspection_Point(Y);  -- stop ambitious optimizers

end Rep;


--
Georg Bauhaus

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Jean-Pierre Rosen escreveu:
> Cesar Rabak a �crit :
>> Ludovic Brenta escreveu:
[snipped]
>> More or less. It has all the operations of the derived type, uses the
>> same representation on the machine.  The incompatibility is syntactic no
>> in its essence.
>>
> Here is the crux of the misunderstanding: sure, at /machine/ level they
> are the same, but in the /problem domain/ they are different. The big
> difference between Ada an other languages is that types (even elementary
> ones) reflect the problem domain, not machine types.

Yes but the crux is another: the four 'new types' suggested for solution 
to a problem shown by B. Meyers in Ada language for the need of 
different function signatures *do not* reflect the problem domain: for 
the later all the numbers are just this _numbers�_.  The Ada 
implementation in order to be able to have two different 'constructors' 
for the new type Point (this indeed a *new* type) created through its 
mechanisms subtypes, which only send the trash over the wall.  All this 
discussion about avoiding programmer errors can be attained instead of 
creating four nicknames for Float to allow:

procedure makePointXY(X : Float; Y : Float) is
    begin
       null; --Whatever.
    end;

procedure makePoint_R_Theta(R : Float; Theta : Float) is
    begin
       null; --Whatever.
    end;

Do you agree the programmer will find the mistake easily as well?

--
Cesar Rabak

[1] Specializations of the concept for say a screen where coordinates 
are integers and limited to screeen area, for example are not being 
discussed here, as are not the kernel of Meyer's critique.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Cesar Rabak schrieb:
>  All this
> discussion about avoiding programmer errors can be attained instead of
> creating four nicknames for Float to allow:
> 
> procedure makePointXY(X : Float; Y : Float) is
>    begin
>       null; --Whatever.
>    end;
> 
> procedure makePoint_R_Theta(R : Float; Theta : Float) is
>    begin
>       null; --Whatever.
>    end;
> 
> Do you agree the programmer will find the mistake easily as well?


How is the example you have given different from

  procedure informalHint_H001(A : ANY; B : ANY) is
    begin
      null;
    end;

  procedure informalHint_H002(A : ANY; B : ANY) is
    begin
      null;
    end;

with the procedure names replaced to match some
formal terms from the problem domain, but the types
left as is?
And what should we conclude then?

We need a solid general case here, I think, to get this
argument away from things that are accidental.  What's the
power of a type when it comes to program construction?


Floats are an issue here.  Let my insignificant finger
point at a strange mental, but measurable, line that language
makers and programmers alike draw
- between types reflecting elementary school experience,
- and types that they themselves defin, carefully[*].

Int, float, and char are taken to be meaningful rocksolid
concepts!
To the effect that every other week you see a CERT
advisory putting our noses into a dangerous mud of int
overflows (and buffer overflows), risking entire systems'
operation.
Isn't this a <emphasis void="crescendo">hint</emphasis>
that *not* bothering with elementary types is an
EMBARRASING_MISTAKE of programming men and women!?
Well, at least if programming errors of this careless
kind do not contribute to our staying in business.


[*] Dabbling in basics of mathematics, I noticed that the
more prominent an author is or was, the higher his awareness
of the fact that we *don't* know what numbers are,
or how we manipulate them (Landau, Halmos, Weyl,
Dirichlet/Dedekind---I just looked at some intriguing
material, not the entire stuff).

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Georg Bauhaus escreveu:
> Cesar Rabak schrieb:
>>  All this
>> discussion about avoiding programmer errors can be attained instead of
>> creating four nicknames for Float to allow:
>>
>> procedure makePointXY(X : Float; Y : Float) is
>>    begin
>>       null; --Whatever.
>>    end;
>>
>> procedure makePoint_R_Theta(R : Float; Theta : Float) is
>>    begin
>>       null; --Whatever.
>>    end;
>>
>> Do you agree the programmer will find the mistake easily as well?
> 
> 
> How is the example you have given different from
> 
>   procedure informalHint_H001(A : ANY; B : ANY) is
>     begin
>       null;
>     end;
> 
>   procedure informalHint_H002(A : ANY; B : ANY) is
>     begin
>       null;
>     end;
> 
> with the procedure names replaced to match some
> formal terms from the problem domain, but the types
> left as is?
> And what should we conclude then?
> 

I conclude that the intent to prove B. Meyer was wrong in his OOSC 
example about the issue of procedure signatures for overloading (which 
happened to be in Ada and Colin bit the bullet) did not arrive at its 
intent.

> We need a solid general case here, I think, to get this
> argument away from things that are accidental.  What's the
> power of a type when it comes to program construction?

The new types were introduced as means to circumvent Meyer's objection, 
and in this case we arrive at the conclusion that they quickly become 
artificial artifacts and worsen the 'ergonomics' of the programming.

> 
> 
> Floats are an issue here.  Let my insignificant finger
> point at a strange mental, but measurable, line that language
> makers and programmers alike draw
> - between types reflecting elementary school experience,
> - and types that they themselves defin, carefully[*].
> 

Sorry if it seems so. The issue I was trying to rise is that subtyping 
(in this case Float) did not solve, instead make it worse, the problem 
that B. Meyer rises.

That can happen with other types as well.

> Int, float, and char are taken to be meaningful rocksolid
> concepts!
> To the effect that every other week you see a CERT
> advisory putting our noses into a dangerous mud of int
> overflows (and buffer overflows), risking entire systems'
> operation.

Yes, but this is subject to another thread. But before you get too much 
hope, remember an int overflow did blow an Arianne rocket...

> Isn't this a <emphasis void="crescendo">hint</emphasis>
> that *not* bothering with elementary types is an
> EMBARRASING_MISTAKE of programming men and women!?

Buffer overflows are not an 'elementary types' problem, it is another 
kind of problem.

> Well, at least if programming errors of this careless
> kind do not contribute to our staying in business.

As I mentioned in this thread, the error about measurement systems that 
costed NASA a Mars mission was coded in type safe system's language, 
wasn't it?

> 
> 
> [*] Dabbling in basics of mathematics, I noticed that the
> more prominent an author is or was, the higher his awareness
> of the fact that we *don't* know what numbers are,
> or how we manipulate them (Landau, Halmos, Weyl,
> Dirichlet/Dedekind---I just looked at some intriguing
> material, not the entire stuff).

[**] Yup! But then we slip to very philosophical discussion ;-)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Cesar Rabak wrote:

|------------------------------------------------------------------------------|
|"[..]                                                                         |
|                                                                              |
|Yes, but this is subject to another thread. But before you get too much hope, |
|remember an int overflow did blow an Arianne rocket..."                       |
|------------------------------------------------------------------------------|

An Ariane 5 rocket which was running flawless software for an Ariane 4
rocket which was misapplied to the Ariane 5 by a manager despite
objections from the software developers. Furthermore, Ada could have
had an exception handler there, but it has not yet proven to be
necessary for an Ariane 4.


|------------------------------------------------------------------------------|
|"[..]                                                                         |
|                                                                              |
|As I mentioned in this thread, the error about measurement systems that costed|
|NASA a Mars mission was coded in type safe system's language, wasn't it?      |
|                                                                              |
|[..]"                                                                         |
|------------------------------------------------------------------------------|

I do not know. Some hints...
FORTRAN influence:
Robert B. Love
Subject: Re: Loss of Mars Climate Orbiter due to units of measurment conflicts
Date: 1999/10/02
Message-ID: <6C26F727ACB69543.66B23092D324DEF8.14EA2C28DF27855B@lp.airnews.net>#1/1
comp.lang.ada
(and Ada advocacy: Michel DELARCHE
Subject: Re: Loss of Mars Climate Orbiter due to units of measurment conflicts
Date: 1999/10/02
Message-ID: <37F64C20.1A05BCF3@cybercable.fr>#1/1
)
and
Lockheed Martin did not adhere to contracted units:
Michel DELARCHE
Subject: Re: Loss of Mars Climate Orbiter due to units of measurment conflicts
Date: 1999/10/02
Message-ID: <37F648AE.566C2BB8@cybercable.fr>#1/1

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Tue, 21 Jul 2009, Cesar Rabak wrote:
> 
> |------------------------------------------------------------------------------|
> |"[..]                                                                         |
> |                                                                              |
> |Yes, but this is subject to another thread. But before you get too much hope, |
> |remember an int overflow did blow an Arianne rocket..."                       |
> |------------------------------------------------------------------------------|
> 
> An Ariane 5 rocket which was running flawless software for an Ariane 4
> rocket which was misapplied to the Ariane 5 by a manager despite
> objections from the software developers. Furthermore, Ada could have
> had an exception handler there, but it has not yet proven to be
> necessary for an Ariane 4.

Yes, however the exception on Ariane 5 happened and it blew (or had to 
be blown): no technology saves us from mismanagement, but a wrong feel 
of safety helps managers to make bad calls...

> 
> |------------------------------------------------------------------------------|
> |"[..]                                                                         |
> |                                                                              |
> |As I mentioned in this thread, the error about measurement systems that costed|
> |NASA a Mars mission was coded in type safe system's language, wasn't it?      |
> |                                                                              |
> |[..]"                                                                         |
> |------------------------------------------------------------------------------|
> 
> I do not know. Some hints...

Nor I either, and probably if we dig in the issue, some account similar 
to the Arianne will surface where managers would be behind the root cause.

It has to be that way, right!? They're better paid, can afford to make 
more expensive mistakes :-D

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Robert Love]

On 2009-07-22 09:10:01 -0500, Colin Paul Gloster said:

> I do not know. Some hints...
> FORTRAN influence:
> Robert B. Love
> Subject: Re: Loss of Mars Climate Orbiter due to units of measurment conflicts
> Date: 1999/10/02
> Message-ID: 
> <6C26F727ACB69543.66B23092D324DEF8.14EA2C28DF27855B@lp.airnews.net>#1/1
> comp.lang.ada

Boy, it is weird seeing your name cited from a decade old message.  I 
don't remember what I said.  I do have a memory that LM (MM in those 
days) was supposed to use SI units per the agreement but used British 
Engineering units.   The context was information sent to NASA/JPL after 
the launch about the LEO orbit.    Strange, the space program still 
seems to be using feet and nautical miles.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 23 Mar 2010, Robert Love wrote:

|--------------------------------------------------------------------------------|
|"On 2009-07-22 09:10:01 -0500, Colin Paul Gloster said:                         |
|                                                                                |
|> I do not know. Some hints...                                                  |
|> FORTRAN influence:                                                            |
|> Robert B. Love                                                                |
|> Subject: Re: Loss of Mars Climate Orbiter due to units of measurment conflicts|
|> Date: 1999/10/02                                                              |
|> Message-ID:                                                                   |
|> <6C26F727ACB69543.66B23092D324DEF8.14EA2C28DF27855B@lp.airnews.net>#1/1       |
|> comp.lang.ada                                                                 |
|                                                                                |
|Boy, it is weird seeing your name cited from a decade old message.  I don't     |
|remember what I said."                                                          |
|--------------------------------------------------------------------------------|

I have had this effect on people. If you want to remind yourself you
could try copying the Message-ID into the bottom of
HTTP://groups.Google.com/advanced_search?q=&

|--------------------------------------------------------------------------------|
|"[..]                                                                           |
|[..]    Strange, the space program still seems to be using feet and nautical    |
|miles."                                                                         |
|--------------------------------------------------------------------------------|

People fail to learn.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Cesar Rabak wrote:

|-------------------------------------------------------------------------------|
|"[..]                                                                          |
|                                                                               |
|[..]  All this discussion about avoiding programmer errors can be attained     |
|instead of creating four nicknames for Float to allow:                         |
|                                                                               |
|procedure makePointXY(X : Float; Y : Float) is                                 |
|   begin                                                                       |
|      null; --Whatever.                                                        |
|   end;                                                                        |
|                                                                               |
|procedure makePoint_R_Theta(R : Float; Theta : Float) is                       |
|   begin                                                                       |
|      null; --Whatever.                                                        |
|   end;                                                                        |
|                                                                               |
|Do you agree the programmer will find the mistake easily as well?              |
|                                                                               |
|[..]"                                                                          |
|-------------------------------------------------------------------------------|

Yes.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 21 juil, 03:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Does the subtyping in Ada complain if one makes an operation on two
> variables of type Length (here defined as 'type Length is new Float;')
> that there is not a compatible Length squared defined?

Yes it will, providing you've design things to go this way (compilers
are still automata, not form or artificial with capabilities to read
in your minde).

For your example, you may first define a private type, so that the
user of the type (except package implementation and child package)
cannot rely on its representation (a black box). You may define
initializers, which would be required, as the user would not be able
to initialize any value otherise. Ex. “ function To_Length (Value :
Natural) return Length_Type ” or “ procedure Set (Length : in out
Length_Type; Value : Natural); ”. You may also have a “ type
Length_Squared_Type is private; ”, private as well and a function “
function Length_Squared (Left, Right : Length_Type) return
Length_Squared_Type; ”. As you see, you can have a fully secured set
of specifications : the user can do only what is defined, and nothing
else. So it is easy to enforce Length_Type * Length_Type to be of type
Length_Squared_Type. Beceause the user cannot do a direct Length_Type
* Length_Type and must use the function you provide in this purpose.

Note : as Length_Type and Length_Squared_Type would probably be
defined in the same package specification, then Length_Squared_Type
could not derived from Length_Type (language rules), and and if you
want to use the same representation for both they could just both
derives from a base representation type which could not exist in the
public speficiation of the package, and then a little convertion will
be needed in the implementation. However, it would probably be nice to
have a wider type for Length_Squared_Type and to not have the same
representation (unless the Length_Type is designed so that there is
never an overflow when computing a Length_Squared_Type).

I apologize for details, as I'm not sure you know Ada well (it seems
this thread is broadcasted in multiple comp.lang.* at the same time).
But even with your Eiffel skills, I think it is possible to understand
the most important aspects.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Mon, 20 Jul 2009, Cesar Rabak wrote:

|-------------------------------------------------------------------------------|
|"[..]                                                                          |
|Nicholas Paul Collin Gloucester escreveu:                                      |
|> On 2009-07-20, Cesar Rabak <csrabak@yahoo.com.br> wrote:                     |
|[..]                                                                           |
|> In this case there is a reason for having more types. An angle and a         |
|> length are simply not interchangable, so they should not be                  |
|> represented both by Float. The amount of money equal to U.S.$1.00 is         |
|> not equal to the amount of money equal to 1.00 Canadian dollar, but          |
|> they are both written with the number 1.00.                                  |
|>                                                                              |
|                                                                               |
|I disagree strongly: an angle in radians is a real number as any other there is|
|not any intrinsic difference in its *type* on ordinary Mathematics.            |
|Dimensionally they are 'pure numbers' with no unit atached, your example on    |
|monetary units being fallacious, so non sequitur."                             |
|-------------------------------------------------------------------------------|

I doubt that you or I shall convince me or you but... if you want to
complain that I misuse the word "type", then fine. If you want to
claim that an angle in radians is the same thing as a length, then you
are mistaken. You can measure an angle with a protractor. You can not
measure a length with a protractor. You can measure a length with a
ruler. You can not measure an angle with a ruler (without some
additional hassle). A rotation is not a translation, despite both
being transformations.

If you believe that a real number of an angle in radians is the same
as a length, then do you believe that a real number of an angle
gradients is the same as a real number of an angle in degrees? 200.0
(a measurement in gradients of an angle) is not equal to pi (a
measurement in radians of the same angle) which is not equal to 180.0
(a measurement in degrees of the same angle). The angle is the same
and the numbers are not so casually interchangable.

A NASA probe was lost when all units were treated as equivalent
numbers.

|-------------------------------------------------------------------------------|
|"[..]                                                                          |
|                                                                               |
|As for normalization, IMNHO it has to be done in the constructor of the        |
|class/object, and not as an (external) wrapper."                               |
|-------------------------------------------------------------------------------|

I did not necessarily prohibit that. The wrapper could be called by
the constructor. The wrapper is external to the floating point Ada
type Radians or Magnitude or X_Coordinate or Y_Coordinate, which
itself could be restricted to the internals of a client's class, much
as a C++ std::string might use a char* internally.

If normalization is required, it might not be ideal to keep it in the
constructor because a variable could be constructed whose value is
changed later, for example
--Call a constructor for Radius but do not give it a value yet.
[..]
  for some_iterations loop
    Radius := Get_Current_Radius;
    --Do stuff.
  end loop;

|-------------------------------------------------------------------------------|
|"> With the type Radians as I had typed it,                                    |
|> Theta := 7.0;                                                                |
|> would not result in a runtime exception. It would be rejected by a           |
|> compiler.                                                                    |
|                                                                               |
|Because we are dealing with examples with literals, let the value come from an |
|input...                                                                       |
|                                                                               |
|[..]"                                                                          |
|-------------------------------------------------------------------------------|

Literals are not restricted to input, but yes, a runtime exception
would occur with input if some other precaution is not taken.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Mon, 20 Jul 2009, Cesar Rabak wrote:
[snipped]

> 
> I doubt that you or I shall convince me or you but... if you want to
> complain that I misuse the word "type", then fine. 

I don't think you do on purpose, it is the nature of the crosspost to 
have certain concepts blurred by the naming conventions of each technology.

> If you want to
> claim that an angle in radians is the same thing as a length, then you
> are mistaken. 

I did not say that, and your example also is not an implementation of that.

> You can measure an angle with a protractor. You can not
> measure a length with a protractor. You can measure a length with a
> ruler. You can not measure an angle with a ruler (without some
> additional hassle). A rotation is not a translation, despite both
> being transformations.
> 
> If you believe that a real number of an angle in radians is the same
> as a length, then do you believe that a real number of an angle
> gradients is the same as a real number of an angle in degrees? 200.0
> (a measurement in gradients of an angle) is not equal to pi (a
> measurement in radians of the same angle) which is not equal to 180.0
> (a measurement in degrees of the same angle). The angle is the same
> and the numbers are not so casually interchangable.
> 

Worse than that: radians are always pure numbers because the way they 
are defined they are relations between two lengths (which for correct 
results have to be in the same unit ;-).

If you want to discuss about new types around above arguments, you'll 
agree that a new type Length would need to accept several _units_ of 
measurement and keep an internal representation which is opaque for 
this, but able to respond to requests of its 'size' in whichever units 
the system have been devised to support.  Also some operations would 
create no units at all (division would give pure numbers [except if both 
operands explicitly require different units, to allow unit conversions], 
multiplication would give Area, etc.).

> A NASA probe was lost when all units were treated as equivalent
> numbers.

Yes and no line of Ada code could save the poor engineers that made that 
mistake (I bet B. Meyer would say Eiffel would :-)

> 
> |-------------------------------------------------------------------------------|
> |"[..]                                                                          |
> |                                                                               |
> |As for normalization, IMNHO it has to be done in the constructor of the        |
> |class/object, and not as an (external) wrapper."                               |
> |-------------------------------------------------------------------------------|
> 
> I did not necessarily prohibit that. The wrapper could be called by
> the constructor. The wrapper is external to the floating point Ada
> type Radians or Magnitude or X_Coordinate or Y_Coordinate, which
> itself could be restricted to the internals of a client's class, much
> as a C++ std::string might use a char* internally.

Notice that all this would be unnecessary if the language's needs did 
not entered into the problem: once an internal representation for the 
type Point had been chosen, the constructors would accept the values and 
do the conversion, which in case of the <rho, theta> representation 
would be done as part of the constructor job.

> 
> If normalization is required, it might not be ideal to keep it in the
> constructor because a variable could be constructed whose value is
> changed later, for example
> --Call a constructor for Radius but do not give it a value yet.
> [..]
>   for some_iterations loop
>     Radius := Get_Current_Radius;
>     --Do stuff.
>   end loop;

The example must be too contrived and I have not code Ada for years to 
understand it, but again it seems to be more an Ada technology related 
issue than a fundamental aspect.

> 
> |-------------------------------------------------------------------------------|
> |"> With the type Radians as I had typed it,                                    |
> |> Theta := 7.0;                                                                |
> |> would not result in a runtime exception. It would be rejected by a           |
> |> compiler.                                                                    |
> |                                                                               |
> |Because we are dealing with examples with literals, let the value come from an |
> |input...                                                                       |
> |                                                                               |
> |[..]"                                                                          |
> |-------------------------------------------------------------------------------|
> 
> Literals are not restricted to input, but yes, a runtime exception
> would occur with input if some other precaution is not taken.

Ludovic has shown all else would be required to attain a safer 
implementation.  As soon one starts to code for real the number of lines 
of code grow exponentially ;-)

Regards,

--
Cesar Rabak

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 21 Jul 2009, Cesar Rabak wrote:

|-----------------------------------------------------------------------------------|
|"[..]                                                                              |
|                                                                                   |
|>                                                                                  |
|> |-------------------------------------------------------------------------------||
|> |"[..]                                                                           |
|> |                                                                                |
|> |                                                                                |
|> |                                                                                |
|> |As for normalization, IMNHO it has to be done in the constructor of the         |
|> |                                                                                |
|> |class/object, and not as an (external) wrapper."                                |
|> |                                                                                |
|> |-------------------------------------------------------------------------------||
|>                                                                                  |
|> I did not necessarily prohibit that. The wrapper could be called by              |
|> the constructor. The wrapper is external to the floating point Ada               |
|> type Radians or Magnitude or X_Coordinate or Y_Coordinate, which                 |
|> itself could be restricted to the internals of a client's class, much            |
|> as a C++ std::string might use a char* internally.                               |
|                                                                                   |
|Notice that all this would be unnecessary if the language's needs did not          |
|entered into the problem: once an internal representation for the type Point had   |
|been chosen, the constructors would accept the values and do the conversion,       |
|which in case of the <rho, theta> representation would be done as part of the      |
|constructor job.                                                                   |
|                                                                                   |
|>                                                                                  |
|> If normalization is required, it might not be ideal to keep it in the            |
|> constructor because a variable could be constructed whose value is               |
|> changed later, for example                                                       |
|> --Call a constructor for Radius but do not give it a value yet.                  |
|> [..]                                                                             |
|>   for some_iterations loop                                                       |
|>     Radius := Get_Current_Radius;                                                |
|>     --Do stuff.                                                                  |
|>   end loop;                                                                      |
|                                                                                   |
|The example must be too contrived and I have not code Ada for years to             |
|understand it, but again it seems to be more an Ada technology related issue       |
|than a fundamental aspect.                                                         |
|                                                                                   |
|[..]"                                                                              |
|-----------------------------------------------------------------------------------|


No, it is not contrived. Unlike a functional language in which every
so-called variable is actually constant, Ada is an imperative language
in which it is common to assign a different value to a variable after
it has already been assigned an earlier value.

In this example, a variable was declared and it was assigned many
values in a loop (perhaps from a GUI). Unless you meant something else
by constructor, checking for errors should not be performed just in
the constructor when the variable begins to exist.

Regards,
Colin Paul Gloster

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Colin Paul Gloster wrote:
> No, it is not contrived. Unlike a functional language in which every
> so-called variable is actually constant...

*Purely* functional, perhaps?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Thu, 23 Jul 2009, Jon Harrop wrote:

|----------------------------------------------------------------------|
|"Colin Paul Gloster wrote:                                            |
|> No, it is not contrived. Unlike a functional language in which every|
|> so-called variable is actually constant...                          |
|                                                                      |
|*Purely* functional, perhaps?"                                        |
|----------------------------------------------------------------------|

If something is not purely functional then it is not functional. If
something is not purely clean, then it is not clean. Sure, people do
describe something as being "cleaned" when not all dirt particles have
been banished from it, and people call languages which are not purely
functional "functional", but being called something and being that
something are different.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Colin Paul Gloster wrote:
> On Thu, 23 Jul 2009, Jon Harrop wrote:
> 
> |----------------------------------------------------------------------|
> |"Colin Paul Gloster wrote:                                            |
> |> No, it is not contrived. Unlike a functional language in which every|
> |> so-called variable is actually constant...                          |
> |                                                                      |
> |*Purely* functional, perhaps?"                                        |
> |----------------------------------------------------------------------|
> 
> If something is not purely functional then it is not functional. If
> something is not purely clean, then it is not clean. Sure, people do
> describe something as being "cleaned" when not all dirt particles have
> been banished from it, and people call languages which are not purely
> functional "functional", but being called something and being that
> something are different.

In other words, you want to use a different definition of "functional" to
almost everyone else. No problem, the Haskell community do it all the time.
I just wanted to make that clear.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Thu, 23 Jul 2009, Jon Harrop wrote:
> 
> |----------------------------------------------------------------------|
> |"Colin Paul Gloster wrote:                                            |
> |> No, it is not contrived. Unlike a functional language in which every|
> |> so-called variable is actually constant...                          |
> |                                                                      |
> |*Purely* functional, perhaps?"                                        |
> |----------------------------------------------------------------------|
> 
> If something is not purely functional then it is not functional. If

Colin, if you take this reasoning then Ada is not OO. . .

just .019999.....

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Thu, 23 Jul 2009 22:08:48 -0300, Cesar Rabak wrote:

> Colin Paul Gloster escreveu:
>> On Thu, 23 Jul 2009, Jon Harrop wrote:
>> 
>>|----------------------------------------------------------------------|
>>|"Colin Paul Gloster wrote:                                            |
>>|> No, it is not contrived. Unlike a functional language in which every|
>>|> so-called variable is actually constant...                          |
>>|                                                                      |
>>|*Purely* functional, perhaps?"                                        |
>>|----------------------------------------------------------------------|
>> 
>> If something is not purely functional then it is not functional. If
> 
> Colin, if you take this reasoning then Ada is not OO. . .

But it could become OO. While no language can ever become functional, since
"functionally" the only reason for a computer to exist is to produce
non-functional side effects....

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[sjw]

On Jul 20, 1:15 pm, Nicholas Paul Collin Gloucester
<Colin_Paul_Glos...@ACM.org> wrote:

>    type Horizontal_Coordinate is new Float;
>    type Vertical_Coordinate is new Float;
>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>    begin
>       null; --Whatever.
>    end;
>
>    type Magnitude is new Float;
>    type Radians is new Float range -3.14*2.0 .. 3.14*2.0;
>    procedure Point(R : Magnitude; Theta : Radians) is
>    begin
>       null; --Whatever.
>    end;

And what will happen to this distinction with Point (2.0, 2.0);?

You could use named parameter association, but *much* better to use
proper types --

type Cartesian_Coordinate is record
   X : Metres;
   Y : Metres;
end record;

which makes it easy to (for instance) create appropriate functions
"+", "-", "*", "/".


I don't think I'd ever, even in an example, write 3.14 for
Ada.Numerics.Pi. We have a partner company who redefined pi to be
3.14159, causing a lot of expense to both sides when we sent a value
greater than this (but less than Ada.Numerics.Pi) and they rejected
it ..

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Wed, 22 Jul 2009 12:29:36 -0700 (PDT), sjw wrote:

> On Jul 20, 1:15�pm, Nicholas Paul Collin Gloucester
> <Colin_Paul_Glos...@ACM.org> wrote:
> 
>> � �type Horizontal_Coordinate is new Float;
>> � �type Vertical_Coordinate is new Float;
>> � �procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>> � �begin
>> � � � null; --Whatever.
>> � �end;
>>
>> � �type Magnitude is new Float;
>> � �type Radians is new Float range -3.14*2.0 .. 3.14*2.0;
>> � �procedure Point(R : Magnitude; Theta : Radians) is
>> � �begin
>> � � � null; --Whatever.
>> � �end;
> 
> And what will happen to this distinction with Point (2.0, 2.0);?

The rule is "never use magical constants". This applies both to 3.14 and to
2.0. In any case it should better be:

   (2.0 * Horizontal_Unit, 2.0 * Vertical_Unit)

> You could use named parameter association, but *much* better to use
> proper types --
> 
> type Cartesian_Coordinate is record
>    X : Metres;
>    Y : Metres;
> end record;

That depends on whether the surface isotropic, in GUI it is usually not,
which makes sense in having Horizontal_Coordinate and Vertical_Coordinate
distinct. In older alphanumerical displays the aspect ratio was not 1. It
was important to keep units different for the vertical and horizontal
coordinates. Though Radians let us assume otherwise....
 
> which makes it easy to (for instance) create appropriate functions
> "+", "-", "*", "/".

Yes.

Interestingly, but I have an impression that a well-done Ada program can be
improved, sort of, infinitely. The language is so rich, there are many
semantic layers hard if possible to penetrate at once... I am not ready to
claim whether this is an advantage or disadvantage.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Wed, 22 Jul 2009, Simon J. Wright wrote:

|--------------------------------------------------------------------|
|"[..]                                                               |
|                                                                    |
|And what will happen to this distinction with Point (2.0, 2.0);?    |
|                                                                    |
|You could use named parameter association, but *much* better to use |
|proper types --                                                     |
|                                                                    |
|type Cartesian_Coordinate is record                                 |
|   X : Metres;                                                      |
|   Y : Metres;                                                      |
|end record;                                                         |
|                                                                    |
|which makes it easy to (for instance) create appropriate functions  |
|"+", "-", "*", "/"."                                                |
|--------------------------------------------------------------------|

Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an
example of overloading which Eiffel can perform which he claimed that
Ada can not manage. The pseudo-Ada example by Dr. Meyer did not have a
record, and a less minor upgrade than adding a record was sufficient
to show that Dr. Meyer did not know what he was writing about.

|--------------------------------------------------------------------|
|"I don't think I'd ever, even in an example, write 3.14 for         |
|Ada.Numerics.Pi. We have a partner company who redefined pi to be   |
|3.14159, causing a lot of expense to both sides when we sent a value|
|greater than this (but less than Ada.Numerics.Pi) and they rejected |
|it .."                                                              |
|--------------------------------------------------------------------|

Ah well.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Wed, 22 Jul 2009, Simon J. Wright wrote:
> 
> |--------------------------------------------------------------------|
> |"[..]                                                               |
> |                                                                    |
> |And what will happen to this distinction with Point (2.0, 2.0);?    |
> |                                                                    |
> |You could use named parameter association, but *much* better to use |
> |proper types --                                                     |
> |                                                                    |
> |type Cartesian_Coordinate is record                                 |
> |   X : Metres;                                                      |
> |   Y : Metres;                                                      |
> |end record;                                                         |
> |                                                                    |
> |which makes it easy to (for instance) create appropriate functions  |
> |"+", "-", "*", "/"."                                                |
> |--------------------------------------------------------------------|
> 
> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an
> example of overloading which Eiffel can perform 

Since you citing me (incorrectly) and write this:

> which he claimed that
> Ada can not manage. 

Writing a wrong assertion about a book it seems you only read a summary 
made before a term exam, I suggest you get the text you implied you were 
mentioning, specially the four paragraph on page 94 (OOSC 2nd ed.) and 
pay attention to was is *actually* written there.

> The pseudo-Ada example by Dr. Meyer did not have a
> record, and a less minor upgrade than adding a record was sufficient
> to show that Dr. Meyer did not know what he was writing about.

Yes it did have a record because this perversion of creating a lot of 
nicknames for solving a problem B. Meyer proposed a different approach.

If mentioning Ada hurts so much your feelings, rest assured the same 
could be said about C++ :-)

Please keep the discussion on the technical aspects and don't make 
personal attacks: they do not add anything to enlightenment for anybody.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Cesar Rabak wrote:
> Colin Paul Gloster escreveu:
>> On Wed, 22 Jul 2009, Simon J. Wright wrote:
>>
>> |--------------------------------------------------------------------|
>> |"[..]                                                               |
>> |                                                                    |
>> |And what will happen to this distinction with Point (2.0, 2.0);?    |
>> |                                                                    |
>> |You could use named parameter association, but *much* better to use |
>> |proper types --                                                     |
>> |                                                                    |
>> |type Cartesian_Coordinate is record                                 |
>> |   X : Metres;                                                      |
>> |   Y : Metres;                                                      |
>> |end record;                                                         |
>> |                                                                    |
>> |which makes it easy to (for instance) create appropriate functions  |
>> |"+", "-", "*", "/"."                                                |
>> |--------------------------------------------------------------------|
>>
>> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an
>> example of overloading which Eiffel can perform 
> 
> Since you citing me (incorrectly) and write this:
> 
>> which he claimed that
>> Ada can not manage. 
> 
> Writing a wrong assertion about a book it seems you only read a summary
> made before a term exam, I suggest you get the text you implied you were
> mentioning, specially the four paragraph on page 94 (OOSC 2nd ed.) and
> pay attention to was is *actually* written there.

Not being a fan of identical names for things not overridden
(SPARK avoids this for Ada), the crux is, I think, allowing
REAL into the discussion:

  new_point (p, q: REAL): POINT

First, this is likely a create routine of POINT, REAL does not
affect dispatching, POINT does.  But when a new routine
should make a new point from parameters of some other type,
not REAL, we can, per advice, use a name that differs from
`new_point` .  And then we may refer to the
"principle of non-deception" which will excuse us for not
having, neither in Ada nor in Eiffel, Multiple Dispatch or,
more Ada-like, many controlling parameters (dispatch smells
of run-time things).

And there's the problem, really. (*)

(Not so much in syntactic vs semantic overload, purported to
require dynamic dispatch, which is not the case for Ada
or whenever the compiler can infer the run-time type. I think
that even some SomeDialectOfEiffel has made an attempt in this
direction.)

`new_point` is using an unspecific type REAL.  Something
that we should not do, using Ada.  REAL says little, except
perhaps that the programmers make certain assumptions.
Hopefully, they have augmented their unspecific REAL with a
"require" for `new_point' documenting at least the range of
permissible values or some such.  Now "require" is presented as
the "answer", and means of "non-decpetion" when overriding
does use the same name as the overridden routine. (p.95)
You could call it a workaround, though, for there is a
better solution for method selection than principles.

Still nothing wrong with using numeric types that are not as
vague as REAL.  For example,

  function new_point (p, q: EUCLIDEAN_DISTANCE) return POINT;

New and distinct parameter types (that in general have compile
time and run-time effects, hence are more than nicknames) are
not a perfect solution, because the distinction doesn't work
in all contexts.  But still, I don't understand why a language
design that puts the spot on types (O-O, modules, contracts, ...)
starts coming up with all kinds of selected "principles" and
"answers" when it comes to the lack of O-O in its elementary
types, like INTEGER.  Or maybe it is no good advertising when
one would have to say, too difficult at the time; of the O-O
model as made does not work well with elementary objects;
or some such?


Another, minor, flaw in this discussion is that Meyer, perhaps for
reasons more or less obvious, refers to Ada 83 when he writes
Ada; an exception is �33.7. (Interesting � in itself IMO.)

(*)
package Points is

   type Euclidean_Distance is digits 5 range 0.0 .. 45_000_000.0;

   type Point is tagged private;

   function New_Point(P, Q: Euclidean_Distance) return Point;


   type Near_Point is new Point with private;

   type Neighbourhood_Distance is new Euclidean_Distance
     range 0.0 .. 450.0;

   not overriding
   function New_Point(P, Q: Neighbourhood_Distance)
     return Near_Point;


private
   type Point is tagged record
      X, Y : Euclidean_Distance;
   end record;

   type Near_Point is new Point with record
      Blocks: Boolean;
   end record;
end Points;

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Fri, 24 Jul 2009, Georg Bauhaus wrote:

|------------------------------------------------------------------|
|"[..]                                                             |
|                                                                  |
|Another, minor, flaw in this discussion is that Meyer, perhaps for|
|reasons more or less obvious, refers to Ada 83 when he writes     |
|Ada; [..]                                                         |
|                                                                  |
|[..]"                                                             |
|------------------------------------------------------------------|

Meyer did unfortunately insist on calling Ada 83 "Ada" and Ada 95 "Ada
95", but in that book he called different versions of Objective-C
"Objective-C" and different versions of C++ "C++" and he called a
newer version of Eiffel (which had significant changes from the
original Eiffel) "Eiffel".

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Thu, 23 Jul 2009, Cesar Rabak wrote:

|-------------------------------------------------------------------------------|
|"Colin Paul Gloster escreveu:                                                  |
|> On Wed, 22 Jul 2009, Simon J. Wright wrote:                                  |
|>                                                                              |
|> |--------------------------------------------------------------------|       |
|> |"[..]                                                               |       |
|> |                                                                    |       |
|> |And what will happen to this distinction with Point (2.0, 2.0);?    |       |
|> |                                                                    |       |
|> |You could use named parameter association, but *much* better to use |       |
|> |proper types --                                                     |       |
|> |                                                                    |       |
|> |type Cartesian_Coordinate is record                                 |       |
|> |   X : Metres;                                                      |       |
|> |   Y : Metres;                                                      |       |
|> |end record;                                                         |       |
|> |                                                                    |       |
|> |which makes it easy to (for instance) create appropriate functions  |       |
|> |"+", "-", "*", "/"."                                                |       |
|> |--------------------------------------------------------------------|       |
|>                                                                              |
|> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an         |
|> example of overloading which Eiffel can perform                              |
|                                                                               |
|Since you citing me (incorrectly) and write this:                              |
|                                                                               |
|> which he claimed that                                                        |
|> Ada can not manage.                                                          |
|                                                                               |
|Writing a wrong assertion about a book it seems you only read a summary made   |
|before a term exam, I suggest you get the text you implied you were mentioning,|
|specially the four paragraph on page 94 (OOSC 2nd ed.) and pay attention to was|
|is *actually* written there."                                                  |
|-------------------------------------------------------------------------------|

Nothing by Meyer was ever even mentioned in any of the courses on
which I was enrolled.

The fourth paragraph on Page 94 may be relevant as to whether or not
overloading is a good thing, but it is irrelevant as to what I had
claimed in this thread on this topic (that is, that Ada can perform a
kind of overloading which Meyer claimed that Ada cannot).

I suggest that you flip back a page and note that Page 93 untruthfully
contained:
"[..]

In Ada[83], for example, a package may contain several routines with the same name, as
long as the signatures of these routines are different, where the signature of a routine is
defined here by the number and types of its arguments. (The general notion of signature
also includes the type of the results, if any, but Ada resolves overloading on the basis of
the argument only.) [..]

[..]"

Then you should read the third paragraph of
HTTP://archive.AdaIC.com/standards/83lrm/html/lrm-06-06.html

Furthermore, remind yourself of what you have claimed in
news:h42da2$lcr$1@aioe.org
despite that I had shown that Ada83 can perform overloading in cases
which Meyer said that Ada83 cannot:
|------------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester escreveu:                              |
|[snipped]                                                               |
|                                                                        |
|>                                                                       |
|> I give an example showing that Ada is better than Eiffel (and Modula-3|
|> and many versions of Pascal) in this regard, based on an example by   |
|> Bertrand Meyer in the second edition of the book "Object-oriented     |
|> software construction". In that book, Dr. Meyer claimed that Ada's    |
|> overloading is inferior to Eiffel's overloading. He called Ada's      |
|> overloading syntactic overloading. He called Eiffel's overloading     |
|> semantic overloading. I believe that he was being sincere, but he was |
|> definitely mistaken. He claimed that it would not be possible to      |
|> sensibly discriminate between overloaded subprograms for a point if   |
|> the real-number parameters could be in any of Cartesian notation and  |
|> polar notation.                                                       |
|>                                                                       |
|> This is refuted by the following Ada code...                          |
|>                                                                       |
|Not it's not, your code only changed the problem appearance but not     |
|substance:                                                              |
|                                                                        |
|[..]"                                                                   |
|------------------------------------------------------------------------|



On Thu, 23 Jul 2009, Cesar Rabak wrote:
|-------------------------------------------------------------------------------|
|"> The pseudo-Ada example by Dr. Meyer did not have a                          |
|> record, and a less minor upgrade than adding a record was sufficient         |
|> to show that Dr. Meyer did not know what he was writing about.               |
|                                                                               |
|Yes it did have a record because this perversion of creating a lot of nicknames|
|for solving a problem B. Meyer proposed a different approach."                 |
|-------------------------------------------------------------------------------|

Meyer had on Page 93:
square (x: INTEGER)
square (x: REAL)
square (x: DOUBLE)
square (x: COMPLEX)
and on Page 95:
new_point (p, q: REAL)
so please show me on which page it was explained that INTEGER or REAL
or DOUBLE or COMPLEX is a record.

|-------------------------------------------------------------------------------|
|"[..]                                                                          |
|                                                                               |
|Please keep the discussion on the technical aspects and don't make personal    |
|attacks: they do not add anything to enlightenment for anybody."               |
|-------------------------------------------------------------------------------|

Please practise what you preach. I did not make a personal attack in
this thread. So far as I have seen, in this thread, neither you nor
Wright correctly tackled the issue that Meyer did not know what he was
writing about. Instead, you and Wright posted about what you believed
to be better techniques, which whether they are better or not, do not
excuse Meyer for criticizing Ada83 for not being able to do something
which Ada83 can actually do.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Colin Paul Gloster escreveu:
> On Thu, 23 Jul 2009, Cesar Rabak wrote:
> 
> |-------------------------------------------------------------------------------|
> |"Colin Paul Gloster escreveu:                                                  |
> |> On Wed, 22 Jul 2009, Simon J. Wright wrote:                                  |
> |>                                                                              |
> |> |--------------------------------------------------------------------|       |
> |> |"[..]                                                               |       |
> |> |                                                                    |       |
> |> |And what will happen to this distinction with Point (2.0, 2.0);?    |       |
> |> |                                                                    |       |
> |> |You could use named parameter association, but *much* better to use |       |
> |> |proper types --                                                     |       |
> |> |                                                                    |       |
> |> |type Cartesian_Coordinate is record                                 |       |
> |> |   X : Metres;                                                      |       |
> |> |   Y : Metres;                                                      |       |
> |> |end record;                                                         |       |
> |> |                                                                    |       |
> |> |which makes it easy to (for instance) create appropriate functions  |       |
> |> |"+", "-", "*", "/"."                                                |       |
> |> |--------------------------------------------------------------------|       |
> |>                                                                              |
> |> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an         |
> |> example of overloading which Eiffel can perform                              |
> |                                                                               |
> |Since you citing me (incorrectly) and write this:                              |
> |                                                                               |
> |> which he claimed that                                                        |
> |> Ada can not manage.                                                          |
> |                                                                               |
> |Writing a wrong assertion about a book it seems you only read a summary made   |
> |before a term exam, I suggest you get the text you implied you were mentioning,|
> |specially the four paragraph on page 94 (OOSC 2nd ed.) and pay attention to was|
> |is *actually* written there."                                                  |
> |-------------------------------------------------------------------------------|
> 
> Nothing by Meyer was ever even mentioned in any of the courses on
> which I was enrolled.
> 
> The fourth paragraph on Page 94 may be relevant as to whether or not
> overloading is a good thing, but it is irrelevant as to what I had
> claimed in this thread on this topic (that is, that Ada can perform a
> kind of overloading which Meyer claimed that Ada cannot).
> 

The point is not "overloading" per se, but the specific type of 
overloading Meyer called _syntactic_.

If you think about (getting out of the Ada box) you'll see he has a 
valid point: overload of constructors help very little for the 
*principle of non-deception* he postulates, OTOH having several objects 
(of different types or classes) respond to methods of same name (that do 
the expected thing when operate on these objects) seems sensible to help 
avoiding mistakes and time in maintenance of the code.

> I suggest that you flip back a page and note that Page 93 untruthfully
> contained:
> "[..]
> 
> In Ada[83], for example, a package may contain several routines with the same name, as
> long as the signatures of these routines are different, where the signature of a routine is
> defined here by the number and types of its arguments. (The general notion of signature
> also includes the type of the results, if any, but Ada resolves overloading on the basis of
> the argument only.) [..]

Which is so correct all this thread is about you showing ways to 
circumvent it using nicknames for the types as some of signatures would 
not discriminate between two constructors that were of interest in the 
example problem domain.

> 
> [..]"
> 
> Then you should read the third paragraph of
> HTTP://archive.AdaIC.com/standards/83lrm/html/lrm-06-06.html
> 
> Furthermore, remind yourself of what you have claimed in
> news:h42da2$lcr$1@aioe.org
> despite that I had shown that Ada83 can perform overloading in cases
> which Meyer said that Ada83 cannot:
> |------------------------------------------------------------------------|
> |"Nicholas Paul Collin Gloucester escreveu:                              |
> |[snipped]                                                               |
> |                                                                        |
> |>                                                                       |
> |> I give an example showing that Ada is better than Eiffel (and Modula-3|
> |> and many versions of Pascal) in this regard, based on an example by   |
> |> Bertrand Meyer in the second edition of the book "Object-oriented     |
> |> software construction". In that book, Dr. Meyer claimed that Ada's    |
> |> overloading is inferior to Eiffel's overloading. He called Ada's      |
> |> overloading syntactic overloading. He called Eiffel's overloading     |
> |> semantic overloading. I believe that he was being sincere, but he was |
> |> definitely mistaken. He claimed that it would not be possible to      |
> |> sensibly discriminate between overloaded subprograms for a point if   |
> |> the real-number parameters could be in any of Cartesian notation and  |
> |> polar notation.                                                       |
> |>                                                                       |
> |> This is refuted by the following Ada code...                          |
> |>                                                                       |
> |Not it's not, your code only changed the problem appearance but not     |
> |substance:                                                              |
> |                                                                        |
> |[..]"                                                                   |
> |------------------------------------------------------------------------|

I maintain you changed the appearance by subtyping, which is OK for Ada, 
  but does not address the point the way Ada distinguishes "overloaded" 
constructors is through its signatures (number and types of parameters).

> 
> 
> On Thu, 23 Jul 2009, Cesar Rabak wrote:
> |-------------------------------------------------------------------------------|
> |"> The pseudo-Ada example by Dr. Meyer did not have a                          |
> |> record, and a less minor upgrade than adding a record was sufficient         |
> |> to show that Dr. Meyer did not know what he was writing about.               |
> |                                                                               |
> |Yes it did have a record because this perversion of creating a lot of nicknames|
> |for solving a problem B. Meyer proposed a different approach."                 |
> |-------------------------------------------------------------------------------|

The "it" here is about *your* 'proposed' solution, not Meyer's, which I 
emphasize, suggest a different approach leading to the principle f 
non-deception.

> 
> Meyer had on Page 93:
> square (x: INTEGER)
> square (x: REAL)
> square (x: DOUBLE)
> square (x: COMPLEX)
> and on Page 95:
> new_point (p, q: REAL)
> so please show me on which page it was explained that INTEGER or REAL
> or DOUBLE or COMPLEX is a record.

Again your hasty reading of my posts and Meyer's material is making you 
shooting on the void: no line of my posts said Mayer used records, in 
fact the paragraph that accompanies this code in page 93 is a summary of 
the link for LRM 6.6, the code being an example of it.



> |-------------------------------------------------------------------------------|
> |"[..]                                                                          |
> |                                                                               |
> |Please keep the discussion on the technical aspects and don't make personal    |
> |attacks: they do not add anything to enlightenment for anybody."               |
> |-------------------------------------------------------------------------------|
> 
> Please practise what you preach. I did not make a personal attack in
> this thread. So far as I have seen, in this thread, neither you nor
> Wright correctly tackled the issue that Meyer did not know what he was
> writing about. 

Given LRM says exactly what Meyer wrote, and the only way to 
"circumvent" the "wrong" of the example was to create several new 
'types' (in Ada parlance), but the fundamental issue remains, namely 
that the only way Ada distinguish a call unambiguously is via "...the 
number of parameter associations, the types and the order of the actual 
parameters, the names of the formal parameters (if named associations 
are used), and the result type (for functions)..." (extract from third 
paragraph of LRM 6.6, it seems to me that Meyer knew exactly what he was 
writing about.

> Instead, you and Wright posted about what you believed
> to be better techniques, which whether they are better or not, do not
> excuse Meyer for criticizing Ada83 for not being able to do something
> which Ada83 can actually do.

Which as the extract of the LRM proves to be the contrary, your 
assertion above is wrong and it is non sequitur.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Robert A Duff]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

> I suggest that you flip back a page and note that Page 93 untruthfully
> contained:
> "[..]
>
> In Ada[83], for example, a package may contain several routines with the same name, as
> long as the signatures of these routines are different, where the signature of a routine is
> defined here by the number and types of its arguments. (The general notion of signature
> also includes the type of the results, if any, but Ada resolves overloading on the basis of
> the argument only.) [..]
>
> [..]"

I didn't look up the above quote from Meyer, but assuming he wrote that,
he was mistaken.  Ada DOES use result types to help resolve overloading.
This was true in Ada 83, and it's still true the latest version
(Ada 2005).

Maybe he was thinking of C++ when he wrote that -- last time I looked,
C++ does NOT use result types to help resolve overloading.
I haven't read the latest C++ standard, but I doubt this part
has changed.

Anyway, I wouldn't beat up on Meyer too much over this.  Ada and C++ are
both large languages, and this is a minor mistake.

C++ overload resolution can be done in a single bottom-up pass
over the expression tree.  Ada requires a bottom-up pass followed
by a top-down pass, for exactly this reason (result types
need to be taken into account).

- Bob

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[jimmaureenrogers]

On Jul 24, 3:46 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> I didn't look up the above quote from Meyer, but assuming he wrote that,
> he was mistaken.  Ada DOES use result types to help resolve overloading.
> This was true in Ada 83, and it's still true the latest version
> (Ada 2005).

A modest example follows:
with Ada.Text_Io; use Ada.Text_Io;
with Ada.Numerics.Elementary_Functions; use
Ada.Numerics.Elementary_Functions;

procedure Overload_On_Return_Example is
   function Sqrt(Item : in Float) return Integer is
      Result : Integer;
   begin
      Result := Integer(Float'Rounding(Sqrt(Item)));
      return Result;
   end Sqrt;

   Base_Value : Float := 221.0;
begin
   Put_Line("Floating point square root of" & Float'Image(Base_Value)
      & " is" & Float'Image(Sqrt(Base_Value)));
   Put_Line("Integer square root of" & Float'Image(Base_Value)
      & " is" & Integer'Image(Sqrt(Base_Value)));
end Overload_On_return_Example;

Note that the function Sqrt defined in the example above takes a
floating point argument and returns an integer which is created
from rounding the result of the Sqrt function returning a floating
point number.

The output of this program is:

Floating point square root of 2.21000E+02 is 1.48661E+01
Integer square root of 2.21000E+02 is 15

Clearly, the compiler had to distinguish between the overloaded
Sqrt functions by return type.

Jim Rogers

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak]

Robert A Duff escreveu:
> Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:
> 
>> I suggest that you flip back a page and note that Page 93 untruthfully
>> contained:
>> "[..]
>>
>> In Ada[83], for example, a package may contain several routines with the same name, as
>> long as the signatures of these routines are different, where the signature of a routine is
>> defined here by the number and types of its arguments. (The general notion of signature
>> also includes the type of the results, if any, but Ada resolves overloading on the basis of
>> the argument only.) [..]
>>
>> [..]"
> 
> I didn't look up the above quote from Meyer, but assuming he wrote that,
> he was mistaken.  Ada DOES use result types to help resolve overloading.
> This was true in Ada 83, and it's still true the latest version
> (Ada 2005).
> 

You're right obviously that the result types (a.k.a. return type) is 
used, but for the discussion of constructors of a specific class this is 
moot.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Andrea Taverna wrote:
> Hi folks!
> 
> I'm a CS student and I often need to write number-crunching code dealing
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including general
> solvers.
> 
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
> 
> Here follow the features it should have, ranked approximately by
> relevance:
> 
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard
> or de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"
> 
> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.

I am very surprised at the list of languages you arrived at! FreePascal,
Eiffel and Modula-3 are all essentially dead. Ada is alive but sacrificed
many hugely-productive forms of abstraction (e.g. first-class functions) in
order to be optimally suitable for embedded programming. Unless you're
planning on number crunching on a PIC, which I seriously doubt, Ada would
be a step in the wrong direction.

I specialize in scientific computing and I've never heard of anyone using
any of those languages for it. I doubt any even have efficient
implementations by modern standards.

My vote would certainly go to OCaml. If you allow proprietary then also
OCaml's cousin F# from Microsoft because it offers even better parallelism.
Both of these languages are used extensively for scientific computing.

I would also strongly recommend avoiding conservative garbage collectors
because they leak uncontrollably:

http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 1:25 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
[snip]
> I am very surprised at the list of languages you arrived at! FreePascal,
> Eiffel and Modula-3 are all essentially dead. Ada is alive but sacrificed
> many hugely-productive forms of abstraction (e.g. first-class functions) in
> order to be optimally suitable for embedded programming. Unless you're
> planning on number crunching on a PIC, which I seriously doubt, Ada would
> be a step in the wrong direction.

You take the 'embedded' tag given to Ada too stongly - it's a general
language with very good support for embedded domains (but also
others).

Runtime performance wise, you can usually get something akin to 'C'-
like speed. Switching off all runtime checks and the difference is
(obviously) even smaller.


> I specialize in scientific computing and I've never heard of anyone using
> any of those languages for it. I doubt any even have efficient
> implementations by modern standards.

That's will come as a huge shock to the guys over at NARVAL [http://
www.cs.kuleuven.be/~dirk/ada-belgium/events/09/090207-fosdem/05-narval.pdf]!!!
:-)

In their own words:

   "It is a distributed data acquisition software system
    that collects and processes data from nuclear and
    particles physics detectors. NARVAL replaces an older
    system based on C, Fortran and proprietary technologies
    with Ada and Debian GNU/Linux and is itself Free
    Software."

Sounds pretty scientific to me...and there are plenty others, e.g.
some Astrophysics work [http://homepage.univie.ac.at/martin.stift/].

AdaCore have 150+ universities signed up for the Academic package
offering tools and support for free (beer & speech) [http://
www.adacore.com/home/academia/] - I doubt very many of them are using
PICs!! ;-)

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Martin wrote:
> On Jul 21, 1:25 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> [snip]
>> I am very surprised at the list of languages you arrived at! FreePascal,
>> Eiffel and Modula-3 are all essentially dead. Ada is alive but sacrificed
>> many hugely-productive forms of abstraction (e.g. first-class functions)
>> in order to be optimally suitable for embedded programming. Unless you're
>> planning on number crunching on a PIC, which I seriously doubt, Ada would
>> be a step in the wrong direction.
> 
> You take the 'embedded' tag given to Ada too stongly - it's a general
> language with very good support for embedded domains (but also
> others).
> 
> Runtime performance wise, you can usually get something akin to 'C'-
> like speed. Switching off all runtime checks and the difference is
> (obviously) even smaller.

I do not doubt that. My concern about Ada is primarily that it prohibits
many conventional and hugely-productive mainstream abstractions like
first-class lexical closures. Those are particularly beneficial in the
context of scientific computing.

>> I specialize in scientific computing and I've never heard of anyone using
>> any of those languages for it. I doubt any even have efficient
>> implementations by modern standards.
> 
> That's will come as a huge shock to the guys over at NARVAL [http://
>
www.cs.kuleuven.be/~dirk/ada-belgium/events/09/090207-fosdem/05-narval.pdf]!!!
> :-)
>
> In their own words:
> 
>    "It is a distributed data acquisition software system
>     that collects and processes data from nuclear and
>     particles physics detectors. NARVAL replaces an older
>     system based on C, Fortran and proprietary technologies
>     with Ada and Debian GNU/Linux and is itself Free
>     Software."

In their own words, they are trying to replace a system that is running on
embedded 68k CPUs.

> Sounds pretty scientific to me...and there are plenty others, e.g.
> some Astrophysics work [http://homepage.univie.ac.at/martin.stift/].

Might be interesting to translate some of the examples in those lecture
notes from Ada to a more modern language.

> AdaCore have 150+ universities signed up for the Academic package
> offering tools and support for free (beer & speech) [http://
> www.adacore.com/home/academia/] - I doubt very many of them are using
> PICs!! ;-)

That link says that Ada is:

  "the right choice for courses in elementary programming"

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 3:09 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Martin wrote:
> > On Jul 21, 1:25 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> > [snip]
> >> I am very surprised at the list of languages you arrived at! FreePascal,
> >> Eiffel and Modula-3 are all essentially dead. Ada is alive but sacrificed
> >> many hugely-productive forms of abstraction (e.g. first-class functions)
> >> in order to be optimally suitable for embedded programming. Unless you're
> >> planning on number crunching on a PIC, which I seriously doubt, Ada would
> >> be a step in the wrong direction.
>
> > You take the 'embedded' tag given to Ada too stongly - it's a general
> > language with very good support for embedded domains (but also
> > others).
>
> > Runtime performance wise, you can usually get something akin to 'C'-
> > like speed. Switching off all runtime checks and the difference is
> > (obviously) even smaller.
>
> I do not doubt that. My concern about Ada is primarily that it prohibits
> many conventional and hugely-productive mainstream abstractions like
> first-class lexical closures. Those are particularly beneficial in the
> context of scientific computing.

But I'm afraid it does...20 years ago it didn't.


[snip]
> In their own words, they are trying to replace a system that is running on
> embedded 68k CPUs.

Yes, that's right...and they are replacing them with GNU/Linux
bozes...you didn't read far enough.


> > Sounds pretty scientific to me...and there are plenty others, e.g.
> > some Astrophysics work [http://homepage.univie.ac.at/martin.stift/].
>
> Might be interesting to translate some of the examples in those lecture
> notes from Ada to a more modern language.

There's plenty that's modern about Ada - it did multi-core natively
and portably long before the current flavour-of-the-month boys came to
the party.

The one thing that is missing is lambda support but that doesn't
bother me to much given the sort of domains I work in. I think I heard
it was being considered for the next language revision.


> > AdaCore have 150+ universities signed up for the Academic package
> > offering tools and support for free (beer & speech) [http://
> >www.adacore.com/home/academia/] - I doubt very many of them are using
> > PICs!! ;-)
>
> That link says that Ada is:
>
>   "the right choice for courses in elementary programming"

Nothing wrong with that - it's also very well suited to intermediate
and advanced programming.

I've nothing against functional languages (my thesis used SML/
NJ)...but I'm afraid your making assertions about Ada that just aren't
true...

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 2:41 pm, Martin <martin.do...@btopenworld.com> wrote:
> There's plenty that's modern about Ada - it did multi-core natively
> and portably long before the current flavour-of-the-month boys came to
> the party.

I'll also add to the list of 'modern' features...full OO-support for
tasks (i.e. lightweight threads) - I don't know of any other language
that can say that.

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Tue, 21 Jul 2009 06:41:28 -0700 (PDT), Martin wrote:

> I've nothing against functional languages (my thesis used SML/
> NJ)...but I'm afraid your making assertions about Ada that just aren't
> true...

Huh, there is nothing wrong in criticizing functional abstractions like
first-class functions etc, or at least in questioning whether a primitive
operation should be considered an object and in which sense exactly. I have
my reservations about functionality of functional abstractions. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Martin wrote:
> On Jul 21, 3:09 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> I do not doubt that. My concern about Ada is primarily that it prohibits
>> many conventional and hugely-productive mainstream abstractions like
>> first-class lexical closures. Those are particularly beneficial in the
>> context of scientific computing.
> 
> But I'm afraid it does...20 years ago it didn't.

Not according to John Barnes' "Rationale for Ada 2005":

  http://www.adaic.org/standards/05rat/html/Rat-3-4.html

> [snip]
>> In their own words, they are trying to replace a system that is running
>> on embedded 68k CPUs.
> 
> Yes, that's right...and they are replacing them with GNU/Linux
> bozes...you didn't read far enough.

If they are still running on embedded 68k CPUs then it cannot be very
computationally intensive work by today's standards. They seem to be just
gathering a not-huge amount of data which is neither interesting nor
relevant in this context.

>> > Sounds pretty scientific to me...and there are plenty others, e.g.
>> > some Astrophysics work [http://homepage.univie.ac.at/martin.stift/].
>>
>> Might be interesting to translate some of the examples in those lecture
>> notes from Ada to a more modern language.
> 
> There's plenty that's modern about Ada - it did multi-core natively
> and portably long before the current flavour-of-the-month boys came to
> the party.

Fortran did parallelism before Ada and the current "flavour-of-the-month
boys" like Cilk and .NET 4 provide modern solutions for parallelism built
upon wait-free work-stealing concurrent deques that Ada not only does not
have but cannot even express.

> The one thing that is missing is lambda support but that doesn't
> bother me to much given the sort of domains I work in. I think I heard
> it was being considered for the next language revision.

What do you mean by "lambda support" if not first-class lexical closures?

>> > AdaCore have 150+ universities signed up for the Academic package
>> > offering tools and support for free (beer & speech) [http://
>> >www.adacore.com/home/academia/] - I doubt very many of them are using
>> > PICs!! ;-)
>>
>> That link says that Ada is:
>>
>> "the right choice for courses in elementary programming"
> 
> Nothing wrong with that - it's also very well suited to intermediate
> and advanced programming.

In the embedded space, perhaps.

> I've nothing against functional languages (my thesis used SML/
> NJ)...but I'm afraid your making assertions about Ada that just aren't
> true...

Not according to the latest Ada specification, AFAICT.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Jon Harrop schrieb:
> Martin wrote:
>> On Jul 21, 3:09 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>> I do not doubt that. My concern about Ada is primarily that it prohibits
>>> many conventional and hugely-productive mainstream abstractions like
>>> first-class lexical closures. Those are particularly beneficial in the
>>> context of scientific computing.
>> But I'm afraid it does...20 years ago it didn't.
> 
> Not according to John Barnes' "Rationale for Ada 2005":
> 
>   http://www.adaic.org/standards/05rat/html/Rat-3-4.html

Chris Okasaki has an entertaining assessment of functional
programming in Ada 2005:
http://okasaki.blogspot.com/2008/07/functional-programming-inada.html

(What one can't do (really) is pass an environment up the call
chain...)

But why not show or point to some striking example of what
is possible to achieve, result-wise, in number-crunching or
scientific computing with full "closures" that is demonstrably
difficult or cumbersome to do using generics, downward "closures"
and objects only.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Georg Bauhaus wrote:
> Chris Okasaki has an entertaining assessment of functional
> programming in Ada 2005:
> http://okasaki.blogspot.com/2008/07/functional-programming-inada.html

Right. I had read that before...

> But why not show or point to some striking example of what
> is possible to achieve, result-wise, in number-crunching or
> scientific computing with full "closures" that is demonstrably
> difficult or cumbersome to do using generics, downward "closures"
> and objects only.

Currying and, therefore, partial application are the most obvious examples.

I recently wrote an F# implementation of QR decomposition that is up to 3x
faster than the Intel MKL (!). I first wrote it with explicit copies. Then
I rephrased it to index everything via functions (making heavy use of
partial application) rather than explicit data structures (creating "views"
of the matrix without copying it). Then I rearranged those to make them
more cache coherent and finally introduced parallelism.

There is a brief description here:

http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-qr-decomposition.html

Moreover, my implementation is parameterized over its element type and
operations so it can be applied to single or double precision or even
symbolic matrices.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Jon Harrop schrieb:

> I recently wrote an F# implementation of QR decomposition that is up to 3x
> faster than the Intel MKL (!). I first wrote it with explicit copies. Then
> I rephrased it to index everything via functions (making heavy use of
> partial application) rather than explicit data structures (creating "views"
> of the matrix without copying it). Then I rearranged those to make them
> more cache coherent and finally introduced parallelism.
> 
> There is a brief description here:
> 
> http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-qr-decomposition.html
> 
> Moreover, my implementation is parameterized over its element type and
> operations so it can be applied to single or double precision or even
> symbolic matrices.

Interesting example, thank you.

BTW, readers interested in "state of the art" concurrent
and parallel algorithms in ISO-languages or other languages
might want to be made aware of the patent situation of
some of the technology required,

http://www.patents.com/Dynamic-circular-work-stealing-deque/US7346753/en-US/
http://www.freepatentsonline.com/7346753.html
http://www.wikipatents.com/7346753.html

etc.


-- 
--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 5:06 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Martin wrote:
> > On Jul 21, 3:09 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> > But I'm afraid it does...20 years ago it didn't.
>
> Not according to John Barnes' "Rationale for Ada 2005":
>
>  http://www.adaic.org/standards/05rat/html/Rat-3-4.html

The first part of this shows how they weren't...read on and it shows
that have been added (anonymous access types) to provide downward
closures (what I took from "first-class lexical closures").



> > Yes, that's right...and they are replacing them with GNU/Linux
> > bozes...you didn't read far enough.
>
> If they are still running on embedded 68k CPUs then it cannot be very
> computationally intensive work by today's standards. They seem to be just
> gathering a not-huge amount of data which is neither interesting nor
> relevant in this context.

No - they are Intel/Linux boxes (GNAT GPL 2007 is Intel only), not PPC
and they gather _and_ process the data (the FORTRAN bit they are
replacing).

I didn't realise there was a size threshold before something became
"interesting" :-)

I have no idea how much data they are collecting / processing but it's
certainly relevant - your claim was you had "never heard of anyone
using any of those languages for it" ('it' being scientific computing)
and I've provided an example, so now you have.


> > There's plenty that's modern about Ada - it did multi-core natively
> > and portably long before the current flavour-of-the-month boys came to
> > the party.
>
> Fortran did parallelism before Ada and the current "flavour-of-the-month
> boys" like Cilk and .NET 4 provide modern solutions for parallelism built
> upon wait-free work-stealing concurrent deques that Ada not only does not
> have but cannot even express.

Yes, their were other pre-Ada concurrent languages - just shows how
modern Ada is! ;-)

I don't use .NET but there's certainly Ada support for it (A# as it
was called, now available from https://libre.adacore.com/libre/). If
it's built into .NET then I don't see any reason why support couldn't
be added. Does .NET offer different task scheduling policies? Or do
you just 'get what's implemented'? There are 4 tasking policies
already defined in Ada and implementations are free to add others:

  pragma Tasking_Dispatch_Policy
(Wait_Free_Work_Stealing_Concurrent_Deques);

...doesn't exactly trip off the tongue but that's it expressed...

Or if you're refering to the work by Chase & Lev @ Sun, then they
implemented it in C++. As far as I know there is nothing you can
implement in C++ that you can't in Ada (or many other languages) and
visa-versa, so it could be added as an external library (akin to
replacing the built in language 'task' keyword with library calls as
you do when using an ARINC-653 supporting OS).


> > The one thing that is missing is lambda support but that doesn't
> > bother me to much given the sort of domains I work in. I think I heard
> > it was being considered for the next language revision.
>
> What do you mean by "lambda support" if not first-class lexical closures?

Ada only supports downward closures not full blown lambda expressions
or functions - that really is the domain of the functional languages
(or TMP).

I can't write unnamed functions, e.g. classic C++ Boost example:

   for_each(a.begin(), a.end(), std::cout << _1 << ' ');
                                ^^^^^^^^^^^^^^^^^^^^^^
                                   unnamed function

I'd have to wrap that in a function in Ada to a pass that (named)
function. I can't return an unnamed function in Ada either. It's just
downwards. But that's a whole lot more that the original Ada83 spec,
which expected you to use generic (template) functions instead. Do-
able but a lot more effort.

I believe there is work on adding some sort of unnamed function
support to a future language revision.


> >> "the right choice for courses in elementary programming"
>
> > Nothing wrong with that - it's also very well suited to intermediate
> > and advanced programming.
>
> In the embedded space, perhaps.

Not just embedded - it's a general purpose language but it certainly
isn't functional. Most of my Ada work isn't embedded at all these
days...usually console apps.

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Martin wrote:
> On Jul 21, 5:06 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Martin wrote:
>> > On Jul 21, 3:09 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> > But I'm afraid it does...20 years ago it didn't.
>>
>> Not according to John Barnes' "Rationale for Ada 2005":
>>
>>  http://www.adaic.org/standards/05rat/html/Rat-3-4.html
> 
> The first part of this shows how they weren't...read on and it shows
> that have been added (anonymous access types) to provide downward
> closures (what I took from "first-class lexical closures").

No, it explicitly states that Ada still has only downward closures and not
first-class lexical closures.

My assertion about Ada was exactly correct: they sacrificed
hugely-productive features for embedded apps.

>> > Yes, that's right...and they are replacing them with GNU/Linux
>> > bozes...you didn't read far enough.
>>
>> If they are still running on embedded 68k CPUs then it cannot be very
>> computationally intensive work by today's standards. They seem to be just
>> gathering a not-huge amount of data which is neither interesting nor
>> relevant in this context.
> 
> I didn't realise there was a size threshold before something became
> "interesting" :-)

If the context is high-performance computing then work being done on 68k
CPUs today is irrelevant.

>> > There's plenty that's modern about Ada - it did multi-core natively
>> > and portably long before the current flavour-of-the-month boys came to
>> > the party.
>>
>> Fortran did parallelism before Ada and the current "flavour-of-the-month
>> boys" like Cilk and .NET 4 provide modern solutions for parallelism built
>> upon wait-free work-stealing concurrent deques that Ada not only does not
>> have but cannot even express.
> 
> Yes, their were other pre-Ada concurrent languages - just shows how
> modern Ada is! ;-)
> 
> I don't use .NET but there's certainly Ada support for it (A# as it
> was called, now available from https://libre.adacore.com/libre/). If
> it's built into .NET then I don't see any reason why support couldn't
> be added. Does .NET offer different task scheduling policies? Or do
> you just 'get what's implemented'? There are 4 tasking policies
> already defined in Ada and implementations are free to add others:
> 
>   pragma Tasking_Dispatch_Policy
> (Wait_Free_Work_Stealing_Concurrent_Deques);
> 
> ...doesn't exactly trip off the tongue but that's it expressed...
> 
> Or if you're refering to the work by Chase & Lev @ Sun, then they
> implemented it in C++. As far as I know there is nothing you can
> implement in C++ that you can't in Ada (or many other languages) and
> visa-versa, so it could be added as an external library (akin to
> replacing the built in language 'task' keyword with library calls as
> you do when using an ARINC-653 supporting OS).

Atomic intrinsics are an obvious counter example.

>> > The one thing that is missing is lambda support but that doesn't
>> > bother me to much given the sort of domains I work in. I think I heard
>> > it was being considered for the next language revision.
>>
>> What do you mean by "lambda support" if not first-class lexical closures?
> 
> Ada only supports downward closures not full blown lambda expressions
> or functions - that really is the domain of the functional languages
> (or TMP).
> 
> I can't write unnamed functions, e.g. classic C++ Boost example:
> 
>    for_each(a.begin(), a.end(), std::cout << _1 << ' ');
>                                 ^^^^^^^^^^^^^^^^^^^^^^
>                                    unnamed function
> 
> I'd have to wrap that in a function in Ada to a pass that (named)
> function. I can't return an unnamed function in Ada either. It's just
> downwards. But that's a whole lot more that the original Ada83 spec,
> which expected you to use generic (template) functions instead. Do-
> able but a lot more effort.
> 
> I believe there is work on adding some sort of unnamed function
> support to a future language revision.

So Ada not only lacks first-class lexical closures but it doesn't even have
anonymous functions. Even C# has both of those features now.

>> >> "the right choice for courses in elementary programming"
>>
>> > Nothing wrong with that - it's also very well suited to intermediate
>> > and advanced programming.
>>
>> In the embedded space, perhaps.
> 
> Not just embedded - it's a general purpose language but it certainly
> isn't functional.

Right.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Robert A Duff]

Martin <martin.dowie@btopenworld.com> writes:

> On Jul 21, 3:09�pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> I do not doubt that. My concern about Ada is primarily that it prohibits
>> many conventional and hugely-productive mainstream abstractions like
>> first-class lexical closures. Those are particularly beneficial in the
>> context of scientific computing.
>
> But I'm afraid it does...20 years ago it didn't.

No, that's not quite right.  Ada 2005 does not have "first-class lexical
closures", as Jon said.  Ada has "downward closures" (sometimes called
"inward closures").  In Ada, you can pass a nested function to a
non-nested function.  You cannot return a nested function from the
function containing it.  Both are required, to make them "first class"
(or "full closures"), as in OCaml, Lisp, Haskell, etc.

I'd say downward closures give you at least 80% of what one might want
from closures.

Unfortunately, the syntax for downward closures is pretty awful
in Ada, compared to (e.g.) OCaml.  There are proposals to make
it better in the next version of Ada.  It is unlikely that the
next version of Ada will have full closures.  (Of course, you can
always simulate full closures in Ada, using tagged and class-wide
types, but it can get pretty ugly.)

I'd still choose Ada over OCaml for what the OP wants to do.
E.g. Ada's ability to have multiple user-defined integer
types seems like a trivial thing, but in practice it is
hugely beneficial.

For example, suppose I have an array containing indices into another
array.  Using a different index type for the two arrays makes the code
clear -- when I see an integer variable, I can immediately tell from
its type which array it is intended to index.

Both OCaml and Ada are pretty good language designs -- far better than
some of the more popular languages.  Both have advantages and
disadvantages.

I would not choose any version/dialect of Pascal or Modula for anything,
these days.  Ada is strictly better.

Eiffel is a nice language design, but suffers from some other problems.
By the way, some of the "design by contract" stuff from Eiffel has
already been implemented in GNAT (the free-software Ada compiler),
and even more is being considered for the next version of Ada.

>> > Sounds pretty scientific to me...and there are plenty others, e.g.
>> > some Astrophysics work [http://homepage.univie.ac.at/martin.stift/].
>>
>> Might be interesting to translate some of the examples in those lecture
>> notes from Ada to a more modern language.

Jon, why do you use "modern" to mean "good"?  They are not synonymous!
For example, closures are good, but they were invented a long
time ago -- they're certainly not "modern".

If you said, "Might be interesting to translate some of the examples in
those lecture notes from Ada to a language with full closures", then
I'd agree -- it would be interesting indeed.

- Bob

P.S. You should know my potential biases:  I was heavily involved in the
design of Ada 95, and somewhat involved in the design of Ada 2005,
and continue to be somewhat involved in the ongoing design of the
next version.  And I currently work for AdaCore.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
> I am very surprised at the list of languages you arrived at! FreePascal,
> Eiffel and Modula-3 are all essentially dead.

I don't think so. FP seems to have a pretty alive community, GOBO
libraries seem to be actively updated. I can't confirm for M3, but its
supporters seem to be "alive and kicking".
Anyway, you're hitting me where it hurts.
Perhaps I'm just clueless, or childish, but I just can't stand this
situation. The more I learn, the more I feel that something went wrong
in the "language war" in the '80, and this leaves a bad tastes in my
mouth. It may be ridiculous since I was a child when that "war" took
place.
Nevertheless, I  can't do anything but note that the languages above
got something right that modern mainstream languages haven't yet.

> I would also strongly recommend avoiding conservative garbage collectors
> because they leak uncontrollably:

Thanks for the tip.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

A link from my old book marks, which may be of interest to someone:
http://www.christ-usch-grein.homepage.t-online.de/Ada/Universe.html

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Hibou57 (Yannick Duchêne)]

On 21 juil, 16:12, Andrea Taverna <a.t...@hotmail.it> wrote:
> On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
>
> > I am very surprised at the list of languages you arrived at! FreePascal,
> > Eiffel and Modula-3 are all essentially dead.
>
> I don't think so. FP seems to have a pretty alive community, GOBO
> libraries seem to be actively updated. I can't confirm for M3, but its
> supporters seem to be "alive and kicking".
All of these three are still alive. I know for FreePascal (alias the
old FPK), althought it is a bit too much buggy in my opinion. I know
for Eiffel as a big part on Eiffel research is done in a town not very
far from where I leave (there is the Loria, at Nancy [france]), and
Modula-3 is still evolving, as it was first Modula, then Modula-2,
then Modula-3 and there was Oberon which came from Modula.

If sometimes peoples feel one of these is not alive anymore, this is I
think beceause each of its users are leaving on there own island and
most of time do not know about what is going on, on other islands.

All of these, with also by the way, Ada, Prolog and derivatives, Lisp
and derivatises, and two or three others (I forgot their names), are
stil living. Most of them beceause they rely on a good theory (except
FreePascal perhaps) and will continue to live for long.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mark T.B. Carroll]

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:
(snip)
> Modula-3 is still evolving, as it was first Modula, then Modula-2,
> then Modula-3 and there was Oberon which came from Modula.
>
> If sometimes peoples feel one of these is not alive anymore, this is I
> think beceause each of its users are leaving on there own island and
> most of time do not know about what is going on, on other islands.

Wow, that's amazing. I stopped using Modula-3 in the late 90's when it
seemed to be dying under me; finally moving over to Java (probably in
2000) was something of a disappointment that I posted complaints about
at the time (where's GENERIC? where's TYPECASE? etc., etc.). I'd still
sometimes be using it now if I really ever saw much life in, say,
comp.lang.modula3 where this thread is going. Debian hasn't even carried
pm3 for years. It must be quite a remote little island: are they
positively trying to avoid being a victim of success or something? I
pray that you're correct - I actually kept my Modula-3 books (have /any/
been in print for years?) and would be using it sometimes now if I
thought there were more than a handful of others doing likewise.

[ followups trimmed ]

Mark

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Andrea Taverna wrote:
> On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
>> I am very surprised at the list of languages you arrived at! FreePascal,
>> Eiffel and Modula-3 are all essentially dead.
> 
> I don't think so.

F# is still pretty obscure so look at this trend of FreePascal vs F# by
Google searches:

  http://www.google.com/trends?q=freepascal%2Cf%23

> FP seems to have a pretty alive community, GOBO 
> libraries seem to be actively updated. I can't confirm for M3, but its
> supporters seem to be "alive and kicking".

I was taught Modula-3 as an undergrad 13 years ago and have not seen it
since.

> Anyway, you're hitting me where it hurts.
> Perhaps I'm just clueless, or childish, but I just can't stand this
> situation. The more I learn, the more I feel that something went wrong
> in the "language war" in the '80, and this leaves a bad tastes in my
> mouth. It may be ridiculous since I was a child when that "war" took
> place.

Well, you do seem to be picking all of the languages that lost the war. ;-)

> Nevertheless, I  can't do anything but note that the languages above
> got something right that modern mainstream languages haven't yet.

Mainstream languages are for business apps and web programming so they do
not have the qualities that you are looking for.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 21, 5:10 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Andrea Taverna wrote:
> > On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> I am very surprised at the list of languages you arrived at! FreePascal,
> >> Eiffel and Modula-3 are all essentially dead.
>
> > I don't think so.
>
> F# is still pretty obscure so look at this trend of FreePascal vs F# by
> Google searches:
>
>  http://www.google.com/trends?q=freepascal%2Cf%23

Unfortunately that picks up a lot of swear-word replacements, as in
"what the f#@$!" and for some reason a heck of a lot of asian
financial pages!!!

Same goes for a straight Google search...

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Martin wrote:
> On Jul 21, 5:10 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Andrea Taverna wrote:
>> > On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
>> >> I am very surprised at the list of languages you arrived at!
>> >> FreePascal, Eiffel and Modula-3 are all essentially dead.
>>
>> > I don't think so.
>>
>> F# is still pretty obscure so look at this trend of FreePascal vs F# by
>> Google searches:
>>
>> http://www.google.com/trends?q=freepascal%2Cf%23
> 
> Unfortunately that picks up a lot of swear-word replacements, as in
> "what the f#@$!" and for some reason a heck of a lot of asian
> financial pages!!!

Before 2004, Google Trends registered nothing for F#. If you look at the
trend, it correlates very strongly with F# releases and major
announcements. It is an accurate measure of people searching for the F#
programming language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 21 Jul., 16:12, Andrea Taverna <a.t...@hotmail.it> wrote:
> On 21 Lug, 14:25, Jon Harrop <j...@ffconsultancy.com> wrote:
>
> > I am very surprised at the list of languages you arrived at! FreePascal,
> > Eiffel and Modula-3 are all essentially dead.
>
> I don't think so. FP seems to have a pretty alive community, GOBO
> libraries seem to be actively updated. I can't confirm for M3, but its
> supporters seem to be "alive and kicking".
> Anyway, you're hitting me where it hurts.
> Perhaps I'm just clueless, or childish, but I just can't stand this
> situation. The more I learn, the more I feel that something went wrong
> in the "language war" in the '80, and this leaves a bad tastes in my
> mouth. It may be ridiculous since I was a child when that "war" took
> place.
> Nevertheless, I  can't do anything but note that the languages above
> got something right that modern mainstream languages haven't yet.

Simplicity of languages and their implementation got lost somehow.
Just because it is possible to write a parser (or compiler) for a
language construct does not make it a good design decision. Many
features get added to languages by a committee and thinking about
parsing and implementing them starts much later (by different
persons which did not have a chance to attend).

Defining language constructs should not be seen as challenge for
compiler/interpreter writers: "Hey lets see if the compiler writers
are capable to implement this construct". Such thinking leads to
unnecessary complex languages.

Parsing with LL(1) and recursive descend parsing has advantages.
It leads to simpler language constructs which are (when done right)
also easier to read for humans.

Seed7 allows the programmer to introduce new language constructs.
Given my criticism towards committee designs this seems to be the
wrong direction. But extending Seed7 is done in the scope of LL(1),
recursive descend parsing and static typing. There are precise
rules how the syntax of Seed7 can be extended. See:

http://seed7.sourceforge.net/manual/syntax.htm

When a programmer introduces a new construct to Seed7 he/she should
implement it also.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

tm wrote:
> Simplicity of languages and their implementation got lost somehow...

The F# team at Microsoft used to advertise that their compiler was under
10kLOC.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Jon Harrop schrieb:
> tm wrote:
>> Simplicity of languages and their implementation got lost somehow...
> 
> The F# team at Microsoft used to advertise that their compiler was under
> 10kLOC.
> 

Did they advertise whether their F# compiler did a bit more
than delegate its work to MS's common compilation infrastructure?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Georg Bauhaus wrote:
> Jon Harrop schrieb:
>> tm wrote:
>>> Simplicity of languages and their implementation got lost somehow...
>> 
>> The F# team at Microsoft used to advertise that their compiler was under
>> 10kLOC.
> 
> Did they advertise whether their F# compiler did a bit more
> than delegate its work to MS's common compilation infrastructure?

F# obviously reuses a lot of technology from the CLR but it includes its own
efficient implementation of curried functions, variant types, pattern
matching, asynchronous workflows, units of measure, inlined functions and
many other features not provided by the CLR.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 24 Jul., 11:31, Jon Harrop <j...@ffconsultancy.com> wrote:
> tm wrote:
> > Simplicity of languages and their implementation got lost somehow...
>
> The F# team at Microsoft used to advertise that their compiler was under
> 10kLOC.

Is is possible to verify this claim?
Is the F# compiler released as open source?
Is it available on "all" operating systems?
What about the (guessed) 100MB DLLs which are used?
Do you trust a quasi monopolist?

You may have your reasons to push F# all the time, but
there are also open questions (see above).

I also think that it is not a good idea to use a language
dominated by a big company.

Seed7 is not owned by a company. Instead it is released as
open source. You can look how the features are implemented
and everybody is invited to join the project.

BTW: Seed7 has different goals than F# and its philosophy is
more close to what the OP is interested in.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

tm wrote:
> On 24 Jul., 11:31, Jon Harrop <j...@ffconsultancy.com> wrote:
>> tm wrote:
>> > Simplicity of languages and their implementation got lost somehow...
>>
>> The F# team at Microsoft used to advertise that their compiler was under
>> 10kLOC.
> 
> Is is possible to verify this claim?
> Is the F# compiler released as open source?

The source code is freely available under a non-OSS licence.

> Is it available on "all" operating systems?

It is supposed to run on compliant VMs like Mono but Mono is not good enough
to run it reliably yet.

> What about the (guessed) 100MB DLLs which are used?

Even the F# Power Pack (which includes things like linear algebra) is only
1Mb more.

> Do you trust a quasi monopolist?

I would not gamble solely on them.

> I also think that it is not a good idea to use a language
> dominated by a big company.

I don't have a problem with using that among lots of other languages (we
also use C#, OCaml, C, C++ and Mathematica).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tm]

On 24 Jul., 15:11, Jon Harrop <j...@ffconsultancy.com> wrote:
> tm wrote:
> > On 24 Jul., 11:31, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> tm wrote:
> >> > Simplicity of languages and their implementation got lost somehow...
>
> >> The F# team at Microsoft used to advertise that their compiler was under
> >> 10kLOC.
>
> > Is is possible to verify this claim?
> > Is the F# compiler released as open source?
>
> The source code is freely available under a non-OSS licence.

That means: The F# compiler is NOT released as open source.

> > Is it available on "all" operating systems?
>
> It is supposed to run on compliant VMs like Mono but Mono is not good enough
> to run it reliably yet.

That means: F# can only run "reliable" under M$ Windows.

> > What about the (guessed) 100MB DLLs which are used?
>
> Even the F# Power Pack (which includes things like linear algebra) is only
> 1Mb more.

Since .NET is needed you probably need much more than 1Mb.

> > Do you trust a quasi monopolist?
>
> I would not gamble solely on them.

So you should refuse M$ only programming languages.

> > I also think that it is not a good idea to use a language
> > dominated by a big company.
>
> I don't have a problem with using that among lots of other languages (we
> also use C#, OCaml, C, C++ and Mathematica).

Try Seed7. It is portable, open source and not dominated by
a big company. I am sure Seed7 is not perfect, but it
can be improved without being hampered by licenses or
company politics.

Feedback about Seed7, its documentation and its homepage
is always welcome.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

tm wrote:
> On 24 Jul., 15:11, Jon Harrop <j...@ffconsultancy.com> wrote:
>> tm wrote:
>> > On 24 Jul., 11:31, Jon Harrop <j...@ffconsultancy.com> wrote:
>> >> tm wrote:
>> >> > Simplicity of languages and their implementation got lost somehow...
>>
>> >> The F# team at Microsoft used to advertise that their compiler was
>> >> under 10kLOC.
>>
>> > Is is possible to verify this claim?
>> > Is the F# compiler released as open source?
>>
>> The source code is freely available under a non-OSS licence.
> 
> That means: The F# compiler is NOT released as open source.

Yes.

>> > Is it available on "all" operating systems?
>>
>> It is supposed to run on compliant VMs like Mono but Mono is not good
>> enough to run it reliably yet.
> 
> That means: F# can only run "reliable" under M$ Windows.

Yes.

>> > What about the (guessed) 100MB DLLs which are used?
>>
>> Even the F# Power Pack (which includes things like linear algebra) is
>> only 1Mb more.
> 
> Since .NET is needed you probably need much more than 1Mb.

Sure. Seed7 probably needs libc which is >1Mb too.

>> > Do you trust a quasi monopolist?
>>
>> I would not gamble solely on them.
> 
> So you should refuse M$ only programming languages.

Why?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[wwilson]

On Fri, 24 Jul 2009 05:31:45 -0400, Jon Harrop <jon@ffconsultancy.com>  
wrote:

> tm wrote:
>> Simplicity of languages and their implementation got lost somehow...
>
> The F# team at Microsoft used to advertise that their compiler was under
> 10kLOC.
>


Am I the only one that remembers when computers came with a maximum of a  
few kbytes.  I personally know of one full FORTRAN IV compiler for the IBM  
1130 that fit into 8 K bytes.  My favorite programming feat was the way  
that IBM squeezed a whole COBOL compiler into 1400 bytes on the IBM 1401.

The much later PDP 11 came with a max of 64 kbites.  This was a popular  
machine and whole organizations managed to get by using it.  If you're not  
familar with the PDP 11, C is a structured assembly language for it and  
the original commercial versions of UNIX were developed on this machine.

In short: Program bloat is not new.  The pioneers of computing managed  
with amounts of memory that seem unbelievable by todays standards.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[robertwessel2]

On Jul 24, 8:15 pm, wwilson <leon.wins...@notes.udayton.edu> wrote:
> On Fri, 24 Jul 2009 05:31:45 -0400, Jon Harrop <j...@ffconsultancy.com>  
> wrote:
>
> > tm wrote:
> >> Simplicity of languages and their implementation got lost somehow...
>
> > The F# team at Microsoft used to advertise that their compiler was under
> > 10kLOC.
>
> Am I the only one that remembers when computers came with a maximum of a  
> few kbytes.  I personally know of one full FORTRAN IV compiler for the IBM  
> 1130 that fit into 8 K bytes.  My favorite programming feat was the way  
> that IBM squeezed a whole COBOL compiler into 1400 bytes on the IBM 1401.


While it’s true that compilers of that era ran in very small amounts
of memory, they often ran very many passes, the code for each of which
was loaded sequentially, and much use was made of temporary files to
hold intermediate transformations of the program being compiled.  Some
compilers used upwards of 20 passes (which wasn't great for
compilation speeds either).  The compilers were in fact much larger
than could fit in memory (at least on the smaller machines), they just
arranged things so that it didn't all need to be loaded at once.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dmitry A. Kazakov]

On Fri, 24 Jul 2009 23:05:03 -0700 (PDT), robertwessel2@yahoo.com wrote:

> On Jul 24, 8:15οΏ½pm, wwilson <leon.wins...@notes.udayton.edu> wrote:
>> On Fri, 24 Jul 2009 05:31:45 -0400, Jon Harrop <j...@ffconsultancy.com> οΏ½
>> wrote:
>>
>>> tm wrote:
>>>> Simplicity of languages and their implementation got lost somehow...
>>
>>> The F# team at Microsoft used to advertise that their compiler was under
>>> 10kLOC.
>>
>> Am I the only one that remembers when computers came with a maximum of a οΏ½
>> few kbytes. οΏ½I personally know of one full FORTRAN IV compiler for the IBM οΏ½
>> 1130 that fit into 8 K bytes. οΏ½My favorite programming feat was the way οΏ½
>> that IBM squeezed a whole COBOL compiler into 1400 bytes on the IBM 1401.
> 
> While itοΏ½s true that compilers of that era ran in very small amounts
> of memory, they often ran very many passes, the code for each of which
> was loaded sequentially, and much use was made of temporary files to
> hold intermediate transformations of the program being compiled.  Some
> compilers used upwards of 20 passes (which wasn't great for
> compilation speeds either).  The compilers were in fact much larger
> than could fit in memory (at least on the smaller machines), they just
> arranged things so that it didn't all need to be loaded at once.

Yes, PDP-11 OS RSX-11M supported memory overlays which were actively used.
However it didn't take 20 passes to compile FORTRAN IV. The compiler was
extremely fast, much faster than the linker (TKB). Indeed I remember a C
compiler (not from DEC) and an Ada 83 compiler (incomplete) for RSX-11
which used 6 passes, or so. But they were rather purely designed.

Back to the point, let us not forget another limit, the hard drive DK for
PDP-11 was 2.5MB. So all overlays should have fit into that. The FORTRAN
compiler, the linker, the text editor (EDT) and the OS kernel together fit
there. Incredible!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[wwilson]

On Sat, 25 Jul 2009 02:05:03 -0400, robertwessel2@yahoo.com  
<robertwessel2@yahoo.com> wrote:

> On Jul 24, 8:15 pm, wwilson <leon.wins...@notes.udayton.edu> wrote:
>> On Fri, 24 Jul 2009 05:31:45 -0400, Jon Harrop <j...@ffconsultancy.com>  
>>  
>> wrote:
>>
>> > tm wrote:
>> >> Simplicity of languages and their implementation got lost somehow...
>>
>> > The F# team at Microsoft used to advertise that their compiler was  
>> under
>> > 10kLOC.
>>
>> Am I the only one that remembers when computers came with a maximum of  
>> a  
>> few kbytes.  I personally know of one full FORTRAN IV compiler for the  
>> IBM  
>> 1130 that fit into 8 K bytes.  My favorite programming feat was the way  
>>  
>> that IBM squeezed a whole COBOL compiler into 1400 bytes on the IBM  
>> 1401.
>
>
> While it’s true that compilers of that era ran in very small amounts
> of memory, they often ran very many passes, the code for each of which
> was loaded sequentially, and much use was made of temporary files to
> hold intermediate transformations of the program being compiled.  Some
> compilers used upwards of 20 passes (which wasn't great for
> compilation speeds either).  The compilers were in fact much larger
> than could fit in memory (at least on the smaller machines), they just
> arranged things so that it didn't all need to be loaded at once.


Hey,its nice to find somebody who remembers when men were men and  
programmers where gods who walked on the earth.

You are right that in many cases the compilers used multiple passes.  If I  
remmeber correctly, the COBOL compiler for the IBM 1401 used 28 passes.   
But this still meant that the compiler fit in 28*1.4 Kbytes (=39.4 kbytes)  
A remarkable feat.

On the other hand, the FORTRAN compiler that I refered to was developed  
for student use.  It remained in the lower half of memory and the compiler  
put code into the upper half.  The compiler was loaded followed by a stack  
of student jobs which the compiler processed one after the other. (Forward  
references were put into a table and cleaned up after the compiler loaded  
the break card that went between jobs.  Each job executed as soon as it  
was translated and when it finished executing, control returned to the  
compiler for the next job.) For its time and the computer, it was very  
fast and efficient.  Many faculty prefered it to the FORTRAN on the  
school's mainframe (384 Kbytes) which took hours to turn a job around.   
(Of course this meant that your job had to fit iinto 8 kbytes!)

One thing that made a difference is that some of the common languaages of  
that era were designed so that the compiler could determine the kind of  
statement from the first two or three letters of the statement.  Both  
FORTRAN and the early BASICs were this way.  At this point the compiler  
jumped to a statement specific translation.  No LL(1), parse tables, or  
other more powerful techniques needed.  Not that I would give up the  
language advantages that these techniques allow.  There is no free lunch  
and, IMHO, many newer language features justify all the extra power that  
is necessry to compile them.

As I said at the beginning it is good to find someone that remembers and  
cares about the early days.

-- 

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrew Reilly]

On Sat, 25 Jul 2009 22:10:03 -0400, wwilson wrote:

> One thing that made a difference is that some of the common languaages
> of that era were designed so that the compiler could determine the kind
> of statement from the first two or three letters of the statement.  Both
> FORTRAN and the early BASICs were this way.  At this point the compiler
> jumped to a statement specific translation.  No LL(1), parse tables, or
> other more powerful techniques needed.  Not that I would give up the
> language advantages that these techniques allow.  There is no free lunch
> and, IMHO, many newer language features justify all the extra power that
> is necessry to compile them.

A comment of Bertrand Meyer's that I remember reading, and agreeing with 
whole-heartedly, is that computers exist to do work, and the more of our 
(menial) work that we (as programmers) can get them to do for us, the 
better off we'll be.  I think that most "modern" languages have taken 
that sentiment well and truly to heart, and that's a very good thing.

I do remember loading compilers from tape into 16k-bytes of RAM, too.  
Yes, it was neat that that was possible, and there are certainly 
important classes of computers that have no more memory than that, today, 
but we don't generally ask them to run compilations for us...

Cheers,

-- 
Andrew

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[bartc]

"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message 
news:7d20p0F29q0dnU1@mid.individual.net...
> On Sat, 25 Jul 2009 22:10:03 -0400, wwilson wrote:
>
>> One thing that made a difference is that some of the common languaages
>> of that era were designed so that the compiler could determine the kind
>> of statement from the first two or three letters of the statement.  Both
>> FORTRAN and the early BASICs were this way.  At this point the compiler
>> jumped to a statement specific translation.  No LL(1), parse tables, or
>> other more powerful techniques needed.  Not that I would give up the
>> language advantages that these techniques allow.  There is no free lunch
>> and, IMHO, many newer language features justify all the extra power that
>> is necessry to compile them.
>
> A comment of Bertrand Meyer's that I remember reading, and agreeing with
> whole-heartedly, is that computers exist to do work, and the more of our
> (menial) work that we (as programmers) can get them to do for us, the
> better off we'll be.

My desktop pc is probably some 1000-10000 times more powerful than the 
computer I used at college with it's 200 simultaneous users.

And what does it spend it's time doing? Probably 99% of the time waiting for 
me to hit a key or pushing a mouse cursor around. 1% of the time doing 
actual work: downloading an email or web page (which could probably be done 
by a dedicated chip)!

So yes it is taking this menial work extremely seriously. No wonder software 
and languages are so bloated, to keep computers busy. Shame it also makes 
them overcomplex for people to use.

> I do remember loading compilers from tape into 16k-bytes of RAM, too.
> Yes, it was neat that that was possible, and there are certainly
> important classes of computers that have no more memory than that, today,
> but we don't generally ask them to run compilations for us...

I've created a compiler in, not 16K, but 32K, and it's not a big deal. Sure 
a bit more memory would have helped, but the gigabytes available now is a 
complete joke.

-- 
bartc 

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Sat, 25 Jul 2009, wwilson wrote:

|--------------------------------------------------------------------------------|
|"[..]                                                                           |
|                                                                                |
|One thing that made a difference is that some of the common languaages of that  |
|era were designed so that the compiler could determine the kind of statement    |
|from the first two or three letters of the statement.  Both FORTRAN and the     |
|early BASICs were this way.  [..]                                               |
|                                                                                |
|[..]"                                                                           |
|--------------------------------------------------------------------------------|

What about the inability to distinguish between
DO 10 I = 1.10
(the assignment DO10I=1.10)
and
DO 10 I = 1,10
(loop to Statement Label 10 for i in 1..10)
in FORTRAN before coming to the radix point or the comma?

Regards,
Colin Paul Gloster

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[wwilson]

On Mon, 27 Jul 2009 07:28:39 -0400, Colin Paul Gloster  
<Colin_Paul_Gloster@acm.org> wrote:

> On Sat, 25 Jul 2009, wwilson wrote:
>
> |--------------------------------------------------------------------------------|
> |"[..]                                                                            
> |
> |                                                                                 
> |
> |One thing that made a difference is that some of the common languaages  
> of that  |
> |era were designed so that the compiler could determine the kind of  
> statement    |
> |from the first two or three letters of the statement.  Both FORTRAN and  
> the     |
> |early BASICs were this way.   
> [..]                                               |
> |                                                                                 
> |
> |[..]"                                                                            
> |
> |--------------------------------------------------------------------------------|
>
> What about the inability to distinguish between
> DO 10 I = 1.10
> (the assignment DO10I=1.10)
> and
> DO 10 I = 1,10
> (loop to Statement Label 10 for i in 1..10)
> in FORTRAN before coming to the radix point or the comma?
>
> Regards,
> Colin Paul Gloster


  Hey Colin

Glad to hear from someone else who remembers the good old days.

As you know, this was a common beginner (both user and compiler writer)  
difficulty in FORTRAN.

Your first example is correct.  ANSI FORTRAN called for ignorimg most  
blanks including this case. ANSI complient compilers would indeed  
translate your first statement as an assignment.

However, most FORTRAN compilers were not ANSI complient.  (At one time or  
another I used, and kept track of, over 30 varieties of FORTRAN.  It was  
an interesting and tedious job!  I even wrote a report for US Army labs on  
"least common denominator FORTRAN" which is just what it sounds like.) You  
were liable to see almost anything in these versions.  Many for example  
allowed you to include assembly language mixed in with the FORTRAN.  (This  
was before stuctured assembly languages and they filled a definite need.)   
Many had additional data types (complex and interval to name two).

To simplify compilation (or because the compiler writer didn't know or  
care) many of these varieties used "DO " as a reserved word (although  
FORTRAN had no reserved words).  I think this was more common on FORTRANs  
for small computers though I have no proof.

Thank you for pointing out a distinction I should have made.  Any other  
cases that I missed?



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 28 Jul 2009, wwilson wrote:

|-----------------------------------------------------------------------------|
|"[..]                                                                        |
|                                                                             |
|Glad to hear from someone else who remembers the good old days.              |
|                                                                             |
|[..]"                                                                        |
|-----------------------------------------------------------------------------|

Uh, I was born in 1980. FORTRAN has not been banished from my life yet.

|------------------------------------------------------------------------------|
|"Thank you for pointing out a distinction I should have made.  Any other cases|
|that I missed?"                                                               |
|------------------------------------------------------------------------------|

Because of the way whitespace is allowed in FORTRAN keywords, maybe
there are some examples not including DO but I am not sure.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Dave Seaman]

On Tue, 28 Jul 2009 01:01:45 -0400, wwilson wrote:

> To simplify compilation (or because the compiler writer didn't know or  
> care) many of these varieties used "DO " as a reserved word (although  
> FORTRAN had no reserved words).  I think this was more common on FORTRANs  
> for small computers though I have no proof.

> Thank you for pointing out a distinction I should have made.  Any other  
> cases that I missed?

You may find a few in the following program, which actually compiles (with
numerous warnings) under gfortran 4.4.0 and executes.

      integer go to,do 100 if,return
      real read(4)
      logical go to if
      real logical(30)
      data read/4h(1x,,3hi5,,4hf8.1,1h)/
      data go to,do 100 if,if 100 do/2,1,30/
      assign 100 to if go to
      do 100 if=do 100 if,if 100 do 
      return=if 
      logical(if)=return
      go to if=if-go to*(if/go to).eq.do 100 if 
      if(go to if) go to if go to 
      call call(logical,return) 
  100 continue
      print read, (if,logical(if),if=do 100 if,if 100 do) 
      stop
      end 
      subroutine call( integer,real ) 
      integer real
      real integer(real)
      common(if)=if*if
      integer(real)=common(real)
      return
      end 





-- 
Dave Seaman
Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
<http://www.indybay.org/newsitems/2008/03/29/18489281.php>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Peter Hermann]

In comp.lang.ada Dave Seaman <dseaman@no.such.host> wrote:
>       integer go to,do 100 if,return
[snip]

           heavy 



thank you for the good laugh	   

(added comp.lang.fortran ;-)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[wwilson]

On Tue, 28 Jul 2009 08:29:36 -0400, Dave Seaman <dseaman@no.such.host>  
wrote:

> On Tue, 28 Jul 2009 01:01:45 -0400, wwilson wrote:
>
>> To simplify compilation (or because the compiler writer didn't know or
>> care) many of these varieties used "DO " as a reserved word (although
>> FORTRAN had no reserved words).  I think this was more common on  
>> FORTRANs
>> for small computers though I have no proof.
>
>> Thank you for pointing out a distinction I should have made.  Any other
>> cases that I missed?
>
> You may find a few in the following program, which actually compiles  
> (with
> numerous warnings) under gfortran 4.4.0 and executes.
>
>       integer go to,do 100 if,return
>       real read(4)
>       logical go to if
>       real logical(30)
>       data read/4h(1x,,3hi5,,4hf8.1,1h)/
>       data go to,do 100 if,if 100 do/2,1,30/
>       assign 100 to if go to
>       do 100 if=do 100 if,if 100 do
>       return=if
>       logical(if)=return
>       go to if=if-go to*(if/go to).eq.do 100 if
>       if(go to if) go to if go to
>       call call(logical,return)
>   100 continue
>       print read, (if,logical(if),if=do 100 if,if 100 do)
>       stop
>       end
>       subroutine call( integer,real )
>       integer real
>       real integer(real)
>       common(if)=if*if
>       integer(real)=common(real)
>       return
>       end
>
>
>
>
>

I love it.  Beautiful.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[parnell]

I would try ATS:

http://www.ats-lang.org/

it is very new but it seems like a promising multi-paradigm
programming language.

Cheers,

Parnell

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 18, 7:19 am, Andrea Taverna <a.tavs.NOS...@libero.it.invalid>
wrote:
> Hi folks!
>
> I'm a CS student and I often need to write number-crunching code dealing
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including general
> solvers.
>
> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard
> or de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"
>
> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.
>
> TIA
>
> --> Impressions I got for each language
>
>      - FreePascal is a safe and modular alternative to C and C++,  but
> it is also close to the latter in terms of expressiveness. Moreover it
> doesn't seem to have the libraries I need.
> ==>Qualifies for 0,1,2,5. Not sure about 3 and 4
>
>      - Eiffel is geared toward application programming in
> medium/large-sized teams relying heavily on OO modelling. It is designed
> for (re)usability, correctness and efficiency in this order.  
> My needs are somewhat different though.
> The main gripe I have with Eiffel is the lack of a well-documented
> standard gpl'ed library.
> GOBO and EiffelBase seem to have incomplete or non-free documentation
> and I couldn't find tutorials; as such, I couldn't get a clear picture
> about them.
> ==> Qualifies for 0,1,2,4,5 and 6.  Not sure about 3.
>
>      - Ada is best suited for large teams and/or critical software, thus
> it may be overkill for my work, OTH it could have anything I might
> happen to need.
> What holds me from jumping onto Ada is the potential complexity
> It would be interesting  to hear the experience of other people learning
> Ada from the C/Java background.
> As for memory management (requirement 4), I heard there are different
> takes on the matter:
>  (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> reducing the need of manual management (MM)
>  (b) Ada libraries adopt idioms that further simplifies MM issues
>  (c) Conservative garbage collectors such as Bohem's can be used with
> Ada, and they are supposed to work "better" with Ada than with unsafe
> languages such as C and C++
>
> So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> mercifully shed some light on the issue.
>
> There seems to be a lot of Ada95 free documentation on the net, I guess
> it's suitable for Ada05 as well.
> ==> Qualifies for 0,1,2,3,5 and, partially, 4
>
>      - Modula-3 is simpler/smaller than Ada and has been successfully
> used for system/application programming.
> It seems to be the most consistent, simple and easy to grok, but I
> couldn't find any container/math library ready to use.
> ==> Qualifies for 0,1,2,4,5,6.

P.S. I was going to write a 3-sentence reply, but got carried away. I
hope this wasn't a troll...

My needs are similar to yours, and I've been looking for better
languages and learning them for years.

In summary: everything sucks, when you look close enough.

OCaml should probably be your #1 choice (about 2x slower than C
usually, single core). Has its own flaws (Google "Ocaml sucks")

Ada is also 2x slower, but less suitable for your purposes (verbose,
less memory safe than OCaml, free compilers produce GPL-only code)

Haskell is good for prototyping, and performance on par with C can be
achieved (but not reliably, at the cost of writing code 10x more
terrible than C: look at the crap in the shootout).

Java: 1.5x slower than C as a rule of thumb. Safe, verbose,
repetitive, overengineered. Some stuff you get for free with C++ and
OCaml ("clone") or in OCaml ("marshalling"), you have to write by hand
in Java for every single class.

C++: learning curve and safety are the main problems. I'm way past the
former, and I use Visual Studio Debug mode (I develop cross-platform
code) when there is any sign of memory problems (not frequent), but
it's still not completely safe.

Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
C (single core only), but you have to work to get within 2x (unlike
OCaml), and if you want it fast, it can't be safe (switch controlled).

The others you mention are dead, with all the implications.

(replaced dead NGs with more relevant ones)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

fft1976 wrote:

> In summary: everything sucks, when you look close enough.
> 
> OCaml should probably be your #1 choice (about 2x slower than C
> usually, single core). Has its own flaws (Google "Ocaml sucks")
> 
> Ada is also 2x slower, but less suitable for your purposes (verbose,
> less memory safe than OCaml, free compilers produce GPL-only code)

Whatever, free Ada (and C++) compilers made from the FSF's GCC
sources produce non-GPL enforcing executables.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

fft1976 wrote:
> Ada is also 2x slower [than C], but less suitable for your purposes (verbose,
> less memory safe than OCaml, free compilers produce GPL-only code)

Correction: the Ada run-time library from GCC (from the Free Software
Foundation) is licensed under GPLv3 with run-time linking exception,
so does not cause the executables to be under GPL.  But that wasn't
the OP's concern, anyway.

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 28, 3:01 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> fft1976 wrote:
> > Ada is also 2x slower [than C], but less suitable for your purposes (verbose,
> > less memory safe than OCaml, free compilers produce GPL-only code)
>
> Correction: the Ada run-time library from GCC (from the Free Software
> Foundation) is licensed under GPLv3 with run-time linking exception,
> so does not cause the executables to be under GPL.  But that wasn't
> the OP's concern, anyway.

I've read somewhere that the quality of those FSF Ada tools/libraries
is not as good (if it were, what would keep the commercial vendors in
business?)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 30, 4:04 am, fft1976 <fft1...@gmail.com> wrote:
> On Jul 28, 3:01 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > fft1976 wrote:
> > > Ada is also 2x slower [than C], but less suitable for your purposes (verbose,
> > > less memory safe than OCaml, free compilers produce GPL-only code)
>
> > Correction: the Ada run-time library from GCC (from the Free Software
> > Foundation) is licensed under GPLv3 with run-time linking exception,
> > so does not cause the executables to be under GPL.  But that wasn't
> > the OP's concern, anyway.
>
> I've read somewhere that the quality of those FSF Ada tools/libraries
> is not as good (if it were, what would keep the commercial vendors in
> business?)

Support. But in general the FSF is always going to be a bit 'behind
the curve'.

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

fft1976 wrote:
> C++: learning curve and safety are the main problems. I'm way past the
> former, and I use Visual Studio Debug mode (I develop cross-platform
> code) when there is any sign of memory problems (not frequent), but
> it's still not completely safe.

If you're using VS then I highly recommend F# for numerical work, largely
because it makes parallelism so easy.

> Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
> C (single core only), but you have to work to get within 2x (unlike
> OCaml), and if you want it fast, it can't be safe (switch controlled).

Bigloo?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[frankenstein]

On Jul 29, 12:14 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> fft1976 wrote:

> If you're using VS then I highly recommend F# for numerical work, largely
> because it makes parallelism so easy.
>
> > Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
> > C (single core only), but you have to work to get within 2x (unlike
> > OCaml), and if you want it fast, it can't be safe (switch controlled).
>
> Bigloo?


Bigloo is a good option for numerical work and sometimes beats my
Fortran F90 code. I am not a Fortran 90 expert but that Bigloo stacks
up  well compared to Fortran tells a lot.

Fact #1: We must forget about the language shootout page because it is
and always has been a kinda like of Micky Mouse benchmark (any idot
who thought he might make up for an excellent programmer posted crappy
code and once posted it is forever in google's history and a lot of
other idiots will use the result from the benchmark). RIP language
shotout page.


Fact 2: The performance of Bigloo especillay for larger problems where
your simulations will consume 12 hours and more on processor times and
will use 2GB of associated main memory and more  does not come for
free. You will have to program your intended code with this in mind.
HOWEVER, turning Bigloo into a numerical powerhorse for large data
simulations is straightforward:

a) use from the very beginning on *fx, *fl ... native Bigloo operators
(IT IS VERY easy to use them and the compiler will help you out a lot
to spotting type mismatches; however, you won't have to use your gun
as you likely would by using OCaml and shooting yourself to stop the
battling for types).


b) use f32 or f64 arrays (I created my own array class) whenever
possible. especially use f32 for large data simulations since it makes
a whole lot of a difference if your data are half the size in the main
memory in 32-bits mode than as it would be in 64-bits even though
internal calculations are always automatically casted to Bigloo its C
type double.

c) use classes to make code clearer: classes are very fast in Bigloo.

d) whenever you have to read in binary data (note there are some
issues with f32 bits; read Bigloo its mailing list) use or check for
the following undocumented functions and your code will fly: (ieee-
string->double), (ieee-string->float), (double->ieee-string), (float-
>ieee-string), etc.

e) use -Obench option when compiling, -Obench covers more or less all
Bigloo to C related and associated compiler options with speed in mind
(no bound checking etc.).

f) add types to your code to make it readable for others and for your
pleasure to read and understand your own code during your debugging
excercise:

==
(define (add-vector::vector vec1::vector vec2::vector name::bstring
x::bint y::my-class)
  (...))
==

I haven't realaesed it yet but I have fully fledged with a whole lot
of bells and whistles bindings to:

- full clapack (linear algebra package converted from Fortran to C by
f2c freely downloadable from the net)
- full DISLIN (high level plotting routine)
- binding to a random number generator
- binding to a mie scattering code
- a matrix class (for creating n dimensional f32 and f64 matrices,
mapping over n-dimensional matrices, pretty printing, slicing, etc.)
which does a fantastic job and is up to the task speed wise.

NOTE: Translating code from an imperative language lets say Fortran to
Bigloo is easy. A lot of Fortran code consists of do loops which
Bigloo you might uses as well:

==
(do ((i 0 (+fx i 1))
     ((=fx i dim))
     (do ... etc.
==

The only issue: Bigloo like C is 0 based and in my case I always think
in row order instead of Fortran column order scheme.


If you don't use Bigloo and recipies and suggestions posted above
Bigloo is dog slow. However, it is really very simple and comes more
or less at no cost to tailor it to a bespoken powerhorse.

Whenever anyone writes a binding for a well respected external C
library which a lot of people might be  interested in please make it
public (yes, yes, I for mself haven't done it yet for dislin and
clapack, etc.). In the hope scientists will stop using Micky Mouse
languages like Matlab or Python with is a pain in the ass.

Bigloo also makes available classes for java. However, I have no idea
if this works well or not and if there are people out there who are
using Bigloo in Java for numerical work.

That said: a big question mark: I haven't seen any detailed
descriptions of Bigloo and how to employ threads to use dual-core or
multi processors even in numerical code.

If anone likes to come forward please do so and report of your
experience using Bigloo in a multi processor farm.

Thanks, Rumpelstilzchen

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Paul Rubin]

frankenstein <klohmuschel@yahoo.de> writes:
> Fact #1: We must forget about the language shootout page because it is
> and always has been a kinda like of Micky Mouse benchmark (any idot
> who thought he might make up for an excellent programmer posted crappy
> code and once posted it is forever in google's history and a lot of
> other idiots will use the result from the benchmark). RIP language
> shotout page.

The shootout is reasonably informative when it's about languages that
have many active practitioners.  If someone posts crappy slow code
that makes the language look bad for a while, someone else can come
along and post faster code.  So there is ongoing competition between
GHC, Ocaml, C++ and so forth.  It's only for the languages with fewer
practitioners (these can still be perfectly good languages) that the
early crappy submissions don't get improved regularly.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Paul Rubin wrote:
> frankenstein <klohmuschel@yahoo.de> writes:
>> Fact #1: We must forget about the language shootout page because it is
>> and always has been a kinda like of Micky Mouse benchmark (any idot
>> who thought he might make up for an excellent programmer posted crappy
>> code and once posted it is forever in google's history and a lot of
>> other idiots will use the result from the benchmark). RIP language
>> shotout page.
> 
> The shootout is reasonably informative when it's about languages that
> have many active practitioners.  If someone posts crappy slow code
> that makes the language look bad for a while, someone else can come
> along and post faster code.  So there is ongoing competition between
> GHC, Ocaml, C++ and so forth.  It's only for the languages with fewer
> practitioners (these can still be perfectly good languages) that the
> early crappy submissions don't get improved regularly.

No, I contributed dozens of optimized programs to the shootout only to have
them rejected for subjective reasons because the benchmarks are poorly
designed. Some of the benchmarks still on there have "deoptimized by Isaac
Gouy" written in them, for example. Consequently, you cannot draw any
useful conclusions about languages from it.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[frankenstein]

On Aug 1, 10:56 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> frankenstein <klohmusc...@yahoo.de> writes:
> > Fact #1: We must forget about the language shootout page because it is
> > and always has been a kinda like of Micky Mouse benchmark (any idot
> > who thought he might make up for an excellent programmer posted crappy
> > code and once posted it is forever in google's history and a lot of
> > other idiots will use the result from the benchmark). RIP language
> > shotout page.
>
> The shootout is reasonably informative when it's about languages that
> have many active practitioners.  If someone posts crappy slow code
> that makes the language look bad for a while, someone else can come
> along and post faster code.  So there is ongoing competition between
> GHC, Ocaml, C++ and so forth.  It's only for the languages with fewer
> practitioners (these can still be perfectly good languages) that the
> early crappy submissions don't get improved regularly.


The shootout is completely useless when it comes to real life. I have
to deal with large data sets and simulations. My problem is that most
of my simulations are stuck in reading in the data. Data from global
chemistry transport models and satellite date make quickly up for 500
GB for a year worth of data and observations. Even only processing day
after day most of the 12 hours the simulation takes is spent in
reading in the data.

Fortran by nature is fast even when using object oriented programming.
However, I am now changing my code to Bigloo. I have no actual figures
if my simulations (basically eigenvalues and inverse and inversion
from data and observations; i am using my binding to clapack for this)
will be as fast as the ones written in Fortran. However, I made the
observation that my class for reading the data from the global
chemistry transport model is faster than the origial code which comes
shipped with the model for reading in the binary files created by the
model. I guess the reason being this: they read in record after record
without ever jumping to the match. My class (based on (ieee-string-
>float and mmap)) jumps around, e.g. the fortran program (with -O3
option) and ifort compiler would take 6 seconds for reading in an
array whereas my bigloo code takes 4 seconds. Disclaimer: (ieee-string-
>float) as it  now stands has a bug in Bigloo and I was forced to use
a software conversion (code for converting 4-bytes to float posted
long time ago here on comp.lang.scheme by Oleg) which puts the figures
to 8 seconds. However, I am quite sure Bigloo developers will resolve
the bug. So my benchmark of seconds is based on a wrong conversion (it
will always give 0.0 instead of the actual value). I also made the
observations that during the read process my Bigloo program and
Fortran consumes the same amount of real memory. I am not expecting
that bigloo will be more memory efficient but I hope the grabage
collector will serve me well. allocating deallocatin (since Fortran 90
standard) is very efficient in Fortran.


Frau Holle

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

frankenstein wrote:
> Fortran by nature is fast even when using object oriented programming.

That was true many years ago but Fortran has fallen a long way behind now.
Applications like numerical methods from linear algebra operating on
matrices with single, double or single/double complex elements were
Fortran's last refuge for many years but even they have come under fire
now.

For example, I recently implemented QR decomposition in F#:

http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-qr-decomposition.html

Fortran is not only incapable of expressing the algorithm that generically,
it is also up to 3x slower than F#!

The reason is the efficiency of parallelism in F#, using the wait-free
work-stealing concurrent deques of the Task Parallel Library for the
efficient dynamic load balancing of fine-grained parallel work items.

If Fortran cannot even compete there, where it is strongest, then it has no
hope for other applications. Hence the defacto-standard libraries for
things like FFTs have been written in a mix of higher-level languages and C
for many years now. For most scientific computing, it is no longer
practically feasible to use Fortran because the language is too cumbersome
and inexpressive.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[frankenstein]

As an addendum: I shall post in the following some bits of my matrix
class. Sorry there are no comments and it lacks all my pretty
printing, slicing and mapping over matrix stuff. However, you should
get an idea. Scroll down until you reach the example of the matrix
matrix multiplication. If you want to bench it againts a C code: use
google for the C code of a matrix matrix multiplication:

copy the code enclosed into a file e.g. foo.scm

and on the command line: bigloo -Obench foo.scm, and time a.out. If
you want to increase the size use 1024 e.g. in (do-main 1024).

Some basics to the class: read through it and you will encounter 3
classes: 64-bit, 32-bit and realmat

you create an n-dimensioanal matrix as follows: (mk-f64mat i j ... n
val: 0.0e0)
you access the values: (f64m& i j ... n)
you store values: (f64m! i j ... n value)

same goes for f32, and realmat. update and accessing is done by the
macro and should be sufficient fast.

Raueber Hotzenplotz


==
(module matrix
   (export
    (class f64mat
       mat
       (rank::bint (default 1))
       (dims::pair-nil (default '(1)))
       (print-index?::bool (default #t)))
    (class f32mat
       mat
       (rank::bint (default 1))
       (dims::pair-nil (default '(1)))
       (print-index?::bool (default #t)))
    (class realmat
       mat
       (rank::bint (default 1))
       (dims::pair-nil (default '(1)))
       (print-index?::bool (default #t)))
    (inline make-matrix::obj  op::pair-nil #!key   (val 0.0e0) (type
(lambda (x y) (make-vector x y))))
     (inline make-matrix-local::obj  op::pair-nil  #!key (val 0.0e0)
(type (lambda (x y) (make-vector x y))))
    (inline mk-f64mat::f64mat  #!rest op::pair-nil #!key (val 0.0e0))
    (inline mk-f32mat::f32mat  #!rest op::pair-nil #!key (val 0.0))
    (inline mk-realmat::realmat #!rest  op::pair-nil #!key (val 0.0))
    (macro aref-set-helper fun::obj x::obj i::bint  .  op::obj)
    (macro f64m&  mat::f64mat . op::obj)
    (macro f32m& mat::f32mat . op::obj)
    (macro realm& mat::realmat . op::obj)
    (macro f64m!c  mat::f64mat val::double . op::obj)
    (macro f64m!  mat::f64mat  . op::obj)
    (macro f32m!c  mat::f32mat val::real . op::obj)
    (macro f32m!  mat::f32mat val::real . op::obj)
    (macro realm!c  mat::realmat val::real . op::obj)
    (macro realm!  mat::realmat val::real . op::obj)))




(define-inline (.1st. x::pair-nil) (car x))
(define-inline (.2nd. x::pair-nil) (cadr x))
(define-inline (.3rd. x::pair-nil) (caddr  x))



(define-inline (make-matrix-local::obj  op::pair-nil
				  #!key (val 0.0e0)
				  (type (lambda (x y) (make-vector x y))))
   (if (=fx 1 (length op))
       (type (car op) val)
       (let ([mx::vector (make-vector (car op))])
	  (do [(oi 0 (+fx oi 1))]
	      [(=fx oi (car op))]
	      (vector-set! mx oi (make-matrix-local  (cdr op) val: val type:
type)))
	  mx)))



(define-inline (make-matrix::obj  op::pair-nil
				  #!key (val 0.0e0)
				  (type (lambda (x y) (make-vector x y))))
   (if (=fx 1 (length op))
       (type (car op) val)
       (let ([mx::vector (make-vector (car op))])
	  (do [(oi 0 (+fx oi 1))]
	      [(=fx oi (car op))]
	      (vector-set! mx oi (make-matrix  (cdr op) val: val type:
type)))
	  mx)))





(define-inline (mk-f64mat::f64mat  #!rest  op::pair-nil #!key (val
0.0e0))
   (let* ((indx::bint (-fx (length op) 1)))
      (if (<fx indx 2)
	  (begin
	     (error "mk-f64mat in matrix.scm" "you would have to pass at
least 1 dimension"  op))
	  (begin
	     (let* ((val::double (list-ref op indx))
		    (op::pair (take op (-fx indx 1))))
		;(print op val indx)
		(instantiate::f64mat (mat (make-matrix-local op val:  val type:
(lambda (x y) (make-f64vector x y))))
				     (rank (length op))
				     (dims op)))))))


(define-inline (mk-f64matr::f64mat  #!rest op::obj)
   (instantiate::f64mat (mat (make-matrix-local op val:  0.0e0 type:
(lambda (x y) (make-f64vector x y))))
			(rank (length op))
			(dims op)))



(define-inline (mk-f32matr::f32mat  #!rest op::obj)
   (instantiate::f32mat (mat (make-matrix-local op val: 0.0 type:
(lambda (x y) (make-f32vector x y))))
			(rank (length op))
			(dims op)))



(define-inline (mk-f32mat::f32mat  #!rest  op::pair-nil #!key (val
0.0))
   (let* ((indx::bint (-fx (length op) 1)))
      (if (<fx indx 2)
	  (begin
	     (error "mk-f32mat in matrix.scm" "you would have to pass at
least 1 dimension"  op))
	  (begin
	     (let* ((val (list-ref op indx))
		    (op::pair (take op (-fx indx 1))))
		(instantiate::f32mat (mat (make-matrix-local op val:  val type:
(lambda (x y) (make-f32vector x y))))
				     (rank (length op))
				     (dims op)))))))



(define-inline (mk-realmatr::realmat  #!rest op::obj)
   (instantiate::realmat (mat (make-matrix-local op val: 0.0 type:
(lambda (x y) (make-vector x y))))
			 (rank (length op))
			 (dims op)))


(define-inline (mk-realmat::realmat  #!rest  op::pair-nil #!key (val
0.0))
   (let* ((indx::bint (-fx (length op) 1)))
      (if (<fx indx 2)
	  (begin
	     (error "mk-realmat in matrix.scm" "you would have to pass at
least 1 dimension"  op))
	  (begin
	     (let* ((val::double (list-ref op indx))
		    (op::pair (take op (-fx indx 1))))
		(instantiate::realmat (mat (make-matrix-local op val:  val type:
(lambda (x y) (make-vector x y))))
				     (rank (length op))
				     (dims op)))))))





(define-macro (m& x::obj i::bint  .  op::obj)
   (if (null? op)
       `(vector-ref ,x ,i)
       `(a& (vector-ref ,x ,i)  ,@op)))


(define-macro (m!  x::obj val::obj i::bint  .  op::obj)
   (if (null? op)
       `(vector-set! ,x ,i ,val)
       `(a! (vector-ref ,x ,i)  ,@op)))



(define-macro (f64m&  mat::f64mat . op::obj)
   `(with-access::f64mat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (f64vector-ref xx yy))
			mat   ,@op)))


(define-macro (f32m&  mat::f32mat . op::obj)
   `(with-access::f32mat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (f32vector-ref xx yy))
			mat   ,@op)))

(define-macro (realm&  mat::realmat . op::obj)
   `(with-access::realmat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (vector-ref xx yy))
			mat   ,@op)))




(define-macro (f64m!  mat::f64mat  . op::obj)
   (let* ((indx::bint (-fx (length op) 1))
	  (val::double (list-ref op indx))
	  (op::pair (take op indx)))
      `(with-access::f64mat ,mat (mat)
	  (aref-set-helper (lambda (xx yy) (f64vector-set! xx yy ,val))
			   mat   ,@op))))


(define-macro (f32m!  mat::f32mat  . op::obj)
   (let* ((indx::bint (-fx (length op) 1))
	  (val::double (list-ref op indx))
	  (op::pair (take op indx)))
      `(with-access::f32mat ,mat (mat)
	  (aref-set-helper (lambda (xx yy) (f32vector-set! xx yy ,val))
			   mat   ,@op))))


(define-macro (realm!  mat::realmat  . op::obj)
   (let* ((indx::bint (-fx (length op) 1))
	  (val::double (list-ref op indx))
	  (op::pair (take op indx)))
      `(with-access::realmat ,mat (mat)
	  (aref-set-helper (lambda (xx yy) (vector-set! xx yy ,val))
			   mat   ,@op))))


(define-inline (aref-set-helper-new fun::obj x::obj i::bint   op::obj)
   (if (null? op)
       (fun x i)
       (aref-set-helper-new fun (vector-ref x i)  (car op) (cdr op))))


(define-macro (aref-set-helper fun::obj x::obj i::bint  .  op::obj)
   (if (null? op)
       `(,fun ,x ,i)
       `(aref-set-helper ,fun (vector-ref ,x ,i)  ,@op)))






(define-macro (f64m!c  mat::f64mat val::double . op::obj)
   `(with-access::f64mat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (f64vector-set! xx yy ,val))
			mat   ,@op)))


(define-macro (f32m!c  mat::f32mat val::real . op)
   `(with-access::f32mat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (f32vector-set! xx
yy ,val)))))


(define-macro (realm!c  mat::realmat val::real . op::obj)
   `(with-access::realmat ,mat (mat)
       (aref-set-helper (lambda (xx yy) (vector-set! xx yy ,val))
			mat   ,@op)))



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Test: matrix -matrix multiplication
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; we craete a matrix here:
;; (mk-f64mat rows cols val: 0.0e0)
;; will create a 64bit matrix of size (rows x cols)
;;
;; we can update individual values by:
;; (f64m! matrix i j value)
;; matrix is the matrix
;; i, j are the indices (based and rows runs first)
;; value is the value
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(define-inline (mkmatrix::f64mat rows::bint cols::bint)
   (let ((mx::f64mat (mk-f64mat  rows cols val: 0.0e0))
	 (count::double 0.5e0))
      (do ((i 0 (+fx i 1)))
	  ((=fx i rows))
	  (let ((row (make-f64vector cols 0.0e0)))
	     (do ((j 0 (+fx j 1)))
		 ((=fx j cols))
		 (f64m! mx i j count)
		 (set! count (+fl count 0.5)))))
      mx))




;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; we do the matrix matrix multiplication
;;
;; we cann access values in the matrix class by:
;; (f64m& matrix i j)
;; and we set values by: (f64m! matrix i j value)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(define-inline (mmult::f64mat rows::bint cols::bint m1::f64mat
m2::f64mat)
   (let ((m3::f64mat (mk-f64mat  rows cols val: 0.0e0)))
      (do ((i 0 (+fx 1 i)))
	  ((=fx i rows))
	  (do ((j 0 (+fx 1 j)))
	      ((=fx j cols))
	      (let ((val::double 0.0e0))
		 (do ((k 0 (+fx 1 k)))
		     ((=fx k cols))
		     (set! val (+fl val
				    (*fl (f64m& m1 i k)
					 (f64m& m2  k j)))))
		 (f64m! m3  i j val))))
      m3))




(define (do-main size::bint)
   (let ((mm::double 0.0e0)
	 (m1::f64mat (mkmatrix  size size))
	 (m2::f64mat (mkmatrix size size)))
      (set! mm (mmult size size m1 m2))
      (let ((r0 (vector-ref (f64mat-mat mm) 0)))
	 (print (f64vector-ref r0 0)))))


(do-main 512)
==

On Aug 1, 8:46 pm, frankenstein <klohmusc...@yahoo.de> wrote:
> On Jul 29, 12:14 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>
> > fft1976 wrote:
> > If you're using VS then I highly recommend F# for numerical work, largely
> > because it makes parallelism so easy.
>
> > > Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
> > > C (single core only), but you have to work to get within 2x (unlike
> > > OCaml), and if you want it fast, it can't be safe (switch controlled).
>
> > Bigloo?
>
> Bigloo is a good option for numerical work and sometimes beats my
> Fortran F90 code. I am not a Fortran 90 expert but that Bigloo stacks
> up  well compared to Fortran tells a lot.
>
> Fact #1: We must forget about the language shootout page because it is
> and always has been a kinda like of Micky Mouse benchmark (any idot
> who thought he might make up for an excellent programmer posted crappy
> code and once posted it is forever in google's history and a lot of
> other idiots will use the result from the benchmark). RIP language
> shotout page.
>
> Fact 2: The performance of Bigloo especillay for larger problems where
> your simulations will consume 12 hours and more on processor times and
> will use 2GB of associated main memory and more  does not come for
> free. You will have to program your intended code with this in mind.
> HOWEVER, turning Bigloo into a numerical powerhorse for large data
> simulations is straightforward:
>
> a) use from the very beginning on *fx, *fl ... native Bigloo operators
> (IT IS VERY easy to use them and the compiler will help you out a lot
> to spotting type mismatches; however, you won't have to use your gun
> as you likely would by using OCaml and shooting yourself to stop the
> battling for types).
>
> b) use f32 or f64 arrays (I created my own array class) whenever
> possible. especially use f32 for large data simulations since it makes
> a whole lot of a difference if your data are half the size in the main
> memory in 32-bits mode than as it would be in 64-bits even though
> internal calculations are always automatically casted to Bigloo its C
> type double.
>
> c) use classes to make code clearer: classes are very fast in Bigloo.
>
> d) whenever you have to read in binary data (note there are some
> issues with f32 bits; read Bigloo its mailing list) use or check for
> the following undocumented functions and your code will fly: (ieee-
> string->double), (ieee-string->float), (double->ieee-string), (float-
>
> >ieee-string), etc.
>
> e) use -Obench option when compiling, -Obench covers more or less all
> Bigloo to C related and associated compiler options with speed in mind
> (no bound checking etc.).
>
> f) add types to your code to make it readable for others and for your
> pleasure to read and understand your own code during your debugging
> excercise:
>
> ==
> (define (add-vector::vector vec1::vector vec2::vector name::bstring
> x::bint y::my-class)
>   (...))
> ==
>
> I haven't realaesed it yet but I have fully fledged with a whole lot
> of bells and whistles bindings to:
>
> - full clapack (linear algebra package converted from Fortran to C by
> f2c freely downloadable from the net)
> - full DISLIN (high level plotting routine)
> - binding to a random number generator
> - binding to a mie scattering code
> - a matrix class (for creating n dimensional f32 and f64 matrices,
> mapping over n-dimensional matrices, pretty printing, slicing, etc.)
> which does a fantastic job and is up to the task speed wise.
>
> NOTE: Translating code from an imperative language lets say Fortran to
> Bigloo is easy. A lot of Fortran code consists of do loops which
> Bigloo you might uses as well:
>
> ==
> (do ((i 0 (+fx i 1))
>      ((=fx i dim))
>      (do ... etc.
> ==
>
> The only issue: Bigloo like C is 0 based and in my case I always think
> in row order instead of Fortran column order scheme.
>
> If you don't use Bigloo and recipies and suggestions posted above
> Bigloo is dog slow. However, it is really very simple and comes more
> or less at no cost to tailor it to a bespoken powerhorse.
>
> Whenever anyone writes a binding for a well respected external C
> library which a lot of people might be  interested in please make it
> public (yes, yes, I for mself haven't done it yet for dislin and
> clapack, etc.). In the hope scientists will stop using Micky Mouse
> languages like Matlab or Python with is a pain in the ass.
>
> Bigloo also makes available classes for java. However, I have no idea
> if this works well or not and if there are people out there who are
> using Bigloo in Java for numerical work.
>
> That said: a big question mark: I haven't seen any detailed
> descriptions of Bigloo and how to employ threads to use dual-core or
> multi processors even in numerical code.
>
> If anone likes to come forward please do so and report of your
> experience using Bigloo in a multi processor farm.
>
> Thanks, Rumpelstilzchen

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Oxide Scrubber]

fft1976 wrote:
> My needs are similar to yours, and I've been looking for better
> languages and learning them for years.
> 
> In summary: everything sucks, when you look close enough.

Except Clojure.

> Java: 1.5x slower than C as a rule of thumb.

I think it can achieve parity.

> Safe, verbose, repetitive, overengineered. Some stuff you get for free
> with C++ and OCaml ("clone") or in OCaml ("marshalling"), you have to
> write by hand in Java for every single class.

Nope. With Java, in most cases you can slap "implements Cloneable" on a 
class and make the clone method public, or slap "implements 
Serializable" on a class to make its instances marshallable.

Clojure is much better though: safe, non-verbose, non-repetitive, full 
access to Java libraries. Clone you mostly don't need as most data 
structures are immutable. Anything made purely with numbers, strings, 
keywords, symbols, lists, vectors, sets, and maps can be written and 
read using Clojure's reader, and can therefore be marshalled easily, and 
to a human-editable text file to boot. (This doesn't, however, 
interoperate with generic Java objects or Java serialization, and I'm 
not sure it works with data structures with circularities. It won't work 
with data structures with infinite sequences in them, but if you 
represent such sequences symbolically it can.)

Last but not least, numerical Clojure code can fairly easily be tuned to 
give comparable performance to C or even hand-tuned assembly, and 
Clojure has strong support for parallelism and threading.

> Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
> C

Sucks compared to Clojure.

>(single core only)

Sucks compared to Clojure.

> but you have to work to get within 2x (unlike OCaml)

You need to work a bit to get the most speed out of Clojure too, but you 
can then get C-like performance out of it in tight loops.

> and if you want it fast, it can't be safe (switch controlled).

You can have have that cake and eat it too in Clojure, aside from giving 
up protection against integer overflow and wrapping for that last bit of 
speed in integer operations. (There are "unchecked" integer operations 
equivalent to normal C/C++/Java arithmetic on int-like types, and "safe" 
ones that promote as needed to int, long, even bignum.)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 28, 5:40 pm, Oxide Scrubber <jharri...@hatlop.de> wrote:

Clojure is kind of cool, but many corrections are in order:

> fft1976 wrote:
> > Java: 1.5x slower than C as a rule of thumb.
>
> I think it can achieve parity.

I disagree. I don't think the JIT can do much about the memory layout
of the data structures. Compare a vector of complex numbers or of 3D
vectors (NOT of pointers to them) in C/C++ and Java. Run some tests. I
did and I looked at others'.

For me, 1.5x is a good trade-off for safety though.

> With Java, in most cases you can slap "implements Cloneable" on a
> class and make the clone method public,

Java's "clone" does a shallow copy only (check the docs). C++ default
copy constructors call copy constructors on the members.

> or slap "implements
> Serializable" on a class to make its instances marshallable.

Does this handle cycles and memory sharing among data structures?

> (This doesn't, however,
> interoperate with generic Java objects or Java serialization, and I'm
> not sure it works with data structures with circularities. It won't work
> with data structures with infinite sequences in them, but if you
> represent such sequences symbolically it can.)

But you'll need Java's data structures and mutations on Java's arrays
to compete with it in speed of numerical code, so this argument goes
out the window.

> Clojure has strong support for parallelism and threading.

Clojure's support for multithreading is good only as long as your code
is pure-functional. Let's see you add 1.0 to all diagonal elements of
a 1000x1000 matrix.

> You need to work a bit to get the most speed out of Clojure too, but you
> can then get C-like performance out of it in tight loops.

In theory, imperative and Java array using Clojure can be made as fast
as Java (which is slower than C), but in practice, experts seem to
agree that Clojure is 5-10 times slower than Java:

http://groups.google.com/group/clojure/msg/92b33476c0507478

Aside: do you remember to add -O3 when you are compiling C/C++? I use
"-server" when running the JVM.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Oxide Scrubber]

fft1976 wrote:
> On Jul 28, 5:40 pm, Oxide Scrubber <jharri...@hatlop.de> wrote:
> 
> Clojure is kind of cool, but many corrections are in order

No, they are not.

>> fft1976 wrote:
>>> Java: 1.5x slower than C as a rule of thumb.
>> I think it can achieve parity.
> 
> I disagree. I don't think the JIT can do much about the memory layout
> of the data structures. Compare a vector of complex numbers or of 3D
> vectors (NOT of pointers to them) in C/C++ and Java. Run some tests. I
> did and I looked at others'.
> 
> For me, 1.5x is a good trade-off for safety though.

The JIT can't, but the coder can. If you want a vector of N 
double-precision complex numbers in Java that is contiguous in memory, 
for example, you could use a Java array of 2xN doubles and index into it 
appropriately.

This won't work with encapsulated-object bignums, but at that point 
you're probably spending most of your time in individual bignum ops, 
particularly multiplies, anyway, so traversal from one bignum to another 
becomes an insignificant factor in run-time.

>> With Java, in most cases you can slap "implements Cloneable" on a
>> class and make the clone method public,
> 
> Java's "clone" does a shallow copy only (check the docs).

True. If you want a deep copy you will have to implement it yourself. Or 
you can make a deepCopy static utility method that exploits 
"Serializable" to deep copy anything that's serializable simply by 
serializing and deserializing it (which can use memory, or a temp file, 
and not much memory if you make an auxiliary class implement both 
InputStream and OutputStream, with its OutputStream methods writing to a 
growable buffer and its InputStream methods consuming (possibly blocking 
if necessary) from same. Closing the OutputStream aspect EOFs the 
InputStream aspect. Then wrap in ObjectInput/OutputStream. You can use a 
BlockingQueue of byte arrays of length 8192 (or whatever), serialize to 
one end and deserialize from the other in concurrent threads, and it 
will tend to not use much memory. Limit the BlockingQueue length to 1 
item and it will never use much more than 8Kbyte (the OutputStream 
aspect will block until the InputStream aspect consumes from the queue).

>> or slap "implements
>> Serializable" on a class to make its instances marshallable.
> 
> Does this handle cycles and memory sharing among data structures?

It does.

>> (This doesn't, however,
>> interoperate with generic Java objects or Java serialization, and I'm
>> not sure it works with data structures with circularities. It won't work
>> with data structures with infinite sequences in them, but if you
>> represent such sequences symbolically it can.)
> 
> But you'll need Java's data structures and mutations on Java's arrays
> to compete with it in speed of numerical code

Not necessarily. It depends on what sort of numerical code.

If the bulk of the time is spent performing arithmetic operations on 
just a few values, these inner loops can be tightened up and use only 
local variables, no arrays or other structures at all.

If the arithmetic is bignum, the bulk of your time will be spent 
performing individual bignum operations. Algorithmic smartness 
(Karatsuba multiplication, memoizing or otherwise saving multiply-used 
intermediate values, and exploiting concurrency) will win big while 
speeding up the loops that invoke bignum operations won't.

If the arithmetic is on smallnums in arrays and the computations are 
mostly mutations, then you may want to use Java arrays, and you may want 
to use a Java method instead of a Clojure function to do the operation 
(and may still call this from Clojure easily enough). Note above about 
Java: if you want contiguous memory you'll have to give up using Java 
objects for things like complexes. But you can still make quasi-methods 
for quasi-objects (e.g. methods that take an array and an index and 
treat the two array elements starting at that index as real and 
imaginary parts of a complex numbers and perform a complex op on them).

With Clojure code, you can make macros that expand to complex operations 
on adjacent pairs of values in a Java primitive array. In practice, 
Clojure access to Java arrays, even primitive arrays, seems to be slow. 
This may be addressed in a future version. Alternatively, use Java for 
this. Macros can also be used to turn code that operates on notional 
vector-like data structures of lengths known at compile time into code 
that actually operates on large sequences of local variables. The 
"vectors" should then end up as contiguous data on the *stack*. If the 
lengths are not known until run-time, the same macros can be used along 
with "eval" to compile functions on the fly to perform efficient 
operations on them. In fact, if other aspects of the computations are 
also not known until run-time "eval" can be useful. If at compile time, 
for example, an unknown value will be added to the diagonal entries of 
lots of 1000x1000 matrices, and at run time that value is pure real, at 
run time "eval" can emit in this case specialized code that doesn't 
waste time adding thousands of zeros to imaginary parts of matrix entries.

Last but certainly not least, ask if any such algorithms can be 
rewritten to be based less on mutation and more on map-reduce type 
operations.

>> Clojure has strong support for parallelism and threading.
> 
> Clojure's support for multithreading is good only as long as your code
> is pure-functional. Let's see you add 1.0 to all diagonal elements of
> a 1000x1000 matrix.

Clojure has all of Java's support for multithreading too. You could on a 
dual-core machine get two threads each mutating 500 of those diagonal 
entries -- no locking required since the changes are independent of one 
another. Just as you could in Java. Or do it in Java and call this from 
Clojure.

>> You need to work a bit to get the most speed out of Clojure too, but you
>> can then get C-like performance out of it in tight loops.
> 
> In theory, imperative and Java array using Clojure can be made as fast
> as Java (which is slower than C)

See above: not if you lay out your data right, and in Clojure (unlike 
pure Java) you can use macros or similarly to emulate having object 
operations on the data despite it really being in a flat array.

> Aside: do you remember to add -O3 when you are compiling C/C++? I use
> "-server" when running the JVM.

I am assuming both. Without -server, Clojure and Java will be 
significantly slower than C/C++. With -server, I've seen numerical 
calculations in both run at tuned-assembly speeds.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Elena]

On 28 Lug, 20:57, fft1976 <fft1...@gmail.com> wrote:
> >      - Eiffel is geared toward application programming in
> > medium/large-sized teams relying heavily on OO modelling. It is designed
> > for (re)usability, correctness and efficiency in this order.  
> > My needs are somewhat different though.
> > The main gripe I have with Eiffel is the lack of a well-documented
> > standard gpl'ed library.
> > GOBO and EiffelBase seem to have incomplete or non-free documentation
> > and I couldn't find tutorials; as such, I couldn't get a clear picture
> > about them.
> > ==> Qualifies for 0,1,2,4,5 and 6.  Not sure about 3.

Don't forget that you can download a GPLed version of EiffelStudio,
the Eiffel IDE with all bells and whistles from ISE:

https://www2.eiffel.com/download/download_info.aspx?id=eiffelstudio&info=false&mirrors=eiffelstudio

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

On 29 Lug, 09:50, Elena <egarr...@gmail.com> wrote:
> Don't forget that you can download a GPLed version of EiffelStudio,
> the Eiffel IDE with all bells and whistles from ISE:
>
> https://www2.eiffel.com/download/download_info.aspx?id=eiffelstudio&i...

Already done. It's cool, and compiling it felt like unwrapping
birthday gifts.
Still, Eiffel libraries are "complex" due to the use of MI and
descendant hiding and I couldn't find a good tutorial. Documentation,
considering such complexity and the difference between Eiffel and
lower-level languages like Ada, M3 and the like, is too scarce.

So far Eiffel seems the language I'd hope to code in for other tasks
than number crunching, where OO software engineering weights more.

Andrea

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ray Blaak]

fft1976 <fft1976@gmail.com> writes:
> > � � �- Ada is best suited for large teams and/or critical software, thus
> > it may be overkill for my work, OTH it could have anything I might
> > happen to need.

Ada is fine as far as it goes, and there is a GNU Ada compiler which helps a
lot. 

My problem with it is the lack of a garbage collection. That is just not
acceptable to me these days. If you manually allocate memory, then you pretty
much have memory bugs, it's as simple as that.

It's better than C/C++ for sure, but I remember plenty of memory exceptions all
the same.

Also, I find the OO notation a little quirky.

> Ada is also 2x slower, but less suitable for your purposes (verbose,
> less memory safe than OCaml, free compilers produce GPL-only code)

I am pretty sure the GPL-only thing is not true.

My own language choice now would be Java or C#. I am investigating Clojure
since I always have a fondness for Scheme/Lisps, and a modern Lisp on the JVM
solves a lot of problems.

OCaml is something I want to know better as well. Any of the ML-family
languages should improve your type theoretical skills.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[learn2code]

["Followup-To:" header set to comp.lang.ada.]
On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:
> fft1976 <fft1976@gmail.com> writes:

> My problem with it is the lack of a garbage collection. That is just not
> acceptable to me these days. If you manually allocate memory, then you
> pretty much have memory bugs, it's as simple as that.

That is simply not true. If you don't know how to do resource management
properly, you're not ready to write commercial code in any environment.

Garbage collection is a throwback to interpreted languages and bloated
run-time systems. Normal compiled languages get along very well without any
such thing at all.

You need to understand your tools and not rely on the rubber crutches
overglorified scripting platforms like Java have taught people to put blind
faith in. What ever happened to competent coders? There is no idiot-proof
system. If you don't know how to manage storage, you shouldn't be allocating
it.

> Also, I find the OO notation a little quirky.

That's a tough proposition from someone advocating C++. C++ notation is
hideous, obfuscated, and error-prone. It's one of the least readable (maybe
the worst in that regard) of any of the languages in common use.

Ada is readable. It's clean, it's orderly, it's so much better and safer
than C++ that there isn't any comparison at all. But that is certainly all
lost on somebody who believes it's impossible to manage memory properly and
thinks garbage collection is a must-have for any language.

>> Ada is also 2x slower, but less suitable for your purposes (verbose,
>> less memory safe than OCaml, free compilers produce GPL-only code)

All utter nonsense. (Understood this was not your comment, you were replying
to the previouis poster...)

> I am pretty sure the GPL-only thing is not true.

Correct.

> My own language choice now would be Java or C#. I am investigating Clojure
> since I always have a fondness for Scheme/Lisps, and a modern Lisp on the
> JVM solves a lot of problems.

Well yes, if you don't know how to code and if you don't understand
fundamental aspects of software engineering like resource management, you
definitely shouldn't be writing code for commercial or industrial
environments and you probably should be using the "protect me from myself"
platforms like Java and C#. I can understand your post better now.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Oxide Scrubber]

learn2code@yourdesk.com wrote:
> ["Followup-To:" header set to comp.lang.ada.]

Sorry, no can do. You write complete nonsense in four newsgroups, you 
get corrected in four newsgroups.

> On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:
>> fft1976 <fft1976@gmail.com> writes:
> 
>> My problem with it is the lack of a garbage collection. That is just not
>> acceptable to me these days. If you manually allocate memory, then you
>> pretty much have memory bugs, it's as simple as that.
> 
> That is simply not true. If you don't know how to do resource management
> properly, you're not ready to write commercial code in any environment.

What utter balderdash. You make GC sound like training wheels, when in 
fact it is very useful even for major production-code systems.

Consider memory management of an object that is shared and passed around 
at need among many related parts of a program. Keeping track of when 
it's no longer in use rapidly becomes nontrivial as the complexity of 
the code using it goes up. Eventually, you'll be reference counting or 
doing something else like that, and before long, you'll end up with an 
ad-hoc, informally specified, slow, bug-ridden implementation of half of 
a garbage collector. (This will probably in turn be a part of an ad-hoc, 
informally specified, slow, bug-ridden implementation of half of Common 
Lisp.)

Why not save yourself the trouble and use a real GC, then? Especially 
since a properly-used GC will actually improve execution speed.

Typical C++ code has to spend time deallocating objects proportional to 
the number of objects that need deallocating. GCs tend to spend time 
deallocating objects proportional to the number of objects that 
*survive* since the last GC. This is often a much smaller number.

On a modern JVM, including Hotspot, the amount of time spent on memory 
management for objects that don't survive to be copied to a tenured 
generation tends to be two.

Two instruction cycles per object, that is, one to copy a pointer and 
one to bump a pointer.

Not even some fiddling around with a free-list on top of that.

The devil is in the details, but the time spent on objects that do 
survive tends not to be much worse over time, especially for very long 
lived objects, which get tenured once and then are very rarely dealt 
with by the garbage collector, which sweeps the tenured space far less 
frequently than it does the young-object space.

The new G1 collector is supposed to be even more efficient; TLABs become 
boxes of objects, which fill up. Eventually the system needs fresh TLABs 
and all the boxes are full, whereupon some of the oldest get garbage 
collected. By then almost everything in them tends to be garbage, and 
only a very few objects must be copied to empty most of those boxes 
while filling a few with live objects. Those become a kind of ad-hoc 
"tenured" generation. Or something like that. Sun's web site has 
technical information about it, somewhere. A site-scoped google search 
of it for "garbage first" should bear fruit.

> Garbage collection is a throwback to interpreted languages and bloated
> run-time systems.

Poppycock.

> Normal compiled languages get along very well without any such thing
> at all.

Many implementations of Common Lisp are compiled. All have GCs. Are none 
of them "normal" compiled languages?

> You need to understand your tools and not rely on the rubber crutches
> overglorified scripting platforms like Java have taught people to put blind
> faith in.

Java? Scripting platform? Oh, PUH-LEEZE. You can't script in Java. Too 
much static main this and class that boilerplate needed, plus you have 
to *compile* it and everything. You can't just write a few lines of code 
in a .java file, sic some interpreter on it, and away you go, unlike say 
Python.

As for GC being "rubber crutches": see above.

> What ever happened to competent coders?

They've all seen C++ for the unholy mess it is and migrated to languages 
like Java, Scala, and Clojure that let you get something done without 
worrying about micromanaging memory? Now if only we could stop worrying 
about streams and window handles and other such nonsense too and have 
the computer automation take care of those sorts of niggling details 
too, as is the computer's job. :)

> There is no idiot-proof system.

Hence your characterization of Java as one seems to be rather flawed.

> If you don't know how to manage storage, you shouldn't be allocating
> it.

Who says they don't know how to? Maybe they just don't *want* to, when 
the computer is perfectly capable of doing it for them, reliably and 
error-free.

Do you think they should also do all sorts of arithmetic manually 
instead of having the computer do it faster and more reliably, too?

Take that to its logical conclusion and all computers "should" be used 
for is playing Quake, while real work is done entirely by hands-on human 
labor.

How positively Luddite of you.

>> Also, I find the OO notation a little quirky.
> 
> That's a tough proposition from someone advocating C++. C++ notation is
> hideous, obfuscated, and error-prone. It's one of the least readable (maybe
> the worst in that regard) of any of the languages in common use.

Funnily enough, it's similar to Java notation. Of course, you might find 
CLOS notation worse -- all those parentheses. Smalltalk too -- no actual 
monolithic class file, just individual methods browsable from a list, 
and possibly mixed in with methods of other classes when dumped to a 
file. C# is like Java, with some funky extras. Am I missing any? Oh, 
yeah, Modula 3. And don't get me started on Objective C...

> Ada is readable. It's clean, it's orderly, it's so much better and safer
> than C++ that there isn't any comparison at all.

And it's at least as verbose as Java. Eeeuw. If you can cope with deeply 
nested parentheses, Lisp FTW. Otherwise maybe stick with C? :)

> But that is certainly all
> lost on somebody who believes it's impossible to manage memory properly

I doubt any of us do so. Indeed, a counterexample seems to be Sun's 
Hotspot GC, which seems to manage memory properly. I've never known it 
to make a mistake, so it *must* be possible.

> and thinks garbage collection is a must-have for any language.

I'm more worried about the wackos that think manual memory management is 
a must-have.

>> My own language choice now would be Java or C#. I am investigating Clojure
>> since I always have a fondness for Scheme/Lisps, and a modern Lisp on the
>> JVM solves a lot of problems.
> 
> Well yes, if you don't know how to code and if you don't understand
> fundamental aspects of software engineering like resource management, you

Horsefeathers.

> the "protect me from myself" platforms like Java

Codswallop.

> and C#.

Blatherskite.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[learn2code]

["Followup-To:" header set to comp.lang.ada.]
On 2009-07-29, Oxide Scrubber <jharriman@hatlop.de> wrote:
> learn2code@yourdesk.com wrote:
>> ["Followup-To:" header set to comp.lang.ada.]
>
> Sorry, no can do. You write complete nonsense in four newsgroups, you 
> get corrected in four newsgroups.

Same to you. Besides, I was just responding to the silly post, if he hadn't
splattered his goo all over usenet my response would have been in one group
as well.

>> On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:
>>> fft1976 <fft1976@gmail.com> writes:
>> 
>>> My problem with it is the lack of a garbage collection. That is just not
>>> acceptable to me these days. If you manually allocate memory, then you
>>> pretty much have memory bugs, it's as simple as that.
>> 
>> That is simply not true. If you don't know how to do resource management
>> properly, you're not ready to write commercial code in any environment.
>
> What utter balderdash. You make GC sound like training wheels

Exactly what it is, excellent characterization!

> when in fact it is very useful even for major production-code systems.

No, it's not useful or even necessary at all unless you have a virtual
machine or other runtime. I work on large systems and we write all our code
in assembler. We don't have GC, we just know how to code. Simple is good for
performance, for readability, and for just about everything else. That's
another reason I like Ada, at least through the 95 version.

I would hate to see the "major production-code system" that relied on GC. I
can tell you this with certainty, no bank, insurance company, airline, or
any other online realtime operation uses such nonsense. Of course they have
some bits here and there written in C++ but the code that keeps them online
and serving customers is written in COBOL, assembler or Ada and doesn't need
or have GC. That's production.

If you're talking about academic (know-nothing) or hobbyist languages I can
understand how GC would be a virtue along with all the other mind-numbing
"improvements" made over the years.

> Consider memory management of an object that is shared and passed around 
> at need among many related parts of a program. Keeping track of when 
> it's no longer in use rapidly becomes nontrivial as the complexity of 
> the code using it goes up. Eventually, you'll be reference counting or 
> doing something else like that, and before long, you'll end up with an 
> ad-hoc, informally specified, slow, bug-ridden implementation of half of 
> a garbage collector. (This will probably in turn be a part of an ad-hoc, 
> informally specified, slow, bug-ridden implementation of half of Common 
> Lisp.)

This is how most uninformed people deal with fundamental lack of knowledge
and discipline in the design and coding of systems of any significant size
and scope. They just go from bad to worse by using spit and bailing wire
instead of understanding the issues and avoiding fundamentally incorrect and
inappropriate practices and language implementations. Know your tools and
you can avoid these problems entirely.

Reference counting and other such silly schemes are as much rubber crutches
as GC. All of the need for this sort of rubbish is based on the basic
inability to design and implement properly. If you would just have control
and understand your platform, all of these problems would go away.

> Why not save yourself the trouble and use a real GC, then? Especially 
> since a properly-used GC will actually improve execution speed.

Because we have never needed them. And nobody else does unless they want to
strap themselves into Java or other bloated run-time systems, as I
said. Traditional compiled languages have no need for GC.

>> Garbage collection is a throwback to interpreted languages and bloated
>> run-time systems.
>
> Poppycock.

And then you go on to give examples of interpreted languages with bloated
runtimes like Lisp, Smalltalk, Clojure, etc. We don't get fooled by VMs,
they're still interpreters. Compiled code runs on bare metal with no
runtime. That's the distinction.

>> Normal compiled languages get along very well without any such thing
>> at all.
>
> Many implementations of Common Lisp are compiled. All have GCs. Are none 
> of them "normal" compiled languages?

No, they're still based on run-time systems and have fundamental flaws that
create the need for GC. At any rate, they're not used in large systems and
not where performance is essential. I don't have any interest in those sorts
of applications. Academic computing is only interesting to academics. I work
on code that has to work and has to perform. None of the languages you
mention will do for any serious sort of work.

>> You need to understand your tools and not rely on the rubber crutches
>> overglorified scripting platforms like Java have taught people to put
>> blind faith in. What ever happened to competent coders?
>
> They've all seen C++ for the unholy mess it is

On this we agree!

> and migrated to languages like Java, Scala, and Clojure that let you get
>something done without worrying about micromanaging memory?

Memory and resource management generally are fundamental aspects of software
engineering discipline. Java is not a language, it's a scripting platform on
a dedicated VM. It's not progress to dumb-down programming to where you need
GQ and a VM and then say why should we worry about micromanaging? It's all
in the details. I think you ought to have total control over what you're
writing and how it works and some of the languages that offer that better
than others are of course assembler but include Ada.

> Now if only we could stop worrying about streams and window handles and
>other such nonsense too and have  the computer automation take care of
>those sorts of niggling details too, as is the computer's job. :)  

That's a fundamental point of disagreement. I don't want anything done for
me. I'll tell the machine what to do, and that's what I want. The father
you get from your hardware, the less efficient your executable, the less
control you have, and the more protection from yourself you need. I don't
want anybody to blame but myself.

If you don't agree, then why stop there? Just write application and code
generators and be done with it.

> Funnily enough, it's similar to Java notation.

That's not by accident, that's by ripoff.

> Of course, you might find CLOS notation worse -- all those
> parentheses. Smalltalk too -- no actual  monolithic class file, just
> individual methods browsable from a list,  and possibly mixed in with
> methods of other classes when dumped to a  file. C# is like Java, with
> some funky extras. Am I missing any? Oh,  yeah, Modula 3. And don't get
> me started started on Objective C... 

The pattern seems to be that OO implementations are necessarily inefficient
compared to their predecessors and as a result of a few years of relying on
their self-protection, coders have become less and less competent, further
away from the machine, and more dependent on nannying. I don't approve of
this. I don't want my car to drive itself to the store, I'll steer it, use
the gas and brakes, and make it do what I want, thanks very much.

I realize every so-called coder under the age of 30 has been brainwashed
into thinking OO is the silver bullet but that's simply not the case. This
misapplication and misimplementation of OO has done far more damage than
good and now we are seeing the results as people become more reliant on
self-protection and less and less capable of doing anything themselves
without 3rd party libraries, GC, and layer upon layer of middleware,
etc. Where does it stop?

>> Ada is readable. It's clean, it's orderly, it's so much better and safer
>> than C++ that there isn't any comparison at all.
>
> And it's at least as verbose as Java. Eeeuw. If you can cope with deeply 
> nested parentheses, Lisp FTW. Otherwise maybe stick with C? :)

Ada is not verbose at all. I don't understand how you can make that
statement. Java is a sloppy mess like its cousins. Ada makes reading the
code simple and that was a design goal of Ada.

> I'm more worried about the wackos that think manual memory management is 
> a must-have.

And why is that? Is personal responsibility somehow not relevant to coding?
Is understanding your hardware and making it do what you want no longer the
goal of programming?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

learn2code@yourdesk.com writes:

> ["Followup-To:" header set to comp.lang.ada.]
> On 2009-07-29, Oxide Scrubber <jharriman@hatlop.de> wrote:
>> What utter balderdash. You make GC sound like training wheels
>> when in fact it is very useful even for major production-code systems.
>
> No, it's not useful or even necessary at all unless you have a virtual
> machine or other runtime. I work on large systems and we write all our code
> in assembler. We don't have GC, we just know how to code. Simple is good for
> performance, for readability, and for just about everything else. That's
> another reason I like Ada, at least through the 95 version.
>
> I would hate to see the "major production-code system" that relied on GC. I
> can tell you this with certainty, no bank, insurance company, airline, or
> any other online realtime operation uses such nonsense. 

That sentence is false.  

ITA Software http://itasoftware.com/ has at least one airline company
using their products and they're written in Common Lisp including a
garbage collector.

There are insurance companies (and banks, but I know specifically of
an insurance company) that use Smalltalk (they periodically hire
Smalltalk programmers in France), which of course works with a garbage
collector.


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Oxide Scrubber]

learn2code@yourdesk.com wrote:
> ["Followup-To:" header set to comp.lang.ada.]

Sorry, no can do. You post tripe to four newsgroups, you get corrected 
in four newsgroups.

> On 2009-07-29, Oxide Scrubber <jharriman@hatlop.de> wrote:
>> learn2code@yourdesk.com wrote:
>>> ["Followup-To:" header set to comp.lang.ada.]
>> Sorry, no can do. You write complete nonsense in four newsgroups, you 
>> get corrected in four newsgroups.
> 
> Same to you.

But I don't write nonsense, unlike you.

> Besides, I was just responding to the silly post, if he hadn't
> splattered his goo all over usenet my response would have been in one group
> as well.

Ray Blaak's post did not strike me as either "silly" or "goo".

>>> On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:
>>>> fft1976 <fft1976@gmail.com> writes:
>>>> My problem with it is the lack of a garbage collection. That is just not
>>>> acceptable to me these days. If you manually allocate memory, then you
>>>> pretty much have memory bugs, it's as simple as that.
>>> That is simply not true. If you don't know how to do resource management
>>> properly, you're not ready to write commercial code in any environment.
>> What utter balderdash. You make GC sound like training wheels
> 
> Exactly what it is

Bull.

>> when in fact it is very useful even for major production-code systems.
> 
> No, it's not useful

Ridiculous.

> I work on large systems and we write all our code in assembler.

Then may God have mercy on your soul.

> Simple is good for performance, for readability, and for just about
> everything else.

Assembly is good for ought but performance. For readability? Ludicrous.

> I would hate to see the "major production-code system" that relied on GC.

Well too bad, because there's more and more of them every day and some 
such confrontation is inevitable, probably the next time you use a web 
server since so many of them use JSP or other JVM-based technologies.

> I can tell you this with certainty, no bank, insurance company, airline, or
> any other online realtime operation uses such nonsense.

Folderol. Lots of these use Java on their web sites.

> Of course they have some bits here and there written in C++ but the code
> that keeps them online and serving customers is written in COBOL, assembler
> or Ada

Rubbish. Dollars to doughnuts they all use ten times as much Java as Ada.

> That's production.

No, that's hokum, directly out of your very own fertile imagination.

> If you're talking about academic (know-nothing) or hobbyist languages I can
> understand how GC would be a virtue along with all the other mind-numbing
> "improvements" made over the years.

GC is hardly restricted to "academic or hobbyist languages". Java, for 
one, is neither. There are also practical uses for Lisp and, though it's 
really *not* a very good idea, technically for C# also.

>> Consider memory management of an object that is shared and passed around 
>> at need among many related parts of a program. Keeping track of when 
>> it's no longer in use rapidly becomes nontrivial as the complexity of 
>> the code using it goes up. Eventually, you'll be reference counting or 
>> doing something else like that, and before long, you'll end up with an 
>> ad-hoc, informally specified, slow, bug-ridden implementation of half of 
>> a garbage collector. (This will probably in turn be a part of an ad-hoc, 
>> informally specified, slow, bug-ridden implementation of half of Common 
>> Lisp.)
> 
> This is how most uninformed people deal with fundamental lack of knowledge
> and discipline in the design and coding of systems of any significant size
> and scope. They just go from bad to worse by using spit and bailing wire
> instead of understanding the issues and avoiding fundamentally incorrect and
> inappropriate practices and language implementations. Know your tools and
> you can avoid these problems entirely.

The "spit and bailing wire" would be destructors, auto_ptr, 
roll-your-own reference counted pointers, and so forth, of course.

> Reference counting and other such silly schemes are as much rubber crutches
> as GC.

There are significant applications that cannot be developed without one of:
1. Reference counting.
2. GC.
3. Memory leaks.

Smart programmers avoid #3, and really smart ones avoid #1 as well, 
since it copes poorly with circular data structures. :)

> All of the need for this sort of rubbish is based on the basic
> inability to design and implement properly.

Nonsense.

> If you would just have control and understand your platform, all of these
> problems would go away.

BS.

>> Why not save yourself the trouble and use a real GC, then? Especially 
>> since a properly-used GC will actually improve execution speed.
> 
> Because we have never needed them.

Speak for yourself.

> And nobody else does unless they want to strap themselves into Java or
> other bloated run-time systems, as I said.

Yes, you did say that, along with quite a lot of other tripe.

> Traditional compiled languages have no need for GC.

Utter crap. Common Lisp is a glaring counterexample; often compiled to 
native code.

>>> Garbage collection is a throwback to interpreted languages and bloated
>>> run-time systems.
>> Poppycock.
> 
> And then you go on to give examples of interpreted languages with bloated
> runtimes like Lisp, Smalltalk, Clojure, etc.

Codswallop.

1. All of those tend to be bytecode-compiled. I'm unaware of any
    Smalltalk dialect that's interpreted, and the only implementation of
    Clojure thus far also compiles to bytecode. And then, via JIT, to
    native code. Many Lisps are directly compiled to native code.
2. The "bloated runtimes" you speak of are a result of having a large,
    featureful standard library and using much of it, instead of the
    impoverished, miserable excuse for one that C/C++ comes with. (What,
    no graphics? Sound? Networking? Threads? Memory-mapped file I/O? Oh,
    come ON! You can't even write a portable C++ app with a real user
    interface FFS.) This has nothing whatsoever to do with either GC or
    compiled vs. interpreted.
3. Some of the most bloated apps it's ever been my displeasure to
    audit via top and ps were written in C++. DESPITE C++'s lack of a
    really featureful standard library.


> We don't get fooled by VMs, they're still interpreters.

What a silly thing to say.

> Compiled code runs on bare metal with no runtime. That's the distinction.

Bunkum. If that were true, then the only "compiled code" in existence 
would be operating system kernels. Which are often written in assembly, 
NOT compiled.

Yeesh.

>>> Normal compiled languages get along very well without any such thing
>>> at all.
>> Many implementations of Common Lisp are compiled. All have GCs. Are none 
>> of them "normal" compiled languages?
> 
> No, they're still based on run-time systems and have fundamental flaws that
> create the need for GC.

Bullshit. Name one such "fundamental flaw".

> At any rate, they're not used in large systems and not where performance
> is essential.

Horsefeathers. Lisp has been used in a lot of performance-requiring 
applications, including on NASA fucking space probes. Ever heard of 
"Deep Space 1"? As for "large systems", some very large ecommerce 
companies have used Lisp to implement very large databases or web apps.

Java is used even more in such situations (excluding NASA probes).

> I don't have any interest in those sorts of applications. Academic
> computing is only interesting to academics.

Large order-fulfillment systems are "academic computing" to you?

Then you truly are lost.

> I work on code that has to work and has to perform.

As do I.

> None of the languages you mention will do for any serious sort of work.

Balderdash.

>>> You need to understand your tools and not rely on the rubber crutches
>>> overglorified scripting platforms like Java have taught people to put
>>> blind faith in. What ever happened to competent coders?
>> They've all seen C++ for the unholy mess it is
> 
> On this we agree!
> 
>> and migrated to languages like Java, Scala, and Clojure that let you get
>> something done without worrying about micromanaging memory?
> 
> Memory and resource management generally are fundamental aspects of software
> engineering discipline.

True. Although a little automation can go a long way, as it can in many 
areas of endeavor.

> Java is not a language, it's a scripting platform

Ludicrous.

> I think you ought to have total control over what you're writing and how
> it works

Then you should not be posting anywhere but comp.lang.asm.*.

>> Now if only we could stop worrying about streams and window handles and
>> other such nonsense too and have  the computer automation take care of
>> those sorts of niggling details too, as is the computer's job. :)  
> 
> That's a fundamental point of disagreement.

I would not be surprised if you disagreed with me if I said the Klein 
4-group was abelian, so you'll pardon me if I don't consider your 
statement here to be very informative or meaningful. :)

> I don't want anything done for me.

Fine. But not every programmer feels as you do.

> I'll tell the machine what to do, and that's what I want. The father
> you get from your hardware, the less efficient your executable

Poppycock. I've got Clojure code right here that takes arithmetic 
expressions, massages them in various ways, compiles up some Java byte 
code, lets the Hotspot server JIT have at it, and winds up running at 
the same speed as hand-tuned assembly. Except that it can cobble this 
stuff up on the fly from Lisp s-expressions constructed or obtained at 
run-time.

Try doing THAT with actual assembly.

Clojure sits on Java, sits on JVM bytecode, sits on C/C++ implementation 
of JVM, sits on assembly, sits on x86 bare metal yet can do something as 
efficiently as assembly -- self-modifying machine code even -- and yet 
do so much more safely and from the comfort of a high level language 
with garbage collection.

You lost this fight the instant you picked it, because you are, quite 
simply, dead wrong.

> the less control you have

A properly designed HLL provides ways to gain back some control if need 
be. Java has WeakReference, finalizers, and other means to gain back 
some from the GC when necessary (which is rarely). It has JNI and JIT 
for when you need assembly's speed or to interface to C libraries. Lisps 
tend to have some form of foreign function interface (Clojure can easily 
call Java code, so Java foreign functions are easy there; indirectly it 
can call C foreign functions via Java code that uses JNI.)

> and the more protection from yourself you need.

Ridiculous. You need "more protection from yourself" when you're doing 
raw pointer arithmetic and unchecked casts and crap like that. In other 
words, C and assembly. And that's when you have the least protection.

> I don't want anybody to blame but myself.

Well, then you'll just have to go into the woods, use some vines and 
sticks to make a crude shovel, dig up some dirt, make a fire, somehow 
manage to forge silicon chips in the dirt, mine other materials with 
your bare hands, slap together a ZX Spectrum kit or something from all 
this, assemble it, and start toggling in an operating system and 
compiler one opcode at a time.

Most of us prefer to use the fruits of industrial civilization, even 
though sometimes that means getting hit by other peoples' bugs. *shrug*

> If you don't agree, then why stop there? Just write application and code
> generators and be done with it.

Be sure to let me know when they've solved strong AI, and then I'll do that.

>> Funnily enough, it's similar to Java notation.
> 
> That's not by accident

Whoosh!

>> Of course, you might find CLOS notation worse -- all those
>> parentheses. Smalltalk too -- no actual  monolithic class file, just
>> individual methods browsable from a list,  and possibly mixed in with
>> methods of other classes when dumped to a  file. C# is like Java, with
>> some funky extras. Am I missing any? Oh,  yeah, Modula 3. And don't get
>> me started started on Objective C... 
> 
> The pattern seems to be that OO implementations are necessarily inefficient
> compared to their predecessors

Piffle.

> and as a result of a few years of relying on their self-protection, coders
> have become less and less competent, further away from the machine, and more
> dependent on nannying.

Poppycock.

> I don't want my car to drive itself to the store, I'll steer it, use
> the gas and brakes, and make it do what I want, thanks very much.

Luddite.

> I realize every so-called coder under the age of 30 has been brainwashed
> into thinking OO is the silver bullet but that's simply not the case.

Indeed; functional is the silver bullet. OO is only bronze.

> This misapplication and misimplementation of OO has done far more damage
> than good and now we are seeing the results as people become more reliant
> on self-protection and less and less capable of doing anything themselves
> without 3rd party libraries, GC, and layer upon layer of middleware, etc.

Hogwash.

> Where does it stop?

With the signing of your civil commitment papers.

>>> Ada is readable. It's clean, it's orderly, it's so much better and safer
>>> than C++ that there isn't any comparison at all.
>> And it's at least as verbose as Java. Eeeuw. If you can cope with deeply 
>> nested parentheses, Lisp FTW. Otherwise maybe stick with C? :)
> 
> Ada is not verbose at all.

Fiddle-faddle. Unless it has syntactic abstraction, anyway.

> I don't understand how you can make that statement.

It's quite simply, really. First I typed an 'A', then an 'n', then a 'd' 
and a space, then "it's", and "at", and "least" and "as", and "verbose", 
and "as" again, and then, finally, "Java" and a period.

You really ought to try it sometime.

> Java is a sloppy mess like its cousins.

Yes, it is. Fortunately, Lisp isn't.

> Ada makes reading the code simple and that was a design goal of Ada.

They said that about BASIC too.

>> I'm more worried about the wackos that think manual memory management is 
>> a must-have.
> 
> And why is that? Is personal responsibility somehow not relevant to coding?

Non-sequitur. The one has nothing whatsoever to do with the other. 
Unless you genuinely believe that the use of automation and personal 
responsibility are mutually exclusive, in which case there's a 
hunter-gatherer tribe out there somewhere that is missing its village idiot.

> Is understanding your hardware and making it do what you want no longer the
> goal of programming?

It still is if you're just a hobbyist hacker. Us professionals are in 
the business of understanding customers' hardware and making it do what 
they want at their push of some buttons. :)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[oxhiderubber]

Oxide Scrubber whined as follow:

> Assembly is good for ought but performance. For readability? Ludicrous.

You just don't seem to have a clue, but you sure have a lot of silly
uninformed prejudices. As with most languages, readability depends on the
coder much more than the language. Of course this can still be a problem
with some languages, but assembler is not one of them. Because of the
structure of assembler there is plenty of white space for comments as
opposed to languages with statements hundreds of characters long.

>> I would hate to see the "major production-code system" that relied on GC.
>
> Well too bad, because there's more and more of them every day and some 
> such confrontation is inevitable, probably the next time you use a web 
> server since so many of them use JSP or other JVM-based technologies.

Ah, now I see the problem. You're talking about silly GUIs as if they were
"major production systems" They aren't, and you're even more out of touch
with reality than I first understood from your other silly posts. No money
moves on web servers, nothing important happens there, they're just
front-ends. More likely than not, the businesses had preexisting ways of
interfacing with customers and just added web-enablement on top of existing
applications. Do you understand this concept? All of the financial
transactions happen on back-end systems (the "major production code
systems") written in assembler and COBOL. None of this happens in toy
languages like Java and very, very little I'm aware of in C++.

>> I can tell you this with certainty, no bank, insurance company, airline,
>> or any other online realtime operation uses such nonsense.
>
> Folderol. Lots of these use Java on their web sites.

No, you don't seem to be able to distinguish front-ends from back-ends. Let
me help you: front-ends are where data is displayed and gathered. Back-ends
are where the real work gets done. Web sites are just e-commerce toys, they
are just viewers. They don't actually *do* anything, much like you, I
suppose.

No major operation uses GC in back-end processing, performance is too
important and time windows are short. None of the languages that major
production systems are written in (COBOL, Assembler, Ada) have or need GC.

> GC is hardly restricted to "academic or hobbyist languages". Java, for 
> one, is neither. There are also practical uses for Lisp and, though it's 
> really *not* a very good idea, technically for C# also.

Those are all toy languages used for GUIs and web apps, and no commercial
back-ends are written in them. Yes, I understand you think putting data on a
colored screen is "major production code" but you're very sadly mistaken. I
suppose you might even be a troll for MS. Guess what? No money moves on MS
or tiny little x86 boxes either, it moves on mainframes.

> There are significant applications that cannot be developed without one
> of: 
> 1. Reference counting.
> 2. GC.
> 3. Memory leaks.

Wrong. We do it all the time. Take a course in data structures some time,
you might be amazed at what a competent designer can do without your
imaginary limitations. We design and sell performance software to Fortune
500 companies and if we leak memory or don't perform there's no second
chance. We just understand what we are doing, and don't depend on other
people solving our problems by creating new ones.

>> If you would just have control and understand your platform, all of these
>> problems would go away.
>
> BS.

Not a very convincing argument! But then nothing you've said has been, it's
mostly furious vitriol because your "arguments" are all empty and based on
your severely limited view of reality and your complete ignorance of what
production systems do and are.

>> Because we have never needed them.
>
> Speak for yourself.

I just did, are you unable to read? In my business we have never needed
them. Don't you get it? The problems are because you don't understand how to
design systems, how to code, or what actually gets executed on the
machine. If you did that, you would understand why all of what you are
saying is nonsense. You're too far away from what actually happens to have a
clue. 

> 3. Some of the most bloated apps it's ever been my displeasure to
>     audit via top and ps were written in C++. DESPITE C++'s lack of a
>     really featureful standard library.

You have no argument from me, although I'm sure the C++ camp can find 10,000
awful Java programs for every bad C++ program. Java is for people who're too
stupid to be able to code in C++, and need even more protection from
themselves.

>> We don't get fooled by VMs, they're still interpreters.
>
> What a silly thing to say.
>
>> Compiled code runs on bare metal with no runtime. That's the distinction.
>
> Bunkum. If that were true, then the only "compiled code" in existence 
> would be operating system kernels. Which are often written in assembly, 
> NOT compiled.

You just don't have a clue. More COBOL is in production doing real back-end
work than all of your silly academic and GUI languages combined. It's all
compiled and runs on metal.

> Large order-fulfillment systems are "academic computing" to you?

You don't understand that the back-ends of order fulfillment systems are not
written in interpreted languages. Only the GUIs are.

> Then you should not be posting anywhere but comp.lang.asm.*.

Ah I see if someone disagrees with you aside from shouting balderdash and
poppycock dozens of times, you also direct them to places you won't have to
answer them. Anyway comp.lang.asm is for assembly on toy computers such as
you use, not the sort we work on.

> Fine. But not every programmer feels as you do.

That's because they're not programmers. They just imagine they are.

If you don't know what the machine is doing with your code, you're not a
programmer. You're just an end-user like a guy watching TV, driving a car,
etc. Programming is about knowing exactly how to tell the machine to do what
you want it to do, and to be able to verify that it is happening as it
should. If you can't do that, you're just playing video games like any other
moron.

Feel free to continue to masturbate in public on your own time. I've no
interest in watching you.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

learn2code@yourdesk.com wrote:
> I would hate to see the "major production-code system" that relied on GC.
> I can tell you this with certainty, no bank, insurance company, airline,
> or any other online realtime operation uses such nonsense. Of course they
> have some bits here and there written in C++ but the code that keeps them
> online and serving customers is written in COBOL, assembler or Ada and
> doesn't need or have GC. That's production.

That has not been true for decades. Here is a trivial counter example of
Jane St. Capital using OCaml in the finance industry:

  http://ocaml.janestreet.com/?q=node/61

My company specializes in the use of OCaml and F# for high performance
technical computing including scientific computing and finance. These
garbage collected languages are common there precisely because they make it
easy to implement complicated algorithms and data structures very
efficiently.

For example, I recently implemented QR decomposition via Householder
reductions in F# that was generic over the element type. I wrote it for fun
but it turned out to be 3x faster than the Intel MKL and 35x shorter than
the reference implementation in LAPACK.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Dmitry A. Kazakov wrote:
> There are relationships between the object and its clients around the
> program which are far more complex and beyond "you die before me", the
> only relationship maintained by GC.

That is incorrect. You are describing reference counting.

> The point is, relationships between objects is key a part of OO design. To
> leave that to GC in hope that it will somehow sort out things is
> irresponsible. It did not, does not and it will not do.

Note that you were long since disproven by the JVM and CLR.

>> Why not save yourself the trouble and use a real GC, then?
> 
> Sure, by using scoped objects whenever possible. That is 90% of all cases.

Functional programming languages are trivial counter examples. Scope alone
cannot even support first-class lexical closures.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Wed, 29 Jul 2009, learn2code@yourdesk.com wrote:

|----------------------------------------------------------------------------|
|"On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:              |
|> fft1976 <fft1976@gmail.com> writes:                                       |
|                                                                            |
|> My problem with it is the lack of a garbage collection. That is just not  |
|> acceptable to me these days. If you manually allocate memory, then you    |
|> pretty much have memory bugs, it's as simple as that.                     |
|                                                                            |
|That is simply not true. If you don't know how to do resource management    |
|properly, you're not ready to write commercial code in any environment.     |
|                                                                            |
|[..]                                                                        |
|                                                                            |
|> Also, I find the OO notation a little quirky.                             |
|                                                                            |
|That's a tough proposition from someone advocating C++. [..]                |
|                                                                            |
|[..]"                                                                       |
|----------------------------------------------------------------------------|

Ray Blaak has written commercial code and he prefers Ada instead of C++.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ray Blaak]

learn2code@yourdesk.com writes:
> Garbage collection is a throwback to interpreted languages and bloated
> run-time systems. Normal compiled languages get along very well without any
> such thing at all.

GC is an advancement of the state of the art. In general, GC manages memory
better than people do.

Is it always appropriate? No, it depends on what you are doing. Sometimes you
need precise control. Fair enough.

But the default of no GC forces the programmer to spent artificial effort on
the memory management problem that could be better spent elsewhere.

Hmm, this is also directed to comp.lang.ada. I recall debating this here
before. Just google "GC" and my name for another thread arguing about GC in
cla.

> > Also, I find the OO notation a little quirky.
> 
> That's a tough proposition from someone advocating C++. C++ notation is
> hideous, obfuscated, and error-prone. It's one of the least readable (maybe
> the worst in that regard) of any of the languages in common use.

I was not advocating C++. I despise it too.

There is nothing "wrong" with the Ada notation. It is just that my way of
thinking prefers to conceptualize objects owning methods,
e.g. obj.doSomething() vs doSomething(obj).

That is just my preference.

Actually doesn't Ada 2005 allow obj.method notation in more circumstances?

> Well yes, if you don't know how to code and if you don't understand
> fundamental aspects of software engineering like resource management, you
> definitely shouldn't be writing code for commercial or industrial
> environments and you probably should be using the "protect me from myself"
> platforms like Java and C#. I can understand your post better now.

Your debating style sucks. No need to be insulting just because I don't agree
with you about GC. I have reasons and experience with using GC and not using
GC, and I can back up my positions. I can also see the arguments for
preferring explicit manual control.

And you know, we can still validly disagree.

Just don't be an asshole about things.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 29, 9:11 am, Ray Blaak <rAYbl...@STRIPCAPStelus.net> wrote:
> fft1976 <fft1...@gmail.com> writes:
> > >      - Ada is best suited for large teams and/or critical software, thus
> > > it may be overkill for my work, OTH it could have anything I might
> > > happen to need.
>
> Ada is fine as far as it goes, and there is a GNU Ada compiler which helps a
> lot.
>
> My problem with it is the lack of a garbage collection. That is just not
> acceptable to me these days. If you manually allocate memory, then you pretty
> much have memory bugs, it's as simple as that.

There's little demand for GC from Ada users for a number of reasons:

1) You very rarely need to explicitly manage memory using Ada -
there's a shed load of predefined containers should you need lists,
vectors, set, etc. and you rarely need to dynamically allocate
anything on a heap - there's just other ways to do it.

2) The traditional non-deterministic nature of when and for how long a
GC was going to run ruled it out for a lot of Ada systems.

Real-time Java (see Aonix's PERC) seems to have got round the non-
deterministic problems but that still doesn't mean there will be an
similar extension to Ada, as there are still ways to do it would
recourse to pointers et al.


> It's better than C/C++ for sure, but I remember plenty of memory exceptions all
> the same.
>
> Also, I find the OO notation a little quirky.

Obj.Method is now supported for classes.

> > Ada is also 2x slower, but less suitable for your purposes (verbose,
> > less memory safe than OCaml, free compilers produce GPL-only code)
>
> I am pretty sure the GPL-only thing is not true.

FSF versions allow you to produce proprietary programs, GNAT GPL 200x
versions do not.

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Martin wrote:
> There's little demand for GC from Ada users for a number of reasons...

The main reason is surely that they are self-selected: former Ada
programmers who wanted the benefits of garbage collection migrated to other
languages and do not demand GC for Ada.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

On 28 Lug, 22:57, fft1976 <fft1...@gmail.com> wrote:
> P.S. I was going to write a 3-sentence reply, but got carried away. I
> hope this wasn't a troll...
>
> My needs are similar to yours, and I've been looking for better
> languages and learning them for years.
>
> In summary: everything sucks, when you look close enough.
With respects to other posters, that's what I'm thinking, but I
believe it's unavoidable, that's reality.

> OCaml should probably be your #1 choice (about 2x slower than C
> usually, single core). Has its own flaws (Google "Ocaml sucks")
That's why it was discarded. It differs a lot from other algol's
relatives and I don't have the time to check how much it (doesn't) suck
(s).

> Ada is also 2x slower,
Are you sure?
> but less suitable for your purposes (verbose,
I have to say that translating my C graph library with Ada, leaving
aside memory management, lead to shorter and readable code, something
I've been dreaming of for the past 3 years

> C++: learning curve and safety are the main problems. I'm way past the
> former, and I use Visual Studio Debug mode (I develop cross-platform
> code) when there is any sign of memory problems (not frequent), but
> it's still not completely safe.
I have my own reason not to use C++ ;)

Andrea

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jon Harrop]

Andrea Taverna wrote:
>> OCaml should probably be your #1 choice (about 2x slower than C
>> usually, single core). Has its own flaws (Google "Ocaml sucks")
>
> That's why it was discarded.

From your options?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[tmoran]

> Ada is also 2x slower,
  Where'd you get that idea?
When comparing to C, you should remember to turn off all run-time
checking, but even with it all on normal code shouldn't have more than a
10-15% slowdown.  Note that Gnat uses the same code generator as Gnu C, so
one would expect the same semantics to generate the same code and run at
the same speed.  And if you are calling a library of course they would be
the same.  Note also that it's very easy, and safer, in Ada to use
multiple cores, on those occasions when that would help.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 29, 7:11 pm, tmo...@acm.org wrote:
> > Ada is also 2x slower,
>
>   Where'd you get that idea?

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gnat&box=1

Of the languages I commented on, I actually know Ada the least, so
take it up with the shootout authors (no bitching to me, please). I
actually think the Ada was run in the shootout with all safety OFF.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Paul Rubin]

fft1976 <fft1976@gmail.com> writes:
> > � Where'd you get that idea?
> http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gnat&box=1

Given that Ada is such a verbose language, the generally smaller
source sizes of the Ada programs suggests that they weren't optimized
very carefully.  I know that some C, Java, and functional language
users treat the shootouts fairly competitively and tune their code
carefully, but I don't know if the Ada users are the same way.  Ada
is unfortunately kind of a niche language these days.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> fft1976 <fft1...@gmail.com> writes:
> > >   Where'd you get that idea?
> >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...
>
> Given that Ada is such a verbose language, the generally smaller
> source sizes of the Ada programs suggests that they weren't optimized
> very carefully.  I know that some C, Java, and functional language
> users treat the shootouts fairly competitively and tune their code
> carefully, but I don't know if the Ada users are the same way.  Ada
> is unfortunately kind of a niche language these days.

This is a hypotheses you are entertaining, right? Or did you notice
anything "suboptimal" in the Ada code?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Paul Rubin]

fft1976 <fft1976@gmail.com> writes:
> This is a hypotheses you are entertaining, right? 

Yes.

> Or did you notice anything "suboptimal" in the Ada code?

I haven't looked at the code.  I do notice from the shootout that in
some examples, the Ada code is significantly smaller both code size
and memory consumption than the C++ code, but the Ada code is slower.
Since Ada and C/C++ have pretty similar semantics, it suggests there
was a time/memory tradeoff that was resolved in different ways between
the programmers.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

fft1976 wrote:
> On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> fft1976 <fft1...@gmail.com> writes:
>>>>   Where'd you get that idea?
>>> http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...
>> Given that Ada is such a verbose language, the generally smaller
>> source sizes of the Ada programs suggests that they weren't optimized
>> very carefully.  I know that some C, Java, and functional language
>> users treat the shootouts fairly competitively and tune their code
>> carefully, but I don't know if the Ada users are the same way.  Ada
>> is unfortunately kind of a niche language these days.
> 
> This is a hypotheses you are entertaining, right? Or did you notice
> anything "suboptimal" in the Ada code?

It is true that Ada programs have been ranking lower at the
Shootout than they did before, and the (two) reasons
are interesting.
Some time ago, many algorithms were supposed to use just the
language, and sequential programs, with few excceptions.
Now with Multicore CPUs everywhere, many Shootout programmers
have started to include threading libraries and thus
perform different algorithms, having their programs perform
devide and conquer and such.

(One might wonder whether or not having concurrency support
built into the language will become the great new thing. :-)

Last time I looked, the Ada programs had not been
updated to use Ada's concurrent types to express the same
devide and conquer strategy, which seems to be allowed now...
The reported speedups for some C versions of the programs
can be used as an estimate of a statistical correction
to the (still sequential) Ada performance.
This then will explain why a 2x slowdown of Ada,
when compared to C, is not a realistic estimate.

A second reason why Ada has dropped at the Shootout is
that the systems they use have older interim (from the Ada
point of view) GCCs that are known to be broken.
This makes some perfectly normal Ada programs fail there.
As the code is available and did not fail when it was
first ranked, and does not fail when used with an apt
compiler like GCC 4.3.x, the Shootout is just showing its
information potential ;-)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 29, 11:51 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> fft1976 wrote:
> > On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> >> fft1976 <fft1...@gmail.com> writes:
> >>>>   Where'd you get that idea?
> >>>http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...
> >> Given that Ada is such a verbose language, the generally smaller
> >> source sizes of the Ada programs suggests that they weren't optimized
> >> very carefully.  I know that some C, Java, and functional language
> >> users treat the shootouts fairly competitively and tune their code
> >> carefully, but I don't know if the Ada users are the same way.  Ada
> >> is unfortunately kind of a niche language these days.
>
> > This is a hypotheses you are entertaining, right? Or did you notice
> > anything "suboptimal" in the Ada code?
>
> It is true that Ada programs have been ranking lower at the
> Shootout than they did before, and the (two) reasons
> are interesting.
> Some time ago, many algorithms were supposed to use just the
> language, and sequential programs, with few excceptions.
> Now with Multicore CPUs everywhere, many Shootout programmers
> have started to include threading libraries and thus
> perform different algorithms, having their programs perform
> devide and conquer and such.
>
> (One might wonder whether or not having concurrency support
> built into the language will become the great new thing. :-)
>
> Last time I looked, the Ada programs had not been
> updated to use Ada's concurrent types to express the same
> devide and conquer strategy, which seems to be allowed now...
> The reported speedups for some C versions of the programs
> can be used as an estimate of a statistical correction
> to the (still sequential) Ada performance.
> This then will explain why a 2x slowdown of Ada,
> when compared to C, is not a realistic estimate.

Try again. The link above is for single-threaded code.

>
> A second reason why Ada has dropped at the Shootout is
> that the systems they use have older interim (from the Ada
> point of view) GCCs that are known to be broken.
> This makes some perfectly normal Ada programs fail there.
> As the code is available and did not fail when it was
> first ranked, and does not fail when used with an apt
> compiler like GCC 4.3.x, the Shootout is just showing its
> information potential ;-)

How would this explain Ada's slow speed? I don't understand you.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

fft1976 wrote:
> Georg Bauhaus wrote:
>> A second reason why Ada has dropped at the Shootout is
>> that the systems they use have older interim (from the Ada
>> point of view) GCCs that are known to be broken.
>> This makes some perfectly normal Ada programs fail there.
>> As the code is available and did not fail when it was
>> first ranked, and does not fail when used with an apt
>> compiler like GCC 4.3.x, the Shootout is just showing its
>> information potential ;-)
>
> How would this explain Ada's slow speed? I don't understand you.

Remember that the Shootout does not compare languages; it compares
compilers (i.e. particular implementations of some languages) combined
with programs (i.e. particular implementations of some algorithms).
So, upgrading the compiler is likely to improve the performance of Ada
programs; similarly, spending time to hand-optimize the programs is
also likely to improve their performance.

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

fft1976 schrieb:
> On Jul 29, 11:51 pm, Georg Bauhaus <rm.tsoh.plus-
> bug.bauh...@maps.futureapps.de> wrote:
>> fft1976 wrote:
>>> On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>>>> fft1976 <fft1...@gmail.com> writes:
>>>>>>   Where'd you get that idea?
>>>>> http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...

>> Last time I looked, the Ada programs had not been
>> updated to use Ada's concurrent types to express the same
>> devide and conquer strategy, which seems to be allowed now...
>> The reported speedups for some C versions of the programs
>> can be used as an estimate of a statistical correction
>> to the (still sequential) Ada performance.
>> This then will explain why a 2x slowdown of Ada,
>> when compared to C, is not a realistic estimate.
> 
> Try again. The link above is for single-threaded code.

My fault. I had more general observations in mind
which don't apply here, sorry.

So I have looked at the fasta program as an example.
It has a relation of roughly 1:2 in running time
comparing C (No.1) to Ada at Shootout.  But the relation
is easily improved without really changing the program:

First, I could confirm the relation of 1:2 on a GNU/Linux
machine.
Two changes shifted the relation towards 6.3s to ~8s
in favor of C, starting from 6.6s to ~12.5s (which
confirms the ratio 1:2).

Change 1: Add pragma Inline(Select_Random);

 I did this because it seemed like the C compiler
 would do just this. (Looking at the disassembly.)
 Have the Ada compiler inline, too.
 This made the Ada program run another 2s faster
 (i.e. down another 2s from ~10s after Change 2).

Change 2: Turn off I/O in both programs.

 While this defeats the purpose, it shows where
 much of the difference comes from:

 This change accounted for about 2s (down from ~12.5s)
 for the Ada program and for about 0.3s (down from
 ~6.6s) for the C program.  So the I/O part in C
 is obviously high speed on Unix, not surprisingly,
 and Ada.Text_IO is notoriously slow (since it is
 a lot like an even more blown up printf(3)).

Conclusions
(so far, if the above can be reproduced):

A fair bit of Ada's disadvantage is remedied by using
Inline; another drag is Text_IO which is indeed slow.
Real world needs might (and will) consider I/O
routines that use OS functions, much like C on Unix does,
more or less.

The seemingly shaky results (if confirmed) also let me
think that without constant attention, the Shootout
can give a wrong impression (for any language :).


>> A second reason why Ada has dropped at the Shootout is
>> that the systems they use have older interim (from the Ada
>> point of view) GCCs that are known to be broken.
>> This makes some perfectly normal Ada programs fail there.
>> As the code is available and did not fail when it was
>> first ranked, and does not fail when used with an apt
>> compiler like GCC 4.3.x, the Shootout is just showing its
>> information potential ;-)
> 
> How would this explain Ada's slow speed? I don't understand you.

In the overall rating, failing programs or missing programs
used to add to where a language was rated IIRC?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 30, 9:10 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:

> A fair bit of Ada's disadvantage is remedied by using
> Inline;

Can Ada be asked to inline automatically?

By the way, can the latest FSF GNAT run on Windows (MinGW) and OSX?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal Obry]

Le 30/07/2009 19:09, fft1976 a �crit :
> Can Ada be asked to inline automatically?

Yes. See gnatmake's options -gnatn and -gnatN. Some inlining are also 
done at -O3 IIRC.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 30, 10:20 am, Pascal Obry <pas...@obry.net> wrote:
> Le 30/07/2009 19:09, fft1976 a écrit :
>
> > Can Ada be asked to inline automatically?
>
> Yes. See gnatmake's options -gnatn and -gnatN. Some inlining are also
> done at -O3 IIRC.
>

I don't understand Georg's point then, unless C/C++ has explicit
"inline".

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Isaac Gouy]

On Jul 30, 10:20 am, Pascal Obry <pas...@obry.net> wrote:
> Le 30/07/2009 19:09, fft1976 a écrit :
>
> > Can Ada be asked to inline automatically?
>
> Yes. See gnatmake's options -gnatn and -gnatN. Some inlining are also
> done at -O3 IIRC.


"Activate inlining for subprograms for which pragma inline is
specified" gives the impression that both a source code change -
pragma Inline(Select_Random); - and a compiler switch change would be
needed?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Isaac Gouy schrieb:
> On Jul 30, 10:20 am, Pascal Obry <pas...@obry.net> wrote:
>> Le 30/07/2009 19:09, fft1976 a �crit :
>>
>>> Can Ada be asked to inline automatically?
>> Yes. See gnatmake's options -gnatn and -gnatN. Some inlining are also
>> done at -O3 IIRC.
> 
> 
> "Activate inlining for subprograms for which pragma inline is
> specified" gives the impression that both a source code change -
> pragma Inline(Select_Random); - and a compiler switch change would be
> needed?

In this case, yes, both  pragma Inline and -gnatn -gnatN was
used.  The Annotated Ada RM says, though, that an implementation
may inline in any case (or not), provided inlining preserves
the semantics. (6.3.2)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ludovic Brenta]

Georg Bauhaus wrote:
> A fair bit of Ada's disadvantage [compared to C] is remedied by using
> Inline; another drag is Text_IO which is indeed slow.

I'm quite sure that replacing Text_IO with streams would make the Ada
program much faster.

--
Ludovic Brenta.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Isaac Gouy]

On Jul 30, 9:10 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
-snip-
> Conclusions
> (so far, if the above can be reproduced):
>
> A fair bit of Ada's disadvantage is remedied by using
> Inline; another drag is Text_IO which is indeed slow.
> Real world needs might (and will) consider I/O
> routines that use OS functions, much like C on Unix does,
> more or less.
>
> The seemingly shaky results (if confirmed) also let me
> think that without constant attention, the Shootout
> can give a wrong impression (for any language :).


"shaky results"? Didn't you confirm those results yourself?

Sure we might hope a different program would give better results, and
instructions for contributing better programs are given in the FAQ.


-snip-
> In the overall rating, failing programs or missing programs
> used to add to where a language was rated IIRC?

Not true for the last several years.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[fft1976]

On Jul 30, 10:59 am, Isaac Gouy <igo...@yahoo.com> wrote:

> "shaky results"? Didn't you confirm those results yourself?

Perhaps he is referring to I/O being the bottleneck. I have to say, if
this is true, it undermines the usefulness of the benchmark to me.

Take it easy.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Isaac Gouy]

On Jul 30, 12:38 pm, fft1976 <fft1...@gmail.com> wrote:
> On Jul 30, 10:59 am, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > "shaky results"? Didn't you confirm those results yourself?
>
> Perhaps he is referring to I/O being the bottleneck. I have to say, if
> this is true, it undermines the usefulness of the benchmark to me.
>
> Take it easy.


His measurements suggest about 1.7s of a 6s difference might be
accounted for by slow Text_IO in programs that write 245MB.

The benchmarks game measurements are made with stdout redirected to /
dev/null - we don't know if that was also the case for the
measurements reported by Georg Bauhaus.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Paul Rubin]

Isaac Gouy <igouy2@yahoo.com> writes:
> His measurements suggest about 1.7s of a 6s difference might be
> accounted for by slow Text_IO in programs that write 245MB.
> 
> The benchmarks game measurements are made with stdout redirected to /
> dev/null - we don't know if that was also the case for the
> measurements reported by Georg Bauhaus.

If Text_IO is slow, it could be that it burns a lot of cpu doing
format conversions, or maybe it uses less buffering than stdio and
therefore does more system calls.  Redirecting to /dev/null wouldn't
make any difference to either of those.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Paul Rubin schrieb:
> Isaac Gouy <igouy2@yahoo.com> writes:
>> His measurements suggest about 1.7s of a 6s difference might be
>> accounted for by slow Text_IO in programs that write 245MB.
>>
>> The benchmarks game measurements are made with stdout redirected to /
>> dev/null - we don't know if that was also the case for the
>> measurements reported by Georg Bauhaus.
> 
> If Text_IO is slow, it could be that it burns a lot of cpu doing
> format conversions, or maybe it uses less buffering than stdio and
> therefore does more system calls.  Redirecting to /dev/null wouldn't
> make any difference to either of those.

I measured with redirection > /dev/null for both programs
and got the (expected) significant difference.

Text_IO is slow by design (being designed around page
control, column control, formatting, etc.  It's
not just moving chunks of char objects.)

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

fft1976 schrieb:
> On Jul 30, 10:59 am, Isaac Gouy <igo...@yahoo.com> wrote:
> 
>> "shaky results"? Didn't you confirm those results yourself?
> 
> Perhaps he is referring to I/O being the bottleneck. I have to say, if
> this is true, it undermines the usefulness of the benchmark to me.

I/O and a few other things are necessrily changing over time,
affecting (perceived) results.  Without intending any complaint:
programs like the fine tests presented at Shootout will
almost inevitably produce some variation along
several dimensions, and this should be expected:

- compilers change

- system libraries/services change

- I/O routines, string processing, matrix handling and
  more are different between languages, and they are not
  always srictly isolated into the test programs.
  If someone wanted to do this kind of specific comparison,
  different programs might profit from slightly different design
  guidelines than those you get for free at the Shootout.

- interpretation of result is correspondingly brittle

An example case is asking (or not) which specific part of a
program is causing its overall running time.

When changing the regex-dna program for Ada some
time ago, I noticed that the GNAT's Spitbol pattern matching
is just as fast as the other fast pattern matching specialists
at the time.  However, the Ada program gets really busy when
reassembling the result string.  So the less astute human
reader might (wrongly) interpret the regex-dna test result as
indication that pattern matching using Ada is not that fast.

Right now the same regex-dna program is failing on the
new Shootout systems; I suspect that the ubiquituous stack size
thing of newer GCCs may be causing this (dictating that stack frames
should be small, i.e. for non-Pascal languages, IIUC);
$ ulimit -s is only partly helpful.  I'm looking into this for the
knuleotide test; a patch and more on the latter in c.l.ada.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Isaac Gouy schrieb:
> On Jul 30, 9:10 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
> -snip-
>> Conclusions
>> (so far, if the above can be reproduced):
>>
>> A fair bit of Ada's disadvantage is remedied by using
>> Inline; another drag is Text_IO which is indeed slow.
>> Real world needs might (and will) consider I/O
>> routines that use OS functions, much like C on Unix does,
>> more or less.
>>
>> The seemingly shaky results (if confirmed) also let me
>> think that without constant attention, the Shootout
>> can give a wrong impression (for any language :).
> 
> 
> "shaky results"? Didn't you confirm those results yourself?

Shaky here should not refer to runs or relative runs of two
specific test programs; the results are stable.  However, the
interpretations of Shootout test comparisons are
less stable, as should be expected (more in an other
post).   So when comparing programming languages in general,
more care needs to be taken when looking at the (list of)
Shootout programs.  They _can_ be informative of language
features if looked at closely.  (I.e., a ranking does not
suffice then.)


> Sure we might hope a different program would give better results, and
> instructions for contributing better programs are given in the FAQ.

Better results of programs is not that important here, what is important
is an expectation, namely that the specific programs might demonstrate
eternally frozen, irreplaceable language properties by looking at
accumulated statistical results only.


> -snip-
>> In the overall rating, failing programs or missing programs
>> used to add to where a language was rated IIRC?
> 
> Not true for the last several years.
> 

Please accept my apologies for being authoritatively
wrong on several accounts. Sorry for misrepresenting
rules.  BTW, I couldn't think of a better way to rank
a failed program runs using compiler X and system Y
other than at list position n + k.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Isaac Gouy]

On Jul 31, 4:29 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:

> Shaky here should not refer to runs or relative runs of two
> specific test programs; the results are stable.  However, the
> interpretations ofShootouttest comparisons are
> less stable, as should be expected (more in an other
> post).   So when comparing programming languages in general,
> more care needs to be taken when looking at the (list of)Shootoutprograms.  They _can_ be informative of language
> features if looked at closely.  (I.e., a ranking does not
> suffice then.)


If we're thinking, a glance at the wide overlaps on the boxplot should
make us question the usefulness of a simple ranking:


http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&box=1


> > Sure we might hope a different program would give better results, and
> > instructions for contributing better programs are given in the FAQ.
>
> Better results of programs is not that important here, what is important
> is an expectation, namely that the specific programs might demonstrate
> eternally frozen, irreplaceable language properties by looking at
> accumulated statistical results only.


Is that a valid expectation?

Does the benchmarks game promote or subvert that expectation, or is
that a matter of how specific details are selected and highlighted in
other discussions?



> Please accept my apologies for being authoritatively
> wrong on several accounts. Sorry for misrepresenting
> rules.

Oh your information was just out of date, so that needed correction. I
didn't intend to be so heavy handed - those were ordinary mistakes.

-snip-

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Isaac Gouy]

Georg Bauhaus wrote:
> fft1976 wrote:
> > On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> >> fft1976 <fft1...@gmail.com> writes:
> >>>>   Where'd you get that idea?
> >>> http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...
> >> Given that Ada is such a verbose language, the generally smaller
> >> source sizes of the Ada programs suggests that they weren't optimized
> >> very carefully.  I know that some C, Java, and functional language
> >> users treat the shootouts fairly competitively and tune their code
> >> carefully, but I don't know if the Ada users are the same way.  Ada
> >> is unfortunately kind of a niche language these days.
> >
> > This is a hypotheses you are entertaining, right? Or did you notice
> > anything "suboptimal" in the Ada code?
>
> It is true that Ada programs have been ranking lower at the
> Shootout than they did before, and the (two) reasons
> are interesting.
> Some time ago, many algorithms were supposed to use just the
> language, and sequential programs, with few excceptions.
> Now with Multicore CPUs everywhere, many Shootout programmers
> have started to include threading libraries and thus
> perform different algorithms, having their programs perform
> devide and conquer and such.
>
> (One might wonder whether or not having concurrency support
> built into the language will become the great new thing. :-)
>
> Last time I looked, the Ada programs had not been
> updated to use Ada's concurrent types to express the same
> devide and conquer strategy, which seems to be allowed now...
> The reported speedups for some C versions of the programs
> can be used as an estimate of a statistical correction
> to the (still sequential) Ada performance.
> This then will explain why a 2x slowdown of Ada,
> when compared to C, is not a realistic estimate.


Authoritative and in this case wrong.

After the benchmarks game caught up with quad-core hardware there were
different sets of measurements - measurements of programs allowed to
use all the cores, and measurements of programs forced onto a single
core.

That URL linked to measurements of programs forced onto a single
core.



> A second reason why Ada has dropped at the Shootout is
> that the systems they use have older interim (from the Ada
> point of view) GCCs that are known to be broken.
> This makes some perfectly normal Ada programs fail there.
> As the code is available and did not fail when it was
> first ranked, and does not fail when used with an apt
> compiler like GCC 4.3.x, the Shootout is just showing its
> information potential ;-)


Authoritative and seemingly wrong again.

GNAT 4.3.3

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gnat&box=1#about

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Thu, 30 Jul 2009, tmoran@acm.org wrote:

|-----------------------------------------------------------------|
|"[..]                                                            |
|When comparing to C, you should remember to turn off all run-time|
|checking, [..]"                                                  |
|-----------------------------------------------------------------|

What would be the point of using Ada then? Ada is good, partially
because it has checks.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin]

On Jul 30, 1:28 pm, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Thu, 30 Jul 2009, tmo...@acm.org wrote:
>
> |-----------------------------------------------------------------|
> |"[..]                                                            |
> |When comparing to C, you should remember to turn off all run-time|
> |checking, [..]"                                                  |
> |-----------------------------------------------------------------|
>
> What would be the point of using Ada then? Ada is good, partially
> because it has checks.

The shootout is /completely/ about speed / resource usage "bragging
rights" and nothing to do with how languages are actually used day-to-
day.

You could alternatively start a separate 'shootout' that emphasised
other aspects of programming to highly strengths in other languages,
e.g. "Without recourse to non-language defined libraries, start 2
tasks that..." etc :-)

Cheers
-- Martin

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[balson]

Andrea Taverna wrote:
> Hi folks!
>

[snip]


> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard
> or de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"
>


	Where's performance on this list?  Do you not care how fast the 
applications run? Look at the following white paper to see if 
performance should or shoild not be high on your list if you are 
considering changing development languages:

http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

	What this WP documents is we took 5 basic very common computer science 
algorithms and wrote them in different languages: C/C++, Java and C# and 
then benchmarked them against each other. If performance is of any 
concern to you, you'd stiff with C/C++.

	IOW, stay away from the likes of Java, C#, Pascal. Unless you have a 
very specific reason for going in that direction. Your performance will 
suffer.

	Now if you just want to learn a new language, that's different. But if 
you are in the commercial space and delivering to customers and that 
customer demands top performance, stick with C/C++.


Jim



> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.
>
> TIA
> --> Impressions I got for each language
>
> - FreePascal is a safe and modular alternative to C and C++, but it is
> also close to the latter in terms of expressiveness. Moreover it doesn't
> seem to have the libraries I need.
> ==>Qualifies for 0,1,2,5. Not sure about 3 and 4
>
> - Eiffel is geared toward application programming in medium/large-sized
> teams relying heavily on OO modelling. It is designed for (re)usability,
> correctness and efficiency in this order. My needs are somewhat
> different though.
> The main gripe I have with Eiffel is the lack of a well-documented
> standard gpl'ed library.
> GOBO and EiffelBase seem to have incomplete or non-free documentation
> and I couldn't find tutorials; as such, I couldn't get a clear picture
> about them.
> ==> Qualifies for 0,1,2,4,5 and 6. Not sure about 3.
>
> - Ada is best suited for large teams and/or critical software, thus it
> may be overkill for my work, OTH it could have anything I might happen
> to need.
> What holds me from jumping onto Ada is the potential complexity
> It would be interesting to hear the experience of other people learning
> Ada from the C/Java background.
> As for memory management (requirement 4), I heard there are different
> takes on the matter:
> (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> reducing the need of manual management (MM)
> (b) Ada libraries adopt idioms that further simplifies MM issues
> (c) Conservative garbage collectors such as Bohem's can be used with
> Ada, and they are supposed to work "better" with Ada than with unsafe
> languages such as C and C++
>
> So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> mercifully shed some light on the issue.
>
> There seems to be a lot of Ada95 free documentation on the net, I guess
> it's suitable for Ada05 as well.
> ==> Qualifies for 0,1,2,3,5 and, partially, 4
>
> - Modula-3 is simpler/smaller than Ada and has been successfully used
> for system/application programming.
> It seems to be the most consistent, simple and easy to grok, but I
> couldn't find any container/math library ready to use.
> ==> Qualifies for 0,1,2,4,5,6.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[balson]

Andrea Taverna wrote:
> Hi folks!
>

[snip]


> In the past I used C, but now I have decided to change language.
> I'm looking for a "better" one.
>
> Here follow the features it should have, ranked approximately by relevance:
>
> 0) open-source support and an alive community
> 1) directly compiled to efficient code
> 2) statically typed and object-oriented, better if multi-paradigm
> 3) general-purpose libraries (possibly standardized, either by standard
> or de facto), including containers and some math abstractions.
> 4) garbage collected. As an alternative, provide memory management
> policies via libraries (e.g. memory pools and such)
> 5) optional run-time checks and some kind of control over compilation
> and low-level issues
> 6) "relatively simple and consistent"
>


	Where's performance on this list?  Do you not care how fast the 
applications run? Look at the following white paper to see if 
performance should or shoild not be high on your list if you are 
considering changing development languages:

http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

	What this WP documents is we took 5 basic very common computer science 
algorithms and wrote them in different languages: C/C++, Java and C# and 
then benchmarked them against each other. If performance is of any 
concern to you, you'd stiff with C/C++.

	IOW, stay away from the likes of Java, C#, Pascal. Unless you have a 
very specific reason for going in that direction. Your performance will 
suffer.

	Now if you just want to learn a new language, that's different. But if 
you are in the commercial space and delivering to customers and that 
customer demands top performance, stick with C/C++.


Jim



> So I have considered these alternatives: FreePascal, Eiffel, Ada and
> Modula-3.
> I have taken a look at all of them and I'm still undecided. Below are
> the impressions I got for each language.
> Can you help me? Feel free to recommend other languages as well.
>
> TIA
> --> Impressions I got for each language
>
> - FreePascal is a safe and modular alternative to C and C++, but it is
> also close to the latter in terms of expressiveness. Moreover it doesn't
> seem to have the libraries I need.
> ==>Qualifies for 0,1,2,5. Not sure about 3 and 4
>
> - Eiffel is geared toward application programming in medium/large-sized
> teams relying heavily on OO modelling. It is designed for (re)usability,
> correctness and efficiency in this order. My needs are somewhat
> different though.
> The main gripe I have with Eiffel is the lack of a well-documented
> standard gpl'ed library.
> GOBO and EiffelBase seem to have incomplete or non-free documentation
> and I couldn't find tutorials; as such, I couldn't get a clear picture
> about them.
> ==> Qualifies for 0,1,2,4,5 and 6. Not sure about 3.
>
> - Ada is best suited for large teams and/or critical software, thus it
> may be overkill for my work, OTH it could have anything I might happen
> to need.
> What holds me from jumping onto Ada is the potential complexity
> It would be interesting to hear the experience of other people learning
> Ada from the C/Java background.
> As for memory management (requirement 4), I heard there are different
> takes on the matter:
> (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> reducing the need of manual management (MM)
> (b) Ada libraries adopt idioms that further simplifies MM issues
> (c) Conservative garbage collectors such as Bohem's can be used with
> Ada, and they are supposed to work "better" with Ada than with unsafe
> languages such as C and C++
>
> So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> mercifully shed some light on the issue.
>
> There seems to be a lot of Ada95 free documentation on the net, I guess
> it's suitable for Ada05 as well.
> ==> Qualifies for 0,1,2,3,5 and, partially, 4
>
> - Modula-3 is simpler/smaller than Ada and has been successfully used
> for system/application programming.
> It seems to be the most consistent, simple and easy to grok, but I
> couldn't find any container/math library ready to use.
> ==> Qualifies for 0,1,2,4,5,6.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

balson schrieb:

> 
>     Where's performance on this list? [...]

> http://.../doc/AlgorithmicPerformance.pdf
> What this WP documents is we took 5 basic very common computer science
> algorithms and wrote them in different languages:
> C/C++, Java and C# and then benchmarked them against each other.

Note: Cherrystonesoftware markets a product that is not available
with Java, C#, or other languages.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Maciej Sobczak]

On 23 Mar, 14:24, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:

> Note: Cherrystonesoftware markets a product that is not available
> with Java, C#, or other languages.

Are they supposed to make products for those platforms that they
consider inferior? Why?

I only believe in those statistics that I falsified myself, but in
this particular paper they clearly described the measurement
conditions and provided source code - it is complete and therefore
credible.
In this case I see no problem.
Or, frankly, I'm not surprised that what they find in their own
measurements is consistent with what they market, as apparently both
the product and the paper are targeted for the same, performance-aware
audience.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus]

Maciej Sobczak schrieb:
> On 23 Mar, 14:24, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> Note: Cherrystonesoftware markets a product that is not available
>> with Java, C#, or other languages.
> 
> Are they supposed to make products for those platforms that they
> consider inferior? Why?

If only it was stated like this.  Anyway, the test cases
are interesting for other reasons: Yes, the language
implementation matters.  E.g., does your JIT compile to MMX or
SQRT hardware instructions when running the prime number
algorithm? Can you share data efficiently across multiple
processors in non-augmented C99 or in Ada?

When deciding for/against a programming language,
based on likely application performance,
it seems equally important to look at some more things.
One example is memory management in muticore programs.
It seems like malloc() is beginning to show its sequential
heritage, with memory management becoming a messy resource
conflict, making multithreaded programs slow.   This is when
VMs using JIT compilers (or programs employing a non-language
allocation library...)
stand a chance of being faster: they may have built in
memory management for multiple processors. Languages
like C don't---Cherrystone offers one example.

Another benchmarks currently shows rather inconclusive,
but instructive results. The same program is run on a single core
and on a multicore CPU
http://shootout.alioth.debian.org/u64/performance.php?test=chameneosredux
http://shootout.alioth.debian.org/u64q/performance.php?test=chameneosredux

Thus, I think, language choice may well depend on considering more
than massive close-to-the-register CPU operation efficiency.
Even when it destroys one's presumptions (that C++, Ada, Eiffel,
Modula-3, Fortran, etc. somehow must always be fastest).

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 23.03.2010, 16:05 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

> On 23 Mar, 14:24, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
>
>> Note: Cherrystonesoftware markets a product that is not available
>> with Java, C#, or other languages.
>
> Are they supposed to make products for those platforms that they
> consider inferior? Why?

Self fulfilling prophecy?

Consider something inferior and then rigged the test condition to prove  
the point?

Reminds me of Tiobe which too changes the search rules when the results  
start to show a trend they don't like.

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Maciej Sobczak]

On 24 Mar, 07:33, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > Are they supposed to make products for those platforms that they
> > consider inferior? Why?
>
> Self fulfilling prophecy?
>
> Consider something inferior and then rigged the test condition to prove  
> the point?

That's one possibility.

The other is: make a test (however naive), find the best platform
(according to the test) and make products that target it. That would
be actually rational.

We can speculate, but objectively we don't know which is the case here
and the innocent-until-proved-guilty rule of the modern society should
prevent us from making unfounded accusations.

I play the devil's advocate role here, but really I see no reasons to
make a noise about this paper. Especially if Ada is not even being
mentioned.
From the Ada point of view this paper is neither right nor wrong.
Heck - it is actually off-topic here. :-)

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:

> Andrea Taverna wrote:
>> Hi folks!
> [snip]
>> In the past I used C, but now I have decided to change language.
>> I'm looking for a "better" one.
>>
>> Here follow the features it should have, ranked approximately by
>> relevance: 
>>
>> 0) open-source support and an alive community
>> 1) directly compiled to efficient code
>> 2) statically typed and object-oriented, better if multi-paradigm
>> 3) general-purpose libraries (possibly standardized, either by
>> standard or de facto), including containers and some math
>> abstractions. 4) garbage collected. As an alternative, provide memory
>> management policies via libraries (e.g. memory pools and such)
>> 5) optional run-time checks and some kind of control over compilation
>> and low-level issues
>> 6) "relatively simple and consistent"
> 
>      Where's performance on this list?  

Performance is mentioned in "1) directly compiled to efficient 
code".

> IOW, stay away from the likes of Java, C#, Pascal. Unless you
> have a 
> very specific reason for going in that direction. Your performance
> will suffer.
> Jim

I don't think many people would be surprised by these results.
After all Java, C# and Pascal (variants) are still largely 
interpreted  languages, even if they use some sort of compiled 
intermediate code.

But each "tool" has its own place in the toolbox.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

Warren <ve3wwg@gmail.com> writes:

> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:
> 
> > Andrea Taverna wrote:
> >> Hi folks!
> > [snip]
> >> In the past I used C, but now I have decided to change language.
> >> I'm looking for a "better" one.
> >>
> >> Here follow the features it should have, ranked approximately by
> >> relevance: 
> >>
> >> 0) open-source support and an alive community
> >> 1) directly compiled to efficient code
> >> 2) statically typed and object-oriented, better if multi-paradigm
> >> 3) general-purpose libraries (possibly standardized, either by
> >> standard or de facto), including containers and some math
> >> abstractions. 4) garbage collected. As an alternative, provide memory
> >> management policies via libraries (e.g. memory pools and such)
> >> 5) optional run-time checks and some kind of control over compilation
> >> and low-level issues
> >> 6) "relatively simple and consistent"
> > 
> >      Where's performance on this list?  
> 
> Performance is mentioned in "1) directly compiled to efficient 
> code".
> 
> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
> > have a 
> > very specific reason for going in that direction. Your performance
> > will suffer.
> > Jim
> 
> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely 
> interpreted  languages, even if they use some sort of compiled 
> intermediate code.

Pascal is not an interpreted language.  One of Pascal's selling points
was that it was one of the first languages that could be parsed by a
simple recursive descent parser without backtracking.

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Patrick Scheible expounded in news:w9z39zqlr2s.fsf@zipcon.net:

> Warren <ve3wwg@gmail.com> writes:
> 
>> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:
>> 
>> > Andrea Taverna wrote:
>> >> Hi folks!
>> > [snip]
>> >> In the past I used C, but now I have decided to change language.
>> >> I'm looking for a "better" one.
>> >>
>> >> Here follow the features it should have, ranked approximately by
>> >> relevance: 
>> >>
>> >> 0) open-source support and an alive community
>> >> 1) directly compiled to efficient code
>> >> 2) statically typed and object-oriented, better if multi-paradigm
>> >> 3) general-purpose libraries (possibly standardized, either by
>> >> standard or de facto), including containers and some math
>> >> abstractions. 4) garbage collected. As an alternative, provide
>> >> memory management policies via libraries (e.g. memory pools and
>> >> such) 5) optional run-time checks and some kind of control over
>> >> compilation and low-level issues
>> >> 6) "relatively simple and consistent"
>> > 
>> >      Where's performance on this list?  
>> 
>> Performance is mentioned in "1) directly compiled to efficient 
>> code".
>> 
>> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
>> > have a 
>> > very specific reason for going in that direction. Your performance
>> > will suffer.
>> > Jim
>> 
>> I don't think many people would be surprised by these results.
>> After all Java, C# and Pascal (variants) are still largely 
>> interpreted  languages, even if they use some sort of compiled 
>> intermediate code.
> 
> Pascal is not an interpreted language.  One of Pascal's selling points
> was that it was one of the first languages that could be parsed by a
> simple recursive descent parser without backtracking.
> 
> -- Patrick

P-code implementations were.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

Warren <ve3wwg@gmail.com> writes:

> Patrick Scheible expounded in news:w9z39zqlr2s.fsf@zipcon.net:
> 
> > Warren <ve3wwg@gmail.com> writes:
> > 
> >> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:
> >> 
> >> > Andrea Taverna wrote:
> >> >> Hi folks!
> >> > [snip]
> >> >> In the past I used C, but now I have decided to change language.
> >> >> I'm looking for a "better" one.
> >> >>
> >> >> Here follow the features it should have, ranked approximately by
> >> >> relevance: 
> >> >>
> >> >> 0) open-source support and an alive community
> >> >> 1) directly compiled to efficient code
> >> >> 2) statically typed and object-oriented, better if multi-paradigm
> >> >> 3) general-purpose libraries (possibly standardized, either by
> >> >> standard or de facto), including containers and some math
> >> >> abstractions. 4) garbage collected. As an alternative, provide
> >> >> memory management policies via libraries (e.g. memory pools and
> >> >> such) 5) optional run-time checks and some kind of control over
> >> >> compilation and low-level issues
> >> >> 6) "relatively simple and consistent"
> >> > 
> >> >      Where's performance on this list?  
> >> 
> >> Performance is mentioned in "1) directly compiled to efficient 
> >> code".
> >> 
> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
> >> > have a 
> >> > very specific reason for going in that direction. Your performance
> >> > will suffer.
> >> > Jim
> >> 
> >> I don't think many people would be surprised by these results.
> >> After all Java, C# and Pascal (variants) are still largely 
> >> interpreted  languages, even if they use some sort of compiled 
> >> intermediate code.
> > 
> > Pascal is not an interpreted language.  One of Pascal's selling points
> > was that it was one of the first languages that could be parsed by a
> > simple recursive descent parser without backtracking.
> > 
> > -- Patrick
> 
> P-code implementations were.

True.  But P-code was for student use, not production, especially not
production in an application where execution time was critical.

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Patrick Scheible <kkt@zipcon.net> writes:

> Warren <ve3wwg@gmail.com> writes:
>
>> Patrick Scheible expounded in news:w9z39zqlr2s.fsf@zipcon.net:
>> 
>> > Warren <ve3wwg@gmail.com> writes:
>> > 
>> >> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:
>> >> 
>> >> > Andrea Taverna wrote:
>> >> >> Hi folks!
>> >> > [snip]
>> >> >> In the past I used C, but now I have decided to change language.
>> >> >> I'm looking for a "better" one.
>> >> >>
>> >> >> Here follow the features it should have, ranked approximately by
>> >> >> relevance: 
>> >> >>
>> >> >> 0) open-source support and an alive community
>> >> >> 1) directly compiled to efficient code
>> >> >> 2) statically typed and object-oriented, better if multi-paradigm
>> >> >> 3) general-purpose libraries (possibly standardized, either by
>> >> >> standard or de facto), including containers and some math
>> >> >> abstractions. 4) garbage collected. As an alternative, provide
>> >> >> memory management policies via libraries (e.g. memory pools and
>> >> >> such) 5) optional run-time checks and some kind of control over
>> >> >> compilation and low-level issues
>> >> >> 6) "relatively simple and consistent"
>> >> > 
>> >> >      Where's performance on this list?  
>> >> 
>> >> Performance is mentioned in "1) directly compiled to efficient 
>> >> code".
>> >> 
>> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
>> >> > have a 
>> >> > very specific reason for going in that direction. Your performance
>> >> > will suffer.
>> >> > Jim
>> >> 
>> >> I don't think many people would be surprised by these results.
>> >> After all Java, C# and Pascal (variants) are still largely 
>> >> interpreted  languages, even if they use some sort of compiled 
>> >> intermediate code.

This is wrong.

The most common implementations of these languages are all compilers.

The fact that the compiled code is later executed by a hardware
processor or a software processor (a "virtual machine") is irrelevant to
the workings of the implementation of the language.



>> > Pascal is not an interpreted language.  One of Pascal's selling points
>> > was that it was one of the first languages that could be parsed by a
>> > simple recursive descent parser without backtracking.
>> > 
>> > -- Patrick
>> 
>> P-code implementations were.
>
> True.  But P-code was for student use, not production, especially not
> production in an application where execution time was critical.

This is wrong.

P-code was designed, and used, exactly like the JVM is today.  There
even were developed processors that executed directly P-code, natively,
like we have JVM implemented in hardware too.


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 2:27 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:

> > True.  But P-code was for student use, not production, especially not
> > production in an application where execution time was critical.
>
> This is wrong.
>
> P-code was designed, and used, exactly like the JVM is today.  There
> even were developed processors that executed directly P-code, natively,
> like we have JVM implemented in hardware too.

I think Patrick is essentially correct; the Wikipedia entry for "UCSD
Pascal" says:

"The University of California, San Diego Institute for Information
Systems developed it in 1978 to provide students with a common
operating system that could run on any of the then available
microcomputers as well as campus DEC PDP-11 minicomputers."  [This was
before the IBM PC came out, so I think "then available microcomputers"
meant Terak and maybe Apple II; perhaps there were some others.]

So, yes, it was originally designed for student use; I don't believe
the original designers had any commercial use in mind.  But its use
spread after that.

                              -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

Adam Beneschan <adam@irvine.com> writes:

> On Mar 24, 2:27=A0pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> 
> > > True. =A0But P-code was for student use, not production, especially not
> > > production in an application where execution time was critical.
> >
> > This is wrong.
> >
> > P-code was designed, and used, exactly like the JVM is today. =A0There
> > even were developed processors that executed directly P-code, natively,
> > like we have JVM implemented in hardware too.
> 
> I think Patrick is essentially correct; the Wikipedia entry for "UCSD
> Pascal" says:
> 
> "The University of California, San Diego Institute for Information
> Systems developed it in 1978 to provide students with a common
> operating system that could run on any of the then available
> microcomputers as well as campus DEC PDP-11 minicomputers."  [This was
> before the IBM PC came out, so I think "then available microcomputers"
> meant Terak and maybe Apple II; perhaps there were some others.]

I encountered it on a CP/M system.  S-100 bus, Z80 processor.  Apple
II's that I saw didn't run it, but I wouldn't swear that it was
impossible.

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 4:15 pm, Patrick Scheible <k...@zipcon.net> wrote:

> I encountered it on a CP/M system.  S-100 bus, Z80 processor.  Apple
> II's that I saw didn't run it, but I wouldn't swear that it was
> impossible.

I recall doing some work with UCSD Pascal on an Apple II (probably II
+) at UC Irvine.

                            -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patricia Shanahan]

Patrick Scheible wrote:
> Adam Beneschan <adam@irvine.com> writes:
> 
>> On Mar 24, 2:27=A0pm, p...@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>
>>>> True. =A0But P-code was for student use, not production, especially not
>>>> production in an application where execution time was critical.
>>> This is wrong.
>>>
>>> P-code was designed, and used, exactly like the JVM is today. =A0There
>>> even were developed processors that executed directly P-code, natively,
>>> like we have JVM implemented in hardware too.
>> I think Patrick is essentially correct; the Wikipedia entry for "UCSD
>> Pascal" says:
>>
>> "The University of California, San Diego Institute for Information
>> Systems developed it in 1978 to provide students with a common
>> operating system that could run on any of the then available
>> microcomputers as well as campus DEC PDP-11 minicomputers."  [This was
>> before the IBM PC came out, so I think "then available microcomputers"
>> meant Terak and maybe Apple II; perhaps there were some others.]
> 
> I encountered it on a CP/M system.  S-100 bus, Z80 processor.  Apple
> II's that I saw didn't run it, but I wouldn't swear that it was
> impossible.

Apple Pascal was based on UCSD Pascal. I ran it frequently on my Apple
II. According to the reference manual, it required 48 KB memory, at
least one Apple II disk drive, and the Apple Language System.

Patricia

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[John B. Matthews]

In article <9N6dnWfJPsGbPTfWnZ2dnUVZ_qydnZ2d@earthlink.com>,
 Patricia Shanahan <pats@acm.org> wrote:

> Patrick Scheible wrote:
> > Adam Beneschan <adam@irvine.com> writes:
> > 
> >> On Mar 24, 2:27=A0pm, p...@informatimago.com (Pascal J. Bourguignon)
> >> wrote:
> >>
> >>>> True. =A0But P-code was for student use, not production, especially not
> >>>> production in an application where execution time was critical.
> >>> This is wrong.
> >>>
> >>> P-code was designed, and used, exactly like the JVM is today. =A0There
> >>> even were developed processors that executed directly P-code, natively,
> >>> like we have JVM implemented in hardware too.
> >> I think Patrick is essentially correct; the Wikipedia entry for "UCSD
> >> Pascal" says:
> >>
> >> "The University of California, San Diego Institute for Information
> >> Systems developed it in 1978 to provide students with a common
> >> operating system that could run on any of the then available
> >> microcomputers as well as campus DEC PDP-11 minicomputers."  [This was
> >> before the IBM PC came out, so I think "then available microcomputers"
> >> meant Terak and maybe Apple II; perhaps there were some others.]
> > 
> > I encountered it on a CP/M system.  S-100 bus, Z80 processor.  Apple
> > II's that I saw didn't run it, but I wouldn't swear that it was
> > impossible.
> 
> Apple Pascal was based on UCSD Pascal. I ran it frequently on my Apple
> II. According to the reference manual, it required 48 KB memory, at
> least one Apple II disk drive, and the Apple Language System.

Just for fun I took a screen shot of Apple UCSD-Pascal 1.3 (II.1) 
running on an emulator written in Java:

<http://i42.tinypic.com/14nuw1.png>
<http://sourceforge.net/projects/jace/>

The UC regents recently released the original I.5 sources "for 
educational, research, and non-profit purposes"

<http://techtransfer.universityofcalifornia.edu/NCD/19327.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrew Haley]

In comp.programming Adam Beneschan <adam@irvine.com> wrote:
> On Mar 24, 2:27?pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> 
>> > True. ?But P-code was for student use, not production, especially not
>> > production in an application where execution time was critical.
>>
>> This is wrong.
>>
>> P-code was designed, and used, exactly like the JVM is today. ?There
>> even were developed processors that executed directly P-code, natively,
>> like we have JVM implemented in hardware too.
> 
> I think Patrick is essentially correct; the Wikipedia entry for "UCSD
> Pascal" says:
> 
> "The University of California, San Diego Institute for Information
> Systems developed it in 1978 to provide students with a common
> operating system that could run on any of the then available
> microcomputers as well as campus DEC PDP-11 minicomputers."

I think there's some confusion here.  UCSD Pascal was not the origin
of Pascal P-code: the compiler that generated P-code was the 1973
Zurich P-compiler, part of the P-kit.  The idea was for the user
either to write an interpeter or modify the source of the P-compiler
and replace its code-generaring routines.  However, according to
Wirth, "the reluctance of many to proceed beyond the interpretive
scheme also gave rise to Pascal's classification as a 'slow language,'
restricted to use in teaching."

Andrew.

N. Wirth, Recollections about the development of Pascal
HOPL-II
Pages: 97-120  
ISBN:0-201-89502-1

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Adam Beneschan <adam@irvine.com> writes:

> On Mar 24, 2:27�pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>> > True. �But P-code was for student use, not production, especially not
>> > production in an application where execution time was critical.
>>
>> This is wrong.
>>
>> P-code was designed, and used, exactly like the JVM is today. �There
>> even were developed processors that executed directly P-code, natively,
>> like we have JVM implemented in hardware too.
>
> I think Patrick is essentially correct; the Wikipedia entry for "UCSD
> Pascal" says:
>
> "The University of California, San Diego Institute for Information
> Systems developed it in 1978 to provide students with a common
> operating system that could run on any of the then available
> microcomputers as well as campus DEC PDP-11 minicomputers."  [This was
> before the IBM PC came out, so I think "then available microcomputers"
> meant Terak and maybe Apple II; perhaps there were some others.]
>
> So, yes, it was originally designed for student use; I don't believe
> the original designers had any commercial use in mind.  But its use
> spread after that.

Sure, but that's unfortunately the case of a lot of systems designed by
researchers: they test bed them with their students.  And that's the
case of a lot of non academic systems including Java too, whose use
spread badly beyond their original intend.


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 8:07 am, Warren <ve3...@gmail.com> wrote:

> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
> >> > have a
> >> > very specific reason for going in that direction. Your performance
> >> > will suffer.
> >> > Jim
>
> >> I don't think many people would be surprised by these results.
> >> After all Java, C# and Pascal (variants) are still largely
> >> interpreted  languages, even if they use some sort of compiled
> >> intermediate code.
>
> > Pascal is not an interpreted language.  One of Pascal's selling points
> > was that it was one of the first languages that could be parsed by a
> > simple recursive descent parser without backtracking.
>
> P-code implementations were.

So all this means is that if we compared the performance of a C
compiler with the performance of a p-code implementation of Pascal, we
shouldn't be surprised if the Pascal program runs slower.  That's
pretty obvious, and also pretty pointless.  Users who are concerned
about performance would want to compare a C compiler with a Pascal
compiler that generates native code.  Those Pascal compilers are
readily available, and there's no inherent reason why they would show
worse performance than C code (if you turn off range checking), since
Pascal is not an interpreted language (as opposed to, say, Lisp or
Perl, which *are* interpreted languages and which would normally not
get you anywhere near the performance of a C program).

                              -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 24.03.2010, 22:36 Uhr, schrieb Adam Beneschan <adam@irvine.com>:

>  Those Pascal compilers are
> readily available,

Right I remember - I had one for my Atari 800 (Kyan Pascal  
http://www.atarimagazines.com/v4n7/kyanpascal.html). It created 6502  
machine code which was as fast as it get on an 8bit system.

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Ole-Hjalmar Kristensen]

Lisp is not necessarily interpreted either.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 23.03.2010, 17:50 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely
> interpreted  languages, even if they use some sort of compiled
> intermediate code.


I would say the most used Pascal variants these days is Delphi and Ada -  
both which compile native code.

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u916w9k9z25lew@macpro-eth1.krischik.com: 

> Am 23.03.2010, 17:50 Uhr, schrieb Warren <ve3wwg@gmail.com>:
> 
>> I don't think many people would be surprised by these results.
>> After all Java, C# and Pascal (variants) are still largely
>> interpreted  languages, even if they use some sort of compiled
>> intermediate code.
> 
> I would say the most used Pascal variants these days is Delphi and Ada
> -  both which compile native code.
> 
> Martin

Ok, sure (apart from old P-code variants). One has to wonder
then why the Pascal "compiled code" was so miserable in 
their results. I don't recall if they mentioned which
Pascal compiler they used.

So if there is a surprise in there, Pascal would be it. ;-)

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mike Sieweke]

In article <Xns9D4571C17F76WarrensBlatherings@188.40.43.245>,
 Warren <ve3wwg@gmail.com> wrote:

> Martin Krischik expounded in
> news:op.u916w9k9z25lew@macpro-eth1.krischik.com: 
> 
> > Am 23.03.2010, 17:50 Uhr, schrieb Warren <ve3wwg@gmail.com>:
> > 
> >> I don't think many people would be surprised by these results.
> >> After all Java, C# and Pascal (variants) are still largely
> >> interpreted  languages, even if they use some sort of compiled
> >> intermediate code.
> > 
> > I would say the most used Pascal variants these days is Delphi and Ada
> > -  both which compile native code.
> > 
> > Martin
> 
> Ok, sure (apart from old P-code variants). One has to wonder
> then why the Pascal "compiled code" was so miserable in 
> their results. I don't recall if they mentioned which
> Pascal compiler they used.
> 
> So if there is a surprise in there, Pascal would be it. ;-)
> 
> Warren

Did anyone else actually read the paper?  It says nothing
of substance about Pascal or Ada.  It only compares the
performance of C, C++, C#, and Java.  There's only one
mention of Pascal as one of "many choices" in programming
languages.


-- Mike Sieweke
-- "Just a bit of harmless brain alteration, that's all..."

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Robert A Duff]

Mike Sieweke <msieweke@ix.netcom.com> writes:

> Did anyone else actually read the paper?

I skimmed it briefly.

>...It says nothing
> of substance about Pascal or Ada.

Right.  That's why it's a little strange that the person
who posted it used the paper as evidence that one should not
use Pascal in performance-critical applications.

>...It only compares the
> performance of C, C++, C#, and Java.  There's only one
> mention of Pascal as one of "many choices" in programming
> languages.

It would be interesting to translate some of the examples in
the paper into Ada, and do some timing.  (Sorry, I'm not
volunteering -- too busy.)

- Bob

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Wed, 24 Mar 2010, Martin Krischik wrote:

|-----------------------------------------------------------------------------|
|"Am 23.03.2010, 17:50 Uhr, schrieb Warren <ve3wwg@gmail.com>:                |
|                                                                             |
|> I don't think many people would be surprised by these results.             |
|> After all Java, C# and Pascal (variants) are still largely                 |
|> interpreted  languages, even if they use some sort of compiled             |
|> intermediate code.                                                         |
|                                                                             |
|                                                                             |
|I would say the most used Pascal variants these days is Delphi and Ada - both|
|which compile native code.                                                   |
|                                                                             |
|Martin                                                                       |
|                                                                             |
|--                                                                           |
|Martin Krischik"                                                             |
|-----------------------------------------------------------------------------|

Do not forget VHDL.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[blmblm]

(Setting follow-ups back to the original cross-posting, since 
I don't read comp.lang.ada .... )

In article <Xns9D4482A264D8BWarrensBlatherings@188.40.43.245>,
Warren  <ve3wwg@gmail.com> wrote:
> balson expounded in news:4BA8BA91.4050905@cherrystonesoftware.com:
> 
> > Andrea Taverna wrote:
> >> Hi folks!
> > [snip]
> >> In the past I used C, but now I have decided to change language.
> >> I'm looking for a "better" one.

[ snip ]

> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
> > have a 
> > very specific reason for going in that direction. Your performance
> > will suffer.
> > Jim
> 
> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely 
> interpreted  languages, even if they use some sort of compiled 
> intermediate code.

It's my impression that most/all current implementations of Java
do "just-in-time" compiling (of the compiled intermediate code)
to native code, and if that's true (certainly true of some of
them), does the language really count as "interpreted"?  Just
sayin', maybe.

> But each "tool" has its own place in the toolbox.

Can't disagree with that, though!


-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

blmblm@myrealbox.com expounded in news:8143krF7lhU1@mid.individual.net:
..
>> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
>> > have a 
>> > very specific reason for going in that direction. Your performance
>> > will suffer.
>> > Jim
>> 
>> I don't think many people would be surprised by these results.
>> After all Java, C# and Pascal (variants) are still largely 
>> interpreted  languages, even if they use some sort of compiled 
>> intermediate code.
> 
> It's my impression that most/all current implementations of Java
> do "just-in-time" compiling (of the compiled intermediate code)
> to native code, and if that's true (certainly true of some of
> them), does the language really count as "interpreted"?  Just
> sayin', maybe.

The "JIT" business is just a distraction IMO. Before any 
"compilation" occurs, something else (the interpreter) is 
orchestrating things. Even the JIT "sections of code" are 
invoked on the behalf of byte code by the "monitoring"
process (i.e. the interpreter).

So unless you can get rid of that "managing process", you still
have what used to be called a "monitor process", that is outside
of the O/S. IOW, an interpreter. In CP/M, the monitor was the
O/S ;) but I digress.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal J. Bourguignon]

Warren <ve3wwg@gmail.com> writes:

> blmblm@myrealbox.com expounded in news:8143krF7lhU1@mid.individual.net:
> ..
>>> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
>>> > have a 
>>> > very specific reason for going in that direction. Your performance
>>> > will suffer.
>>> > Jim
>>> 
>>> I don't think many people would be surprised by these results.
>>> After all Java, C# and Pascal (variants) are still largely 
>>> interpreted  languages, even if they use some sort of compiled 
>>> intermediate code.
>> 
>> It's my impression that most/all current implementations of Java
>> do "just-in-time" compiling (of the compiled intermediate code)
>> to native code, and if that's true (certainly true of some of
>> them), does the language really count as "interpreted"?  Just
>> sayin', maybe.
>
> The "JIT" business is just a distraction IMO. Before any 
> "compilation" occurs, something else (the interpreter) is 
> orchestrating things. Even the JIT "sections of code" are 
> invoked on the behalf of byte code by the "monitoring"
> process (i.e. the interpreter).
>
> So unless you can get rid of that "managing process", you still
> have what used to be called a "monitor process", that is outside
> of the O/S. IOW, an interpreter. In CP/M, the monitor was the
> O/S ;) but I digress.

JIT or not JIT, this has nothing to do with the programming language,
but with the processor.  Therefore "interpreter" or "compiler" have
nothing to do in a sentence with "JIT".

Even a hardware processor such as an x86 processor could be doing JIT
(eg. the Transmeta processors, or some high end Intel processors).


-- 
__Pascal Bourguignon__

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[J-P. Rosen]

balson a écrit :
>     IOW, stay away from the likes of Java, C#, Pascal. Unless you have a
> very specific reason for going in that direction. Your performance will
> suffer.
> 
I don't see why you put Pascal in the same basket. Pascal is not part of
the benchmark, therefore there is no evidence for what you say, and
Pascal does not require an interpreter or semi-interpreter.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Jim Balson]

J-P. Rosen wrote:
> balson a écrit :
>>      IOW, stay away from the likes of Java, C#, Pascal. Unless you have a
>> very specific reason for going in that direction. Your performance will
>> suffer.
>>
> I don't see why you put Pascal in the same basket. Pascal is not part of
> the benchmark, therefore there is no evidence for what you say, and
> Pascal does not require an interpreter or semi-interpreter.
>


I included Pascal because once you get up into languages that do bounds 
checking, performance will degrade. Pascal is one of those languages 
that does bounds checking. It comes down to this:

a) Either the programmer writes code to not exceed array bounds, or
b) Use a language that does it for you.

The choice of (a) will cost you a little bit of time developing.
The choice of (b) is going to cost you in performance when done.

If we were to add another language to our benchmarks, Pascal would be 
the logical choice. And we may do it at some point in the future. We're 
certainly going to add many more algorithms to the testing as time permits.


Jim

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal Obry]

Jim,

> I included Pascal because once you get up into languages that do bounds
> checking, performance will degrade. Pascal is one of those languages
> that does bounds checking. It comes down to this:
> 
> a) Either the programmer writes code to not exceed array bounds, or
> b) Use a language that does it for you.
> 
> The choice of (a) will cost you a little bit of time developing.
> The choice of (b) is going to cost you in performance when done.
> 
> If we were to add another language to our benchmarks, Pascal would be
> the logical choice. And we may do it at some point in the future. We're
> certainly going to add many more algorithms to the testing as time permits.

I dont' know for Pascal, Ada does bound checking too. Nevertheless, in
some cases the checks can be removed automatically, for example:

   type Tab is array (1 .. 10) of Integer;

   T : Tab;

   for K in T'Range loop
      T (K) :=
   end loop;

Here "T (K)" won't trigger a runtime check as the compile can see at
compile time that K is always in the proper range.

But anyway this is not even an issue. For performance you can always
remove the checks using the right compiler option. Then you have the
best of both worlds. During development the checks are really helpful,
in production you remove them.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[jpwoodruff]

On Mar 23, 10:54 am, Pascal Obry <pas...@obry.net> wrote:

<jpw removed discussion of bounds checking>

> But anyway this is not even an issue. For performance you can always
> remove the checks using the right compiler option. Then you have the
> best of both worlds. During development the checks are really helpful,
> in production you remove them.
>

I hope I'm not the only old-timer who remembers:

"This is the case of the sailor who wears his life jacket while
rigging his boat,
then leaves it ashore when he goes sailing."

John

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

jpwoodruff <jpwoodruff@gmail.com> writes:

> On Mar 23, 10:54=A0am, Pascal Obry <pas...@obry.net> wrote:
> 
> <jpw removed discussion of bounds checking>
> 
> > But anyway this is not even an issue. For performance you can always
> > remove the checks using the right compiler option. Then you have the
> > best of both worlds. During development the checks are really helpful,
> > in production you remove them.
> >
> 
> I hope I'm not the only old-timer who remembers:
> 
> "This is the case of the sailor who wears his life jacket while
> rigging his boat,
> then leaves it ashore when he goes sailing."

Not the only one.  How many viruses spread by buffer overflow exploits
that would be impossible in a bounds-checked language?

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

Pascal Obry <pascal@obry.net> writes:

> Jim,
> 
> > I included Pascal because once you get up into languages that do bounds
> > checking, performance will degrade. Pascal is one of those languages
> > that does bounds checking. It comes down to this:
> > 
> > a) Either the programmer writes code to not exceed array bounds, or
> > b) Use a language that does it for you.
> > 
> > The choice of (a) will cost you a little bit of time developing.
> > The choice of (b) is going to cost you in performance when done.
> > 
> > If we were to add another language to our benchmarks, Pascal would be
> > the logical choice. And we may do it at some point in the future. We're
> > certainly going to add many more algorithms to the testing as time permits.
> 
> I dont' know for Pascal, Ada does bound checking too. Nevertheless, in
> some cases the checks can be removed automatically, for example:
> 
>    type Tab is array (1 .. 10) of Integer;
> 
>    T : Tab;
> 
>    for K in T'Range loop
>       T (K) :=
>    end loop;
> 
> Here "T (K)" won't trigger a runtime check as the compile can see at
> compile time that K is always in the proper range.
> 
> But anyway this is not even an issue. For performance you can always
> remove the checks using the right compiler option. Then you have the
> best of both worlds. During development the checks are really helpful,
> in production you remove them.

It's been said that this approach is like having lifeboats on an ocean
liner while it is in sea trials, and then taking them out when it
starts to carry passengers.

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Pascal Obry]

Patrick,

> It's been said that this approach is like having lifeboats on an ocean
> liner while it is in sea trials, and then taking them out when it
> starts to carry passengers.

Well don't get me wrong. I did not say that one MUST remove checks for
production but that one CAN do that. In some cases, HPC come to mind,
this can save quite some cycles. If the simulation is not critical (no
life depend on it) then why not? At least this is a possibility, let's
exploit it where and when it makes sense.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 23.03.2010, 21:33 Uhr, schrieb Patrick Scheible <kkt@zipcon.net>:

> Pascal Obry <pascal@obry.net> writes:

>> But anyway this is not even an issue. For performance you can always
>> remove the checks using the right compiler option. Then you have the
>> best of both worlds. During development the checks are really helpful,
>> in production you remove them.
>
> It's been said that this approach is like having lifeboats on an ocean
> liner while it is in sea trials, and then taking them out when it
> starts to carry passengers.

Right on. I was very disappointed then I read the details of Java's assert  
statement - if you just double click an executable jar file the assets are  
removed by the class loader :-( .

Regards

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 23, 10:41 am, Jim Balson <lab...@cherrystonesoftware.com>
wrote:
> J-P. Rosen wrote:
> > balson a écrit :
> >>      IOW, stay away from the likes of Java, C#, Pascal. Unless you have a
> >> very specific reason for going in that direction. Your performance will
> >> suffer.
>
> > I don't see why you put Pascal in the same basket. Pascal is not part of
> > the benchmark, therefore there is no evidence for what you say, and
> > Pascal does not require an interpreter or semi-interpreter.
>
> I included Pascal because once you get up into languages that do bounds
> checking, performance will degrade. Pascal is one of those languages
> that does bounds checking. It comes down to this:
>
> a) Either the programmer writes code to not exceed array bounds, or
> b) Use a language that does it for you.
>
> The choice of (a) will cost you a little bit of time developing.
> The choice of (b) is going to cost you in performance when done.

Aside from the fact that (as Pascal Obry pointed out) compilers for
languages that do these checks for you usually provide a way to
suppress those checks, (a) is a little bit naïve.  Or maybe a lot
naïve---I don't know.  But it's like saying

(c) The programmer writes code that just works perfectly all the time.

I wish I could!  I've been in this business for over 30 years and I
still haven't figured out how not to make mistakes.  I suspect that it
may have to do with my being a member of _Homo sapiens_.  But I'm sure
that the folks at Microsoft, Oracle, etc., try to write code that
"doesn't exceed array bounds" (and doesn't do double deallocation,
etc.).  But all they have to do is make a mistake in one case, and the
result is software with a vulnerability that bad guys figure out how
to exploit, and now the amount of performance time you save by not
doing bound checks is dwarfed by the amount of total time thousands of
people spend trying to clean malware off their computers, restore
destroyed data from backup, etc.

So bounds checking is a good thing.  Even so, it's good to have a
choice.  Pascal and Ada, as usually implemented, let you choose
between the extra safety of bounds checks and the added performance of
eliminating them in programs that have been tested.  C doesn't.

                                     -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Mensanator]

On Mar 23, 2:33 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Mar 23, 10:41 am, Jim Balson <lab...@cherrystonesoftware.com>
> wrote:
>
>
>
>
>
> > J-P. Rosen wrote:
> > > balson a écrit :
> > >>      IOW, stay away from the likes of Java, C#, Pascal. Unless you have a
> > >> very specific reason for going in that direction. Your performance will
> > >> suffer.
>
> > > I don't see why you put Pascal in the same basket. Pascal is not part of
> > > the benchmark, therefore there is no evidence for what you say, and
> > > Pascal does not require an interpreter or semi-interpreter.
>
> > I included Pascal because once you get up into languages that do bounds
> > checking, performance will degrade. Pascal is one of those languages
> > that does bounds checking. It comes down to this:
>
> > a) Either the programmer writes code to not exceed array bounds, or
> > b) Use a language that does it for you.
>
> > The choice of (a) will cost you a little bit of time developing.
> > The choice of (b) is going to cost you in performance when done.
>
> Aside from the fact that (as Pascal Obry pointed out) compilers for
> languages that do these checks for you usually provide a way to
> suppress those checks, (a) is a little bit naïve.  Or maybe a lot
> naïve---I don't know.  But it's like saying
>
> (c) The programmer writes code that just works perfectly all the time.
>

I asked a programmer once (after his program crashed immediately after
he compiled it): "Didn't you run this?"

His reply: "Why should I run it? I know how it works, I wrote it."

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[David Thompson]

On Tue, 23 Mar 2010 12:33:46 -0700 (PDT), Adam Beneschan
<adam@irvine.com> wrote:
<snip>
> I wish I could!  I've been in this business for over 30 years and I
> still haven't figured out how not to make mistakes.  <snip>
> So bounds checking is a good thing.  Even so, it's good to have a
> choice.  Pascal and Ada, as usually implemented, let you choose
> between the extra safety of bounds checks and the added performance of
> eliminating them in programs that have been tested.  C doesn't.

Ada has standard-in-language option, so all implementations must
provide it; PL/I same. Pascal doesn't require checking, but common
practice is yes or option. Fortran doesn't require it, and common
practice is no, but there have long been some that do, especially
since F90 made unnecessary (but did not entirely remove) the
assumed-size' (aterisk) form that most discourages it.

C doesn't prohibit it, but encourages pointer use that makes it more
difficult; there have been bounds-checking C implementations, but in
the dancing bear category.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 31.03.2010, 08:55 Uhr, schrieb David Thompson  
<dave.thompson2@verizon.net>:

> Ada has standard-in-language option, so all implementations must
> provide it; PL/I same. Pascal doesn't require checking, but common
> practice is yes or option.

Just noticed that the three languages quoted also lets you specify the  
base index. That is you can specify an array starting at 1980 and ending  
at 2010. And before the performance freaks panic: If you have a statistic  
application collecting data from 1980 to 2010 then a 0 based index will  
only give you a lot of extra work but no performance advantage.

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

Jim Balson expounded in news:4BA8FD54.8020200@cherrystonesoftware.com:

> J-P. Rosen wrote:
>> balson a écrit :
>>>      IOW, stay away from the likes of Java, C#, Pascal. Unless you
>>>      have a 
>>> very specific reason for going in that direction. Your performance
>>> will suffer.
>>>
>> I don't see why you put Pascal in the same basket. Pascal is not part
>> of the benchmark, therefore there is no evidence for what you say,
>> and Pascal does not require an interpreter or semi-interpreter.
> 
> I included Pascal because once you get up into languages that do
> bounds checking, performance will degrade. ...

Leave out bounds checking, and quality will degrade.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Colin Paul Gloster]

On Tue, 23 Mar 2010, Jim Balson wrote:

|-------------------------------------------------------------------------|
|"[..]                                                                    |
|                                                                         |
|If we were to add another language to our benchmarks, Pascal would be the|
|logical choice."                                                         |
|-------------------------------------------------------------------------|

FORTRAN-77 code on a good machine would be faster if no heap usage is needed.

|-------------------------------------------------------------------------|
|" And we may do it at some point in the future. We're certainly          |
|going to add many more algorithms to the testing as time permits."       |
|-------------------------------------------------------------------------|

Good.

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Andrea Taverna]

On 23 Mar, 13:31, balson <lab...@cherrystonesoftware.com> wrote:
>
>
>         Where's performance on this list?  Do you not care how fast the
> applications run?

Yes, I do, but there's a somewhat famouse quote I'd tend to agree
with:
/While hardware computing horsepower increases at roughly 60%/year,
compiler optimizations contribute only 4%. Basically, compiler
optimization work makes only marginal contributions. This means
Programming Language Research should be concentrating on something
other than optimizations. Perhaps programmer productivity is a more
fruitful arena. (Probesting's Law)./


> Look at the following white paper to see if
> performance should or shoild not be high on your list if you are
> considering changing development languages:
>
> http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

With respect to that paper, it fails to account that Java and C# are
quite different from the other alternatives I listed. More precisely,
C#/Java may be required to perform a lot of checks to ensure "safety"
in a very high level sense and both strive to offer a C-like
alternative to C++ for some kinds of applications.
Ada, CL, M3 and Pascal were designed with quite different goals that
are likely to make them easier to optimize than the former two.

As an example, I run your insertion-sort benchmark with the following
implementations:
- C with gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
- Ada with gcc GNAT, compiled with flags -gnatp and -O2
- Common Lisp SBCL 1.0.33, compiler directives are in the source code,
the "usual" (speed 3) (space 0) (safety 0)
on an Acer Aspire 3000 with 500MB RAM and processor AMD Sempron 3100+
1.6GHz with Fedora Core 11 installed.
Source for Ada and Lisp benchmark can be found here http://pastebin.org/125192
and here http://pastebin.org/125194 respectively.

(ALERT: I'm a noob, at least in Ada and Lisp, so the code might be
ugly has hell, but, hopefully, correct)

The results:
[Size]	100'000	200'000	400'000
/Lang]
C	23.36	144.90	521.38
Lisp	40.74	147.97	692.51
Ada	22.88	112.92	488.69
				[secs]


[...]
> I included Pascal because once you get up into languages that do bounds
> checking, performance will degrade.
Being a student, I'm almost ignorant on how coding is supposed to work
outside academia, still I'm not convinced on this.
For one, some of the languages I listed encourage the use of special
idioms for accessing arrays s.t. such accesses are provably correct
and efficient, e.g.
Ada: for I in V'Range loop ....
Lisp: (loop :with n := (length v) :for i :from 0 :below n :do.... ;
not sure about this idiom ...

and, as other have said, most of the implementation of those
languages, with, IIRC, the exception of Java and C#, allow you to turn
off those or all of the run-time checks for production code.

> Pascal is one of those languages
> that does bounds checking. It comes down to this:
>
> a) Either the programmer writes code to not exceed array bounds, or
> b) Use a language that does it for you.
But, well, there are other options!
c) use a language that help you write correct code
seems a viable one.
Historically Pascal and the likes cared about providing the programmer
a good deal of elementary tools, such as *true arrays*, C/C++ never
provided that. Pascal-like languages have had *optional* run-time
checks on array access for a long time.

But I have seen lot of C/C++ code written by "experts" that followed
the Greenspun's 10th rule. They wrote string/number munching code and
invented their own run-time checks, so there's also
d) write your own checks in a language that provides none

Andrea

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Gautier write-only]

On 27 Mrz., 01:53, Andrea Taverna wrote:

> As an example, I run your insertion-sort benchmark with the following
> implementations:
> - C with gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
> - Ada with gcc GNAT, compiled with flags -gnatp and -O2
> - Common Lisp SBCL 1.0.33, compiler directives are in the source code,
> the "usual" (speed 3) (space 0) (safety 0)

For gcc (Ada and C) you can also try the following flags:
-funroll-loops -fpeel-loops -ftracer -funswitch-loops -fweb -frename-
registers
For gcc, Ada only: -gnatn (cross-unit inlining)
Have fun!
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Patrick Scheible]

balson <labrat@cherrystonesoftware.com> writes:

> 
> 	Where's performance on this list?  Do you not care how fast the 
> applications run? Look at the following white paper to see if 
> performance should or shoild not be high on your list if you are 
> considering changing development languages:
> 
> http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf
> 
> 	What this WP documents is we took 5 basic very common computer science 
> algorithms and wrote them in different languages: C/C++, Java and C# and 
> then benchmarked them against each other. If performance is of any 
> concern to you, you'd stiff with C/C++.
> 
> 	IOW, stay away from the likes of Java, C#, Pascal. Unless you have a 
> very specific reason for going in that direction. Your performance will 
> suffer.

[snip]

I looked at the paper on the web page you point at.  Why do you not
distinguish between C and C++?  They are significantly different
languages.  If you use C++, performance will probably suffer compared
to C.

Why are you making statements about Pascal's performance?  While
Pascal has some annoying limitations for the programmer, it is very
fast.  If you tested it, where's the results?  If you didn't test it,
why are you making disparaging comments about it?

Performance only sometimes comes from better performance on the same
code.  Most of the time, performance gains come from writing a
better algorithm.  Programmers are better off chosing a language
well-suited to the problem.  Then if performance isn't good, figure
out where it's slow and improve that part of the code.

-- Patrick

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[cbcurl]

On Mar 23, 12:50 pm, Warren <ve3...@gmail.com> wrote:
> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely
> interpreted  languages, even if they use some sort of compiled
> intermediate code.

Really?

AFAIK, most Java and C# implementations, JIT-compile to machine code
and are *not* interpreted, and since when was Pascal ever an
interpreted language (perhaps you were thinking of BASIC)?

- C

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[John B. Matthews]

In article 
<7a0c7a19-5d83-4cc6-be68-95ebf41533e7@t23g2000yqt.googlegroups.com>,
 cbcurl <cbcurl@gmail.com> wrote:

> since when was Pascal ever an interpreted language

AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>
>  cbcurl <cbc...@gmail.com> wrote:
> > since when was Pascal ever an interpreted language
>
> AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.

I wouldn't call it an interpreted language, really.  The UCSD compiler
generated code for a machine that didn't exist, and then programs ran
by interpreting that machine's instructions.  However, my recollection
is that the pseudo-machine's instruction set really didn't have
anything to do with Pascal and could have been used for any language.
A few years later, Western Digital developed a machine that executed
the P-machine's instructions directly (in microcode).  The lab I
worked for back in college (at UC Irvine) used this compiler, and we
had one of the WD machines also, so this is something I'm quite
familiar with, as far as the deteriorating brain cells of my memory
permit.

This doesn't meet my criteria for what I'd call an interpreted
language.  For that, I'd assume that the interpreter reads the
original source statements, or some sort of tokenized form that bears
a close relation to the original source statements, while running the
program.  I'd also assume that variables and other identifiers are
stored by name, or by something equivalent such as a pointer into a
string table, but that in any case the interpreter does things "by
name".  In contrast, I believe that UCSD Pascal allocated local stack
variables pretty much the same way a native compiler would,
referencing them via byte or word offsets from the top or bottom of a
stack frame, although it's been a really long time so I could be wrong
here.

                                     -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[John B. Matthews]

In article 
<3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed@a31g2000prd.googlegroups.com>,
 Adam Beneschan <adam@irvine.com> wrote:

> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
> >
> >  cbcurl <cbc...@gmail.com> wrote:
> > > since when was Pascal ever an interpreted language
> >
> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
> 
> I wouldn't call it an interpreted language, really.  The UCSD 
> compiler generated code for a machine that didn't exist, and then 
> programs ran by interpreting that machine's instructions.  However, 
> my recollection is that the pseudo-machine's instruction set really 
> didn't have anything to do with Pascal and could have been used for 
> any language. A few years later, Western Digital developed a machine 
> that executed the P-machine's instructions directly (in microcode).  
> The lab I worked for back in college (at UC Irvine) used this 
> compiler, and we had one of the WD machines also, so this is 
> something I'm quite familiar with, as far as the deteriorating brain 
> cells of my memory permit.
> 
> This doesn't meet my criteria for what I'd call an interpreted 
> language.  For that, I'd assume that the interpreter reads the 
> original source statements, or some sort of tokenized form that bears 
> a close relation to the original source statements, while running the 
> program.  I'd also assume that variables and other identifiers are 
> stored by name, or by something equivalent such as a pointer into a 
> string table, but that in any case the interpreter does things "by 
> name".  In contrast, I believe that UCSD Pascal allocated local stack 
> variables pretty much the same way a native compiler would, 
> referencing them via byte or word offsets from the top or bottom of a 
> stack frame, although it's been a really long time so I could be 
> wrong here.

No, I believe you are correct, and you draw a useful distinction. Basic 
interpreters of that era stored tokenized keywords, but the variable 
names--at least the first few characters--were legible in the stored 
program. In contrast, the compiled p-code was quite generic; I briefly 
used a Fortran compiler that generated p-code, and I'm sure others were 
available. The p-code itself was interpreted.

I still enjoy using the system in emulation. As a concrete example,

]list

 10 A% = 12345: PRINT A%

]mtr
*800.81f
00/0800:00 12 08 0A 00 41 25 D0-.....A%P
00/0808:31 32 33 34 35 3A BA 41-12345::A
00/0810:25 00 00 00 64 C1 80 30-%...dA.0
00/0818:39 00 00 00 24 D0 E7 28-9...$Pg(

In Basic, the variable name "A" appears in both the tokenized source and 
the variable table; its value appears as a string literal and a 
twos-complement integer: 16#3039#.

$ ac -e Pascal.2mg test.text
{$R-}
program Test;
var
  a: Integer;
begin
  a := 12345;
  Writeln(a);
end.

$ ac -e Pascal.2mg temp.text
Code file = test.code
The following library bytes are non-zero:

TEST     is a linked segment  (P-code vers.6), length = 42 bytes
** # PROCS = 1, SEGMENT # = 1
Disassembly for procedure # 1; Lex level = 0
P-code procedure 1
Code = 27, parameters = 4, data = 2 bytes; Jump table = 0 words
   0: D7                            NOP    
   1: D7                            NOP    
   2: C7 39 30                      LDCI   12345
   5: AB 03                         SRO    3
   7: B6 01 03                      LOD    1,3
  10: EA                            SLDO 3 
  11: 00                            SLDC 0 
  12: CD 00 0D                      CXP    0,13
  15: 9E 00                         CSP    0
  17: B6 01 03                      LOD    1,3
  20: CD 00 16                      CXP    0,22
  23: 9E 00                         CSP    0
  25: C1 00                         RBP    0

Even without elaborating on the opcodes, it's clear that constant 
remains while variable and procedure names have been elided. When I 
encountered Java bytecode decades later, everything old was new again. 

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

John B. Matthews expounded in news:nospam-E19D5A.22083823032010
@news.aioe.org:

> In article 
> <3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed@a31g2000prd.googlegroups.com>,
>  Adam Beneschan <adam@irvine.com> wrote:
> 
>> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>> > In article
>> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>> >
>> >  cbcurl <cbc...@gmail.com> wrote:
>> > > since when was Pascal ever an interpreted language
>> >
>> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>> 
>> I wouldn't call it an interpreted language, really.  The UCSD 
>> compiler generated code for a machine that didn't exist, and then 
>> programs ran by interpreting that machine's instructions.  
-------------------^^^^^^^^^^^^

I smell an interpreter!

>> This doesn't meet my criteria for what I'd call an interpreted 
>> language.  For that, I'd assume that the interpreter reads the 
>> original source statements, or some sort of tokenized form that bears 
>> a close relation to the original source statements, while running the 
>> program.  

That's a pretty narrow view.

Usually ppl talk of "interpreted" vs "native code execution".
It would be incorrect IMO to call p-code natively executed
code.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 8:23 am, Warren <ve3...@gmail.com> wrote:
> John B. Matthews expounded in news:nospam-E19D5A.22083823032010
> @news.aioe.org:
>
>
>
>
>
> > In article
> > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...@a31g2000prd.googlegroups.com>,
> >  Adam Beneschan <a...@irvine.com> wrote:
>
> >> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> >> > In article
> >> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>
> >> >  cbcurl <cbc...@gmail.com> wrote:
> >> > > since when was Pascal ever an interpreted language
>
> >> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>
> >> I wouldn't call it an interpreted language, really.  The UCSD
> >> compiler generated code for a machine that didn't exist, and then
> >> programs ran by interpreting that machine's instructions.  
>
> -------------------^^^^^^^^^^^^
>
> I smell an interpreter!
>
> >> This doesn't meet my criteria for what I'd call an interpreted
> >> language.  For that, I'd assume that the interpreter reads the
> >> original source statements, or some sort of tokenized form that bears
> >> a close relation to the original source statements, while running the
> >> program.  
>
> That's a pretty narrow view.
>
> Usually ppl talk of "interpreted" vs "native code execution".
> It would be incorrect IMO to call p-code natively executed
> code.

So it's executed by an interpreter.  That doesn't make the *language*
compiled into p-code an INTERPRETED LANGUAGE, which is what we were
talking about---not any old "interpreter".

                                      -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

Adam Beneschan expounded in
news:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2000prd.googlegroups.com: 

> On Mar 24, 8:23�am, Warren <ve3...@gmail.com> wrote:
>> John B. Matthews expounded in news:nospam-E19D5A.22083823032010
>> @news.aioe.org:
>>
>>
>>
>>
>>
>> > In article
>> > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...@a31g2000prd.googlegroups.com>,
>> > �Adam Beneschan <a...@irvine.com> wrote:
>>
>> >> On Mar 23, 1:27�pm, "John B. Matthews" <nos...@nospam.invalid>
>> >> wrote 
>:
>> >> > In article
>> >> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.co
>> >> > m>, 
>>
>> >> > �cbcurl <cbc...@gmail.com> wrote:
>> >> > > since when was Pascal ever an interpreted language
>>
>> >> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>>
>> >> I wouldn't call it an interpreted language, really. �The UCSD
>> >> compiler generated code for a machine that didn't exist, and then
>> >> programs ran by interpreting that machine's instructions. �
>>
>> -------------------^^^^^^^^^^^^
>>
>> I smell an interpreter!
>>
>> >> This doesn't meet my criteria for what I'd call an interpreted
>> >> language. �For that, I'd assume that the interpreter reads the
>> >> original source statements, or some sort of tokenized form that
>> >> bears a close relation to the original source statements, while
>> >> running the program. �
>>
>> That's a pretty narrow view.
>>
>> Usually ppl talk of "interpreted" vs "native code execution".
>> It would be incorrect IMO to call p-code natively executed
>> code.
> 
> So it's executed by an interpreter.  That doesn't make the *language*
> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> talking about---not any old "interpreter".
> 
>                                       -- Adam

So by your definition, my "tokenized basic" isn't interpreted either?
It saves as an intermediate byte code also. So did GWBASIC IIRC. But 
nobody would say that GWBASIC wasn't interpreted.

Sorry, but if any "execution" requires the help of an interpreter,
it is "interpreted" at some level(s), even in Java's case.

Now if the O/S could load and hand control over control to the 
loaded code (exec) without involving a separate process, then 
that would be different. Otherwise, I still smell an interpreted
"language".

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 1:00 pm, Warren <ve3...@gmail.com> wrote:
> Adam Beneschan expounded innews:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2000prd.googlegroups.com:

> >> I smell an interpreter!
>
> >> >> This doesn't meet my criteria for what I'd call an interpreted
> >> >> language.  For that, I'd assume that the interpreter reads the
> >> >> original source statements, or some sort of tokenized form that
> >> >> bears a close relation to the original source statements, while
> >> >> running the program.  
>
> >> That's a pretty narrow view.
>
> >> Usually ppl talk of "interpreted" vs "native code execution".
> >> It would be incorrect IMO to call p-code natively executed
> >> code.
>
> > So it's executed by an interpreter.  That doesn't make the *language*
> > compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> > talking about---not any old "interpreter".
>
> >                                       -- Adam
>
> So by your definition, my "tokenized basic" isn't interpreted either?
> It saves as an intermediate byte code also. So did GWBASIC IIRC. But
> nobody would say that GWBASIC wasn't interpreted.

Please read carefully what I wrote earlier: "For that, I'd assume that
the interpreter reads the original source statements, or some sort of
tokenized form that bears a close relation to the original source
statements, while running the program."

I don't know what GWBASIC's intermediate byte code looked like.  But
if it was, in essence, an encoded representation of the source---"that
bears a close relation to the original source statements", to quote
myself---then it's an interpreted language.  p-code does not bear any
such relation to the Pascal source.  I know that the question of "how
close is the byte code to the source" is a fuzzy one.


> Sorry, but if any "execution" requires the help of an interpreter,
> it is "interpreted" at some level(s), even in Java's case.
>
> Now if the O/S could load and hand control over control to the
> loaded code (exec) without involving a separate process, then
> that would be different. Otherwise, I still smell an interpreted
> "language".

I think your definition of "interpreted language" is too broad to be
meaningful.  Suppose I had a Pascal compiler that generated code for a
processor that is no longer manufactured.  So I write a program that
emulates that processor.  That's effectively an interpreter, but does
that make Pascal an interpreted language?  Not in any meaningful
sense.  And what's the difference if the interpreter is for a
processor that no longer exists, or for a processor that never existed
such as the p-machine?

To relate it back to the topic of discussion: I think it was you that
claimed that it was meaningless to compare C/C++ results to Java, C#,
or Pascal (variants) because the latter were "largely interpreted
languages".  To be meaningful, a statement like that has to be talking
about the language as a whole, not just one or a few idiosyncratic
implementations of a language.  Some languages are definitely designed
to be interpreted---APL, Perl, and Lisp all allow you to build strings
or list structures at runtime that can be executed, and then execute
them.  Also, all of those languages support variables whose types can
change during execution, making it difficult to generate efficient
machine code.  I don't know much about Java, but I believe it was
designed to be interpreted (by a virtual Java machine) on different
platforms, although apparently it can be compiled; I don't know
whether the language design prevents it from being compiled into code
that's as efficient as other languages.  I don't know anything about
C#.

Pascal, on the other hand, doesn't have any of the characteristics
that make "interpreted languages" what they are.  Its variables are
statically typed, and there is no built-in facility for parsing and
executing a Pascal statement at runtime.  Whatever other features
there may be that are interesting about "interpreted languages",
Pascal doesn't have them.  In short, Pascal, as a *language*, is a
traditional compiled language and there is absolutely no basis for
putting it into the "interpreted language" category, period.  The fact
that one popular implementation of this language used a virtual
machine and an interpreter for that machine is irrelevant.

                                     -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4011 bytes --]

Adam Beneschan expounded in
news:104cd8d2-d4b4-4e47-9780-30746251da2d@a37g2000prd.googlegroups.com: 

> On Mar 24, 1:00�pm, Warren <ve3...@gmail.com> wrote:
>> Adam Beneschan expounded
>> innews:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2 
> 000prd.googlegroups.com:
> 
>> >> I smell an interpreter!
..
>> So by your definition, my "tokenized basic" isn't interpreted either?
>> It saves as an intermediate byte code also. So did GWBASIC IIRC. But
>> nobody would say that GWBASIC wasn't interpreted.
> 
> Please read carefully what I wrote earlier: "For that, I'd assume that
> the interpreter reads the original source statements, or some sort of
> tokenized form that bears a close relation to the original source
> statements, while running the program."

Apart from efficiencies, what does "close relation to source" have to
do with it? You still have another program "interpreting" it to 
carry out the instructions coded, in the original source.

> ..  p-code does not bear any
> such relation to the Pascal source.  I know that the question of "how
> close is the byte code to the source" is a fuzzy one.

Yep, but except where you have the interpreter in hardware, 
it is still interpreted. Of course hardware often uses 
software also (microcode), but usually people draw the
line at that boundary.

>> Sorry, but if any "execution" requires the help of an interpreter,
>> it is "interpreted" at some level(s), even in Java's case.
>>
>> Now if the O/S could load and hand control over control to the
>> loaded code (exec) without involving a separate process, then
>> that would be different. Otherwise, I still smell an interpreted
>> "language".
> 
> I think your definition of "interpreted language" is too broad to be
> meaningful.  

It's clear cut. If you need another executable to run it, then it's
interpreted. Though I will grant that there are a couple of exceptions
here also- the cobrun command that Open Cobol uses is a main program
stub that dynamically calls a cobol module (as a shared library) to 
load and execute it. But the same code can be compiled into a stand
alone executable -- and neither of these are interpreted.

> Suppose I had a Pascal compiler that generated code for a
> processor that is no longer manufactured.  So I write a program that
> emulates that processor.  

People usually call that "emulation".

> That's effectively an interpreter, but does
> that make Pascal an interpreted language?  

No. This is where the word emulator makes a useful distinction.

> And what's the difference if the interpreter is for a
> processor that no longer exists, or for a processor that never existed
> such as the p-machine?

Emulated theoretical concept of a machine code is usually
just viewed interpreted code. However modern usage has also 
brought in the idea of a "virtual machine". I think that is
more of a marketing concept than a useful term.

> To relate it back to the topic of discussion: I think it was you that
> claimed that it was meaningless to compare C/C++ results to Java, C#,
> or Pascal (variants) because the latter were "largely interpreted
> languages".  

I didn't say it was meaningless- just that there is no surprise
in that (aside prehaps from truly compiled Pascal).

> .. In short, Pascal, as a *language*, is a
> traditional compiled language and there is absolutely no basis for
> putting it into the "interpreted language" category, period.  

I'll disagree about the p-code implementation, but would otherwise
generally agree.

> The fact
> that one popular implementation of this language used a virtual
> machine and an interpreter for that machine is irrelevant.
>                                      -- Adam

It's not irrelevant, unless you _qualify_ what you're talking 
about. Otherwise some poor saps with a different background
in Pascal may come away with different and incorrect conclusions.

The fact that it was _popular_ means you have to deal with it
when making statements about the language's performance.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> The fact that it was _popular_ means you have to deal with it
> when making statements about the language's performance.

It was never as popular as Turbo Pascal. I can think of 2 p-code pascals:  
The original With pascal and USCS Pascal. I can think of five which  
compile native: Kyan Pascal, Oregon Pascal, GNU-Pascal, Free-Pascal and  
last but most important one: Turbo Pascal now Delphi. The sales and use of  
the later probably dwarfing the combined rest.

And that is out of the top of my head without google research. You are  
just plain wrong. Pascal was not designed as an interpreted language, most  
implementations are not interpreted the most popular implementation is not  
interpreted. You can turn in any way you like - the result is always the  
same: Pascal is not an interpreted language.

Regards

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u951g6eyz25lew@macpro-eth1.krischik.com: 

> Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:
> 
>> The fact that it was _popular_ means you have to deal with it
>> when making statements about the language's performance.
> 
> It was never as popular as Turbo Pascal. I can think of 2 p-code
> pascals:  The original With pascal and USCS Pascal. I can think of
> five which  compile native...
> 
> Martin

It was never a popularity contest ;-)  The fact that people
see it as "popular" (whether first place or last), means that 
a mention of Pascal needs to be a qualified one.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 26.03.2010, 19:21 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Martin Krischik expounded in
> news:op.u951g6eyz25lew@macpro-eth1.krischik.com:
>
>> Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:
>>
>>> The fact that it was _popular_ means you have to deal with it
>>> when making statements about the language's performance.
>>
>> It was never as popular as Turbo Pascal. I can think of 2 p-code
>> pascals:  The original With pascal and USCS Pascal. I can think of
>> five which  compile native...
>>
>> Martin
>
> It was never a popularity contest ;-)  The fact that people
> see it as "popular" (whether first place or last), means that
> a mention of Pascal needs to be a qualified one.

That would be "saw" it as popular. UCSD Pascal is dead long ago. You are  
clinging on the very last straw here to keep your argument up!

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u996t11wz25lew@macpro-eth1.krischik.com: 

> That would be "saw" it as popular. UCSD Pascal is dead long ago. You
> are  clinging on the very last straw here to keep your argument up!
> 
> Martin

I disagree. ;-)

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 24.03.2010, 21:00 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Otherwise, I still smell an interpreted
> "language".

As I already pointed out: I only say it is an interpreted *language* if  
the majority of *implementations* are interpreted. There are two different  
overlapping groups but they are not identical.

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:

> So it's executed by an interpreter.  That doesn't make the *language*
> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> talking about---not any old "interpreter".

My personal definition is that a language is interpreted if the majority  
of implementations use an interpreter. And Pascal would not be among the  
list.

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u950lqpyz25lew@macpro-eth1.krischik.com: 

> Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:
> 
>> So it's executed by an interpreter.  That doesn't make the *language*
>> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
>> talking about---not any old "interpreter".
> 
> My personal definition is that a language is interpreted if the
> majority  of implementations use an interpreter. And Pascal would not
> be among the  list.
> 
> Martin

I still maintain you need to be specific about it. I will 
agree that they all were not interpreted. But at the same 
time it is equally wrong to imply that they were all compiled.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 26.03.2010, 19:24 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Martin Krischik expounded in
> news:op.u950lqpyz25lew@macpro-eth1.krischik.com:
>
>> Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:
>>
>>> So it's executed by an interpreter.  That doesn't make the *language*
>>> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
>>> talking about---not any old "interpreter".
>>
>> My personal definition is that a language is interpreted if the
>> majority  of implementations use an interpreter. And Pascal would not
>> be among the  list.
>>
>> Martin
>
> I still maintain you need to be specific about it. I will
> agree that they all were not interpreted. But at the same
> time it is equally wrong to imply that they were all compiled.

I make it simple for you:

Pascal: language, not interpreted
UCSD-Pascal, language *implementation*, interpreted.

As you say: you have to be specific.

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in news:op.u9958tkwz25lew@macpro-
eth1.krischik.com:

>> I still maintain you need to be specific about it. I will
>> agree that they all were not interpreted. But at the same
>> time it is equally wrong to imply that they were all compiled.
> 
> I make it simple for you:
> 
> Pascal: language, not interpreted
> UCSD-Pascal, language *implementation*, interpreted.
> 
> As you say: you have to be specific.
> 
> Martin

The reason it's important here to distinguish, is that one might
assume "interpreted" by its quoted performance level. I recognize 
that p-code went out of fashion a long time ago, but for clarity..

"The prosecution rests."

Warren