Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
Andrea Taverna
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.
Richard Harter
You might also consider modern fortran.
Richard Harter, c...@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.
Francois PIETTE
> with combinatorial optimization problems.
> 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.
--
francoi...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
Pascal J. Bourguignon
> 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__
Ludovic Brenta
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.
Ludovic Brenta
[...]
> 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.
BGB / cr88192
"Andrea Taverna" <a.tavs...@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.
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...
Hibou57 (Yannick Duchêne)
> [...] 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.
Ben Bacarisse
<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.
Andrea Taverna
>
> > 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.
Pascal Obry
> 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
Andrea Taverna
> unnecessary headaches that I can get for using unsafe languages.
bad wording, should be:
and the /most important/ thing I care about...
Georg Bauhaus
> 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
Andrew Reilly
> 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
mockturtle
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.
>
>
> 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.
Andrea Taverna
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
Andrea Taverna
wrote:
> Of those, I'd use Modula-3.
>
Andrea
Pascal J. Bourguignon
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__
Pascal J. Bourguignon
> 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__
Hibou57 (Yannick Duchêne)
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).
Georg Bauhaus
> 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?
Hibou57 (Yannick Duchêne)
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.
Pascal J. Bourguignon
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__
Georg Bauhaus
> 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?
tm
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.
Jean-Pierre Rosen
[...]
> - 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
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 (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Nicholas Paul Collin Gloucester
|-----------------------------------------------------------------------------|
|"[..] |
| |
|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
Nicholas Paul Collin Gloucester
|--------------------------------------------------------------------------|
|"[..] |
| |
|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
Nicholas Paul Collin Gloucester
|-----------------------------------------------------------------------------|
|-----------------------------------------------------------------------------|
Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;
CeML; or Gaml?
Nicholas Paul Collin Gloucester
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. |
| |
|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. |
|the impressions I got for each language. |
|Can you help me? Feel free to recommend other languages as well. |
| |
| |
|--> 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. |
| |
|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 |
|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. |
| |
|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;
Mark T.B. Carroll
> 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
Nicholas Paul Collin Gloucester
|------------------------------------------------------------------------|
|------------------------------------------------------------------------|
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.
Mark T.B. Carroll
> On 2009-07-20, Mark T.B. Carroll <Mark.C...@Aetion.com> wrote:
>
> |------------------------------------------------------------------------|
> |"Nicholas Paul Collin Gloucester <Colin_Pau...@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
Hibou57 (Yannick Duchêne)
> 1) More than complex, Ada is feature-rich,
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).
tm
> 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.
Nicholas Paul Collin Gloucester
|---------------------------------------------------------------------------------------------------------------------|
|"Nicholas Paul Collin Gloucester <Colin_Pau...@ACM.org> writes: |
| |
|> On 2009-07-20, Mark T.B. Carroll <Mark.C...@Aetion.com> wrote: |
|> |
|> |------------------------------------------------------------------------| |
|> |"Nicholas Paul Collin Gloucester <Colin_Pau...@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�.
Georg Bauhaus
> 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.
Jean-Pierre Rosen
> 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.
> [...]
> 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...
Ben Bacarisse
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.
Tetrahedral Quartz
> 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.
Jon Harrop
> Have a look at Haskell.
He said performance was important.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop
> 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.
Jon Harrop
> 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.
>
> 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.
> 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
Martin
[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
Jon Harrop
> 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"
parnell
it is very new but it seems like a promising multi-paradigm
programming language.
Cheers,
Parnell
Mark T.B. Carroll
> 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
Colin Paul Gloster
|----------------------------------------------------------------------|
|"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.
Martin
> 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
Martin
> 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
Dmitry A. Kazakov
> 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
Andrea Taverna
> 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.
Hibou57 (Yannick Duchêne)
http://www.christ-usch-grein.homepage.t-online.de/Ada/Universe.html
Hibou57 (Yannick Duchêne)
> 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".
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.
Jon Harrop
> 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.
Jon Harrop
> 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.
Mark T.B. Carroll
(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
Georg Bauhaus
> 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.
Hibou57 (Yannick Duchêne)
wrote:
> Wow, that's amazing. I stopped using Modula-3 in the late 90's when it
> seemed to be dying under me;
Yes, it still live in your heart... do you feel it ?
I stop joking now
This is a community trouble, not a language trouble, as Modula-3 seems
to be the source of some other languages (like Java by the way, but
too much partly, not to talk about the reasons why I do not enjoy
Java).
Ex. The comp.lang.pascal is not any more, but Pascal is still alive
I guess people using Modula-3 nowadays are very happy with it (and
perhaps some have made their private Modula-4)
Part of the language “ war ” (don't like this word talking about
language, thus the quotes) is not due to concept, but also due to
fashion, market (and I forgot some). To me, unless a language died due
to concept troubles, it is not dead at all.
As you said, you still kept your book and did not throw it away.
Doesn't it make sense to you ? (like Modula-3 appearing in the title
of this thread). Mainstream (in particular) is full of examples of
designers designing in one language and thinking in an other one. I
guess you still oftenly think in Modula-3.
Christoph Schlegel
> "Hibou57 (Yannick Duchêne)" <yannick...@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.
Elego Software in Germany are maintaining and developing the now free
Critical Mass Modula-3 compiler with the help of others now. You may
want to have a look at their website. Discussions are mainly happening
in the mailing lists, while comp.lang.modula3 is very quiet...
Robert A Duff
> 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.
Andrew Reilly
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
Martin
> 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
Jon Harrop
> 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.
Martin
> 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
Jon Harrop
> 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.
Georg Bauhaus
> 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
Jon Harrop
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.
sjw
<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 ..
Dmitry A. Kazakov
> 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.
Colin Paul Gloster
|--------------------------------------------------------------------|
|"[..] |
| |
|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.
tm
> 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.
Dmitry A. Kazakov
> 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.
tm
> 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.
Jon Harrop
> Simplicity of languages and their implementation got lost somehow...
The F# team at Microsoft used to advertise that their compiler was under
10kLOC.
Georg Bauhaus
> 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?
tm
> 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.
Jon Harrop
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.
Jon Harrop
> 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).
tm
> 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.
Jon Harrop
> 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?
Wolfgang Ehrhardt
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)
bartc
"Wolfgang Ehrhardt" <Wolfgang.Ehrhar...@munich.netsurf.de>
wrote in message news:4a6a2335...@news.individual.net...
> On Fri, 24 Jul 2009 00:26:11 -0700 (PDT), tm <thomas...@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
wwilson
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/
robert...@yahoo.com
> 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.
Dmitry A. Kazakov
> 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!
Frank J. Lhota
> 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"
Dmitry A. Kazakov
> 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.)
wwilson
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.
wwilson
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.
Andrew Reilly
> 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
Mark T.B. Carroll
> Elego Software in Germany are maintaining and developing the now free
> Critical Mass Modula-3 compiler with the help of others now.
Hmmm. "Our software development teams are focused on advanced system
development in Java and C/C++ for the high-tech market." I wonder what
they get out of supporting Modula-3 too.
> You may want to have a look at their website. Discussions are mainly
> happening in the mailing lists, while comp.lang.modula3 is very
> quiet...
Ah, I shall have to check how many different posters they have on the
lists - thanks!
Mark
bartc
"Andrew Reilly" <andrew-...@areilly.bpc-users.org> wrote in message
news:7d20p0F...@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
tm
> "Wolfgang Ehrhardt" <Wolfgang.Ehrhardt.PLEASE.REM...@munich.netsurf.de>
> wrote in messagenews:4a6a2335...@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.
bartc
"tm" <thomas...@gmx.at> wrote in message
news:ffe34647-ed6d-4349...@v36g2000yqv.googlegroups.com...
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
Pascal J. Bourguignon
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__
bartc
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
Colin Paul Gloster
|--------------------------------------------------------------------------------|
|"[..] |
| |
|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
wwilson
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?
Colin Paul Gloster
|-----------------------------------------------------------------------------|
|"[..] |
| |
|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.