Today I tackled a problem that I had done twelve years ago.
I did it in four hours, and it took me about three months of
weekends back then. Today I did it in OCaml, back then I 
did it in C++.

I encounter many people who learn a new language and
then start trashing the languages they previously knew.
Typically the scenario I see are quotes of the form:
I just learned { Lisp, Smalltalk, Delphi, OCaml, Eiffel, Haskell}.
After learning it I now realise just how bad  {C, C++, VB, PhP, Perl}
is. Typically it is followed by a list of features

The funniest is I just learned Delphi and see just how bad VB is.
Delphi is the best programming language ever, precisely because 
it shows the lack of depth of the programmer, as well as his just
sheerly stupid arrogance.

Now a few languages ( VB ) are pretty limited, but most can pretty 
much do what others can. So it to trash a language because you
were inexperienced when you used iot is dumb. 

My experience bears me out, because from what I've seen of the 
work I did I would have to say that 12 years of experience 
( though I must admit many programmers I meet manage to
  gain 12 years of experience and learn absolutely nothing )
were much more responsible for the speed that I managed to
accomplish my task with.

It leaves me to believe that I would have taken four hours today
if I had done it in C++, and three months 12 years ago if I had
done it in OCaml.

That goes for any language that is sophisticated enough.












----------------------------
The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess.
----------------
Thaddeus L. Olczyk, PhD
Think twice, code once.

TLOlczyk <olczyk2002@yahoo.com> wrote in message news:<eq51rvgcdau0op373urooi1bs2m09qa50m@4ax.com>...
> Today I tackled a problem that I had done twelve years ago.
> I did it in four hours, and it took me about three months of
> weekends back then. Today I did it in OCaml, back then I 
> did it in C++.
> 
> I encounter many people who learn a new language and
> then start trashing the languages they previously knew.
> Typically the scenario I see are quotes of the form:
> I just learned { Lisp, Smalltalk, Delphi, OCaml, Eiffel, Haskell}.
> After learning it I now realise just how bad  {C, C++, VB, PhP, Perl}
> is. Typically it is followed by a list of features
> 
> The funniest is I just learned Delphi and see just how bad VB is.
> Delphi is the best programming language ever, precisely because 
> it shows the lack of depth of the programmer, as well as his just
> sheerly stupid arrogance.
> 
> Now a few languages ( VB ) are pretty limited, but most can pretty 
> much do what others can. So it to trash a language because you
> were inexperienced when you used iot is dumb. 

Ironically, there's a theory that pascal that suffers much of this -
up till a few years ago pascal was the main learning language of
colleges - so students felt that C and C++ was 'grown up' and for the
'real world' and associated pascal with their own past, their own
restrictions then.

In fairness to VB, it was for many years the easiest way to put
together a windows GUI app, slightly easier than Delphi (because it
has slightly less to learn).

Generally there isn't much you can do in C, Pascal, Basic that you
can't also do in Basic, Pascal and C!   (or make that java, c++,
delphi etc etc etc!)

The main issues for most projects are in areas of portability, speed,
third party library support, workforce available, tool costs/quality
and so on.

TLOlczyk wrote:

[...]

> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months 12 years ago if I had
> done it in OCaml.

I have in the past chosen to prototype stuff in SML and re-implement it 
in C++. SML is far more productive than C++ for me even though I'm far 
more experienced in C++ than in SML. As for why I have to re-implement 
it, some of the people I work with would rather I program in C. I can at 
least get away with C++. Some of us aren't trashing languages because we 
used them when we were inexperienced. We're trashing them because 
they're not very good programming languages. But as terrible as C++ is, 
it's better than raw C.

[...]

-thant

In comp.object TLOlczyk <olczyk2002@yahoo.com> wrote:
> The funniest is I just learned Delphi and see just how bad VB is.
> Delphi is the best programming language ever, precisely because 
> it shows the lack of depth of the programmer, as well as his just
> sheerly stupid arrogance.

.... and ignorance of Ada.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

TLOlczyk <olczyk2002@yahoo.com> writes:

> That goes for any language that is sophisticated enough.

Thank you for sharing your opinions.  The truth is: We don't know.
Programmers' productivity is not well understood.  We don't known how
much it depends on choosing a certain programming language, on working
in a motivated team, on having one of those cute infrared-mice next to
our keyboards.

In principle, you could conduct experiments to get some statistical
evidence on the programming language's influence on productivity (at
least for certain "typical" programming jobs).  I know only very few
studies which try to do this in a scientifically valid way (but then:
I'm no expert in this field).  Probably, these studies are hard to do,
you need lots of participants, and it is unclear if statistical
evidence would convince an XYZ-fan to migrate to language ABC after
all.

But we still want to convince others to use our most favorite
programming language.  (Because if more people use our language, more
tools are developed for it, more books are written about it, more jobs
are offered for it.)  Since we don't have real evidence to support
that XYZ is better than ABC to do OPQ-programming we share opinions.
If you use google you'll find plenty of opinions, leading to hot
debates on the topic.  The insight gained from these debates is often
small.

> Today I tackled a problem that I had done twelve years ago.
> I did it in four hours, and it took me about three months of
> weekends back then. Today I did it in OCaml, back then I 
> did it in C++.
> 
> I encounter many people who learn a new language and
> then start trashing the languages they previously knew.
> Typically the scenario I see are quotes of the form:
> I just learned { Lisp, Smalltalk, Delphi, OCaml, Eiffel, Haskell}.
> After learning it I now realise just how bad  {C, C++, VB, PhP, Perl}
> is. Typically it is followed by a list of features
> 
> The funniest is I just learned Delphi and see just how bad VB is.
> Delphi is the best programming language ever, precisely because 
> it shows the lack of depth of the programmer, as well as his just
> sheerly stupid arrogance.
> 
> Now a few languages ( VB ) are pretty limited, but most can pretty 
> much do what others can. So it to trash a language because you
> were inexperienced when you used iot is dumb. 
> 
> My experience bears me out, because from what I've seen of the 
> work I did I would have to say that 12 years of experience 
> ( though I must admit many programmers I meet manage to
>   gain 12 years of experience and learn absolutely nothing )
> were much more responsible for the speed that I managed to
> accomplish my task with.
> 
> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months 12 years ago if I had
> done it in OCaml.
> 
> That goes for any language that is sophisticated enough.

I like to think of it in terms of "advantages." For example, if I'm writing 
a program to balance my checkbook, I'll throw something together in VB real 
quick. If I was writing a network database program, I'd use Delphi; and if 
I was writing an operating system kernel, I'd use C. They all have their 
strong points, and some things just need to be done with certain languages 
lest you made your OWN language, which would be a real pain in the ass.

Personally, though, I think C has the one-up on all languages because it 
itself is very small and is independant of libraries. Therefore, the entire 
functionality of the language can change simply by swapping out the 
libraries. Obviously, too, is the fact that C is one of the BEST languages 
to use for memory referencing, which is vital for system-level 
applications.

What I don't like is Microsoft, constantly EXTENDING the C language into 
oblivion. When C++ came out, I thought, "What is this crap?" When C# came 
out, I thought, "What the HELL is THIS crap?" Microsoft's C languages have 
such HUGE libraries that it's impossible to know everything about them. You 
constantly need to rummage thru seemingly endless references to figure out 
how certain functions and classes work. It's rediculous! They'll probably 
come out with a new one this year, and I'll puke!

Muzzlebreak wrote:
<snip>
> What I don't like is Microsoft, constantly EXTENDING the C language into 
> oblivion. When C++ came out, I thought, "What is this crap?" When C# came 
> out, I thought, "What the HELL is THIS crap?" Microsoft's C languages have 
> such HUGE libraries that it's impossible to know everything about them. You 
> constantly need to rummage thru seemingly endless references to figure out 
> how certain functions and classes work. It's rediculous! They'll probably 
> come out with a new one this year, and I'll puke!

Uh... Microsoft isn't even vaguely responsible for C++.  They produced a 
compiler for it, but the language itself evolved completely outside 
their control.

C# on the other hand is pretty much theirs.  They may or may not have 
liberated it from elsewhere, but they're responsible for it :>

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote in
news:1068578455.161929@radsrv1.tranzpeer.net: 

> Muzzlebreak wrote:
> <snip>
>> What I don't like is Microsoft, constantly EXTENDING the C language
>> into oblivion. When C++ came out, I thought, "What is this crap?"
>> When C# came out, I thought, "What the HELL is THIS crap?"
>> Microsoft's C languages have such HUGE libraries that it's impossible
>> to know everything about them. You constantly need to rummage thru
>> seemingly endless references to figure out how certain functions and
>> classes work. It's rediculous! They'll probably come out with a new
>> one this year, and I'll puke! 
> 
> Uh... Microsoft isn't even vaguely responsible for C++.  They produced
> a compiler for it, but the language itself evolved completely outside 
> their control.
> 
> C# on the other hand is pretty much theirs.  They may or may not have 
> liberated it from elsewhere, but they're responsible for it :>
> 

Yes, but when C++ first appeared, Microsoft's had the biggest libraries, 
which is no surprise. At least Borland knew when to stop! MS can never get 
enough of libraries. It makes me sick.

TLOlczyk <olczyk2002@yahoo.com> might (or might not) have written this
on (or about)  Tue, 11 Nov 2003 04:42:45 -0600, :

>It leaves me to believe that I would have taken four hours today
>if I had done it in C++, and three months 12 years ago if I had
>done it in OCaml.

Overall I agree with this.  On the other hand, I am working in both
Java and C++ at the moment; and the tools for Java are so much nicer
than the tools for C++ that there's really no comparison.  I can work
much more quickly in Java.  

This isn't an indictment of C++; I love the language.  Rather it's a
statement about the tools that support the various languages.
Refactoring IDEs like IntelliJ and Eclipse make a *huge* difference in
productivity.  I didn't used to believe this, but I've been convinced
through first-hand use.  

I don't know if a good refactoring C++ IDE can be created.  I've heard
arguments both for and against.  What I *do* know is that there is
nothing like IntelliJ for C++ (yet).  

Robert C. Martin    | "Uncle Bob"                   
Object Mentor Inc.  | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716         
Suite 206           | Fax: (847) 775-8174           | www.objectmentor.com
                    |                               | www.XProgramming.com
Gurnee, IL,         | Training and Mentoring        | www.junit.org
60031               | OO, XP, Agile, C++, Java, C#  | http://fitnesse.org

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote in message news:<boqvq4$r9o$1@news.uni-stuttgart.de>...
> In comp.object TLOlczyk <olczyk2002@yahoo.com> wrote:
> > The funniest is I just learned Delphi and see just how bad VB is.
> > Delphi is the best programming language ever, precisely because 
> > it shows the lack of depth of the programmer, as well as his just
> > sheerly stupid arrogance.
> 
> ... and ignorance of Ada.

For most problems, Ada is not at all productive because the libraries
don't exists, or, if they do exist, are hard to find.  No matter what
language you choose, it's faster to write ten lines of code than to
write 250.

TLOlczyk wrote:

> My experience bears me out, because from what I've seen of the
> work I did I would have to say that 12 years of experience
> ( though I must admit many programmers I meet manage to
>   gain 12 years of experience and learn absolutely nothing )
> were much more responsible for the speed that I managed to
> accomplish my task with.
> 
> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months 12 years ago if I had
> done it in OCaml.

There is probably some truth to this.  I think another factor
is your own experience.  I would expect someone with 12 years
experience as a programmer to develop something faster than
someone with 2 years.

Languages themselves do play a role, though.  When I went to
teach myself Lisp recently, I created a game (Mastermind) in
pretty short time.  I'm *pretty* *sure* it would have taken me
a bit longer in C or C++ or Java.

But there are so many factors involved, it's hard to know.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

In article <36w4qxagafr.fsf@chagall.ti.uni-mannheim.de>,
 Matthias <no@spam.pls> wrote:

> TLOlczyk <olczyk2002@yahoo.com> writes:
> 
> > That goes for any language that is sophisticated enough.
> 
> Thank you for sharing your opinions.  The truth is: We don't know.
> Programmers' productivity is not well understood.  We don't known how
> much it depends on choosing a certain programming language, on working
> in a motivated team, on having one of those cute infrared-mice next to
> our keyboards.
> 
> In principle, you could conduct experiments to get some statistical
> evidence on the programming language's influence on productivity (at
> least for certain "typical" programming jobs).  I know only very few
> studies which try to do this in a scientifically valid way (but then:
> I'm no expert in this field).  Probably, these studies are hard to do,
> you need lots of participants, and it is unclear if statistical
> evidence would convince an XYZ-fan to migrate to language ABC after
> all.

It's very very hard to do this truly scientifically.  Perhaps the best 
we have is when a few hundred self-selected people select their own 
favourite language and implement a solution for the same well-defined 
and fairly complex specification over a period of several days.

The best example of this I know of is the yearly ICFP programming 
contest, which is the only contest I know of that gives complete freedom 
of language, and realistically complex tasks.

I don't think that winning ICFP proves your language is the best one -- 
and there are a lot of factors other than langauge that determine 
placings -- but it does tend to show that there isn't anything too 
seriously wrong with it, at least in expert hands.

This year C++ did well, but in previous years it has been dominated by 
staticly-typed languages such as O'Caml and ocassionally Haskell or C.  
Dylan is the only dynamically-typed language to do well with the Judges' 
Prize this year and 2nd Prize in 2001 [1]

C++ is getting to be a pretty formidable language in the hands of 
experts.  The problem is that almost no one can become truly expert in 
it, and even then only at great cost.

I know that for myself when I'm programming in C++ I spent most of my 
time thinking about C++, while when I program in Dylan I spend most of 
my time thinking about the problem.  Amazingly, I've seen this change of 
focus happen to people (coming from C++ and Java) with as little as a 
day's experience in Dylan.

-- Bruce

[1] disclaimer: I was in both teams

"Muzzlebreak" <s@e.a> wrote:
> Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote:
> > Muzzlebreak wrote:
> > <snip>
> >> What I don't like is Microsoft, constantly EXTENDING the C language
> >> into oblivion. When C++ came out, I thought, "What is this crap?"
> >> When C# came out, I thought, "What the HELL is THIS crap?"
> >> Microsoft's C languages have such HUGE libraries that it's impossible
> >> to know everything about them. You constantly need to rummage thru
> >> seemingly endless references to figure out how certain functions and
> >> classes work. It's rediculous! They'll probably come out with a new
> >> one this year, and I'll puke!
> >
> > Uh... Microsoft isn't even vaguely responsible for C++.  They produced
> > a compiler for it, but the language itself evolved completely outside
> > their control.
> >
> > C# on the other hand is pretty much theirs.  They may or may not have
> > liberated it from elsewhere, but they're responsible for it :>
> >
>
> Yes, but when C++ first appeared, Microsoft's had the biggest libraries,
> which is no surprise. At least Borland knew when to stop! MS can never get
> enough of libraries. It makes me sick.

You don't have use them.  What are you complaining about?

Dan.

"Bruce Hoult" <bruce@hoult.org> wrote:

> C++ is getting to be a pretty formidable language in the hands of
> experts.  The problem is that almost no one can become truly expert in
> it, and even then only at great cost.

It is a highly extensible language.  The problem is that
the extensibility was achieved by adding on a great deal
of complexity, at every level of the language design,
rather than orthogonality and elegance.

> I know that for myself when I'm programming in C++ I spent most of my
> time thinking about C++, while when I program in Dylan I spend most of
> my time thinking about the problem.  Amazingly, I've seen this change of
> focus happen to people (coming from C++ and Java) with as little as a
> day's experience in Dylan.

This has certainly been my experience.  I was much more
comfortable in both Dylan and OCaml after fairly minimal
exposure to those langauges than I have ever been in C++,
with which I've had much more experience.

Dan.

In article <bruce-C5752B.14082112112003@copper.ipg.tsnz.net>, Bruce Hoult
wrote:
> 
> The best example of this I know of is the yearly ICFP programming
> contest, which is the only contest I know of that gives complete
> freedom of language, and realistically complex tasks. I don't think
> that winning ICFP proves your language is the best one -- and there
> are a lot of factors other than langauge that determine placings --
> but it does tend to show that there isn't anything too seriously
> wrong with it, at least in expert hands.
> 
> This year C++ did well, but in previous years it has been dominated
> by staticly-typed languages such as O'Caml and ocassionally Haskell
> or C.  Dylan is the only dynamically-typed language to do well with
> the Judges' Prize this year and 2nd Prize in 2001.

Dylan has an /extremely/ coherent set of collection libraries; they
are some of the best I've seen in any language. By comparison Lisp,
C++, Java, and Ocaml all have fairly "warty" libraries -- the
different collection types in these languages each have somewhat
different interfaces. So you have to do more work remembering the
interfaces.

-- 
Neel Krishnaswami
neelk@cs.cmu.edu

[followups set to comp.programming]

Muzzlebreak wrote:

> Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote in
> news:1068578455.161929@radsrv1.tranzpeer.net:
> 
>> Muzzlebreak wrote:
>> <snip>
>>> What I don't like is Microsoft, constantly EXTENDING the C language
>>> into oblivion. When C++ came out, I thought, "What is this crap?"

<snip>

>> 
>> Uh... Microsoft isn't even vaguely responsible for C++.  They produced
>> a compiler for it, but the language itself evolved completely outside
>> their control.
>> 
<snip>
> 
> Yes, but when C++ first appeared, Microsoft's had the biggest libraries,

C++ first appeared (under that name) in 1983. I don't recall Microsoft 
producing a C++ compiler until around 1992 or 1993. They certainly weren't 
the first to produce an MS-DOS implementation of C++, let alone a Unix 
version.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

kcline17@hotmail.com (Kevin Cline) wrote in
news:ba162549.0311111340.280a5bf0@posting.google.com: 

> For most problems, Ada is not at all productive because the libraries
> don't exists, or, if they do exist, are hard to find.  No matter what
> language you choose, it's faster to write ten lines of code than to
> write 250.

I agree that writing something is often less productive than reusing
existing libraries. What I disagree with is the assertion that Ada
libraries do not exist or are hard to find for most problems.

Another problem with your statement is the apparent assumption that
productivity should be measured in how fast lines of code are written.
Productivity should be measured against the amount of effort required
to produce a properly working software system. 

Some languages are designed to maximize writing speed. C and Perl are
two examples. The common development model with C, and to a somewhat
lesser extent with C++, is to code, compile, then execute an extended
debug cycle, possibly including unit testing. Typically the debug
cycle is much longer than the initial coding and compile times.

Ada usually takes a little longer to write. It often takes much
longer to get a clean compile. On the other hand, the debug cycle
is normally very short for Ada because of the language rules and the
thorough job performed by the compiler for finding errors. The result
is consistent. The Ada program is usually completed in less time than
the C or C++ program. Statistics also show that the Ada program is
likely to have one half to one third the number of bugs as the released
C or C++ program.

Given those measures, Ada is often several times more productive than
C or C++. Generally, the larger the program the better Ada looks when
compared with C or C++.

Jim Rogers

Bruce Hoult <bruce@hoult.org> writes:

>Dylan is the only dynamically-typed language to do well [in the ICFP
>programming competition] with the Judges' Prize this year and 2nd Prize
>in 2001 [1]

Erlang also won the Judges' Prize in 2001, for being the best "lightning"
(24-hour) entry, and Python did the same in 2002.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

[Followups set to comp.programming]

James Rogers wrote:

> Some languages are designed to maximize writing speed. C and Perl are
> two examples. The common development model with C, and to a somewhat
> lesser extent with C++, is to code, compile, then execute an extended
> debug cycle, possibly including unit testing. Typically the debug
> cycle is much longer than the initial coding and compile times.

I accept that that may be your experience of C. It is not mine. I find that 
the most time-consuming part of C programming is the thinking. "What is the 
best way to solve this problem?" Coding and compiling don't take a terribly 
long time, as you rightly point out. The debug cycle is generally short, 
too.

The trick to C programming is to *know* the language.

Well, okay, the two tricks are to know the language and crank up the warning 
level.

Er, the three tricks...

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Richard Heathfield wrote:
> 
> [Followups set to comp.programming]
> 
> James Rogers wrote:
> 
> > Some languages are designed to maximize writing speed. C and Perl are
> > two examples. The common development model with C, and to a somewhat
> > lesser extent with C++, is to code, compile, then execute an extended
> > debug cycle, possibly including unit testing. Typically the debug
> > cycle is much longer than the initial coding and compile times.
> 
> I accept that that may be your experience of C. It is not mine. I find that
> the most time-consuming part of C programming is the thinking. "What is the
> best way to solve this problem?" Coding and compiling don't take a terribly
> long time, as you rightly point out. The debug cycle is generally short,
> too.
> 
> The trick to C programming is to *know* the language.
> 
> Well, okay, the two tricks are to know the language and crank up the warning
> level.
> 
> Er, the three tricks...
> 

And it comes down to the comfy chair, after all. 

> --
> Richard Heathfield : binary@eton.powernet.co.uk
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton


--
Les Cargill

TLOlczyk <olczyk2002@yahoo.com> wrote in message news:<eq51rvgcdau0op373urooi1bs2m09qa50m@4ax.com>...
> Today I tackled a problem that I had done twelve years ago.
> I did it in four hours, and it took me about three months of
> weekends back then. Today I did it in OCaml, back then I 
> did it in C++.
> 
> I encounter many people who learn a new language and
> then start trashing the languages they previously knew.

The important subtlety is:  Do they then believe that they are better
in the old languages as a result of learning the new?

If they don't, then it's more a useless complaint and I agree.

However, I personally have had conceptions for languages that only
became worthwhile once I learned lisp.  Because otherwise it would
have been a race to correct special cases.  So if I ever trash other
languages (in what I perceive to be friendly company), it is because
lisp solves enormous problems that I perceived before knowing about
lisp.  And eventually I will get this anger out of my system and act
more professionally.  But when you care about something, it is hard to
be completely detached.

tayss_temp@yahoo.com (Tayss) writes:

> TLOlczyk <olczyk2002@yahoo.com> wrote in message news:<eq51rvgcdau0op373urooi1bs2m09qa50m@4ax.com>...

>> I encounter many people who learn a new language and
>> then start trashing the languages they previously knew.

> The important subtlety is:  Do they then believe that they are better
> in the old languages as a result of learning the new?

I could probably write better C++ programs now, than a few years ago.
The problem is that I no longer want to :-)

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

>>> Muzzlebreak wrote:
>>> <snip>
>>>> What I don't like is Microsoft, constantly EXTENDING the C language
>>>> into oblivion. When C++ came out, I thought, "What is this crap?"
> 
> <snip>
> 
>>> 
>>> Uh... Microsoft isn't even vaguely responsible for C++.  They
>>> produced a compiler for it, but the language itself evolved
>>> completely outside their control.
>>> 
> <snip>
>> 
>> Yes, but when C++ first appeared, Microsoft's had the biggest
>> libraries, 
> 
> C++ first appeared (under that name) in 1983. I don't recall Microsoft
> producing a C++ compiler until around 1992 or 1993. They certainly
> weren't the first to produce an MS-DOS implementation of C++, let
> alone a Unix version.
> 

Talking about Mainstream, but let's just break out the microscope on it. I 
remember Microsoft being around when I first noticed, so I will include 
them. Peniswrinkle.

Muzzlebreak wrote:

<snip>
>>C++ first appeared (under that name) in 1983. I don't recall Microsoft
>>producing a C++ compiler until around 1992 or 1993. They certainly
>>weren't the first to produce an MS-DOS implementation of C++, let
>>alone a Unix version.
> 
> Talking about Mainstream, but let's just break out the microscope on it. I 
> remember Microsoft being around when I first noticed, so I will include 
> them. Peniswrinkle.

No matter how much you might like to do so, you can't blame Microsoft 
for any problem you perceive in C++.  Sorry.  They wrote a compiler, 
sure.  So did a lot of other people.  Their compiler isn't even a very 
good one, at the end of the day.  There are plenty of others like that 
too.  Seems silly to focus on theirs *shrug*

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

In article <bruce-C5752B.14082112112003@copper.ipg.tsnz.net>, Bruce Hoult wrote:
> I know that for myself when I'm programming in C++ I spent most of my 
> time thinking about C++, while when I program in Dylan I spend most of 
> my time thinking about the problem.  Amazingly, I've seen this change of 
> focus happen to people (coming from C++ and Java) with as little as a 
> day's experience in Dylan.

That has been our experience also, though the languages are
different. A friend at Ericsson put it in almost exactly those words:
"When I was programming in C I was wrestling with C all the time, in
Erlang we went home every day and felt we had solved problems".

Check out Erlang at http://www.erlang.org. (I'm more of a static
typing kind of guy myself; http://www.haskell.org, http://www.ocaml.org).

Stefan,
-- 
Stefan Axelsson                  (email at http://www.cs.chalmers.se/~sax)

Bruce Hoult <bruce@hoult.org> writes:

> In article <36w4qxagafr.fsf@chagall.ti.uni-mannheim.de>,
>  Matthias <no@spam.pls> wrote:
> > In principle, you could conduct experiments to get some statistical
> > evidence on the programming language's influence on productivity (at
> > least for certain "typical" programming jobs).  I know only very few
> > studies which try to do this in a scientifically valid way (but then:
> > I'm no expert in this field).  Probably, these studies are hard to do,
> > you need lots of participants, and it is unclear if statistical
> > evidence would convince an XYZ-fan to migrate to language ABC after
> > all.
> 
> It's very very hard to do this truly scientifically.  Perhaps the best 
> we have is when a few hundred self-selected people select their own 
> favourite language and implement a solution for the same well-defined 
> and fairly complex specification over a period of several days.

I totally agree.  Sometimes I wish everyone involved in a programming
language flamewar had to contribute 10 cents for each usenet-posting
to a fund which would finance such research. ;-)

> The best example of this I know of is the yearly ICFP programming 
> contest, which is the only contest I know of that gives complete freedom 
> of language, and realistically complex tasks.

I also like the ICFP-idea (although I never participated).
Unfortunately, it gathers data very slowly (with one contest a year it
takes long to capture enough data).  A website which does a mini-ICFP
every month or so would be cute.  Does anybody know if such a thing
exists?

In article <slrnbr3bcs.pgl.neelk@gs3106.sp.cs.cmu.edu>,
 Neelakantan Krishnaswami <neelk@cs.cmu.edu> wrote:

> In article <bruce-C5752B.14082112112003@copper.ipg.tsnz.net>, Bruce Hoult
> wrote:
> > 
> > The best example of this I know of is the yearly ICFP programming
> > contest, which is the only contest I know of that gives complete
> > freedom of language, and realistically complex tasks. I don't think
> > that winning ICFP proves your language is the best one -- and there
> > are a lot of factors other than langauge that determine placings --
> > but it does tend to show that there isn't anything too seriously
> > wrong with it, at least in expert hands.
> > 
> > This year C++ did well, but in previous years it has been dominated
> > by staticly-typed languages such as O'Caml and ocassionally Haskell
> > or C.  Dylan is the only dynamically-typed language to do well with
> > the Judges' Prize this year and 2nd Prize in 2001.
> 
> Dylan has an /extremely/ coherent set of collection libraries; they
> are some of the best I've seen in any language. By comparison Lisp,
> C++, Java, and Ocaml all have fairly "warty" libraries -- the
> different collection types in these languages each have somewhat
> different interfaces. So you have to do more work remembering the
> interfaces.

This is true.  Dylan gives you keyed access to any collection using the 
same coll[key] syntax as Pascal/C/Perl use for arrays, and sequential 
access to any collection using "for(elt in coll)", and it's polymorphic, 
so a function doesn't even have to know what sort of collection it is 
being given (but it's faster if it *does* know).  Even better, user 
defined collections fit right in seamlessly.  It's amazing how much 
flexibility this lets you retain until very late in the development 
process -- or even permanently, in those sections of the program where 
you don't need C-like speed.

-- Bruce

Muzzlebreak wrote:

> 
> What I don't like is Microsoft, constantly EXTENDING the C language into 
> oblivion. When C++ came out, I thought, "What is this crap?" 
Are you saying MS invented C++? I think Bjarne Stroustrup may be 
surprised to hear that. I am not aware of MS extending the C or C++ 
language. Rather the opposite, VC++ 6 did not fully implement the C++ 
standard, I'm not sure about VC++.Net.


When C# came
> out, I thought, "What the HELL is THIS crap?" 
You don't have to use it, personally I find it more productive than 
C/C++ on Windows.

In article <3fb1c315$1@news.unimelb.edu.au>,
 Fergus Henderson <fjh@cs.mu.oz.au> wrote:

> Bruce Hoult <bruce@hoult.org> writes:
> 
> >Dylan is the only dynamically-typed language to do well [in the ICFP
> >programming competition] with the Judges' Prize this year and 2nd Prize
> >in 2001 [1]
> 
> Erlang also won the Judges' Prize in 2001, for being the best "lightning"
> (24-hour) entry, and Python did the same in 2002.

Oops, you're right.  That statement was something I researched for my 
(pre results) write-up in 2001, and I hadn't updated it :-(

The "Lightning" prize tends to have a bit of a different flavour to the 
contest as a whole -- it's usually quite enough of a challenge to solve 
the task in three days, so doing it in 24 hours is really really hard 
and you're not likely to have to compete on performance.

-- Bruce

Corey Murtagh wrote:
> Uh... Microsoft isn't even vaguely responsible for C++.  They produced a 
> compiler for it, but the language itself evolved completely outside 
> their control.

They have been extending the language with tons of modifiers (_near, 
_far in olden DOS times; _stdcall, long long, extensions for IDL etc. 
etc. etc.).
I once worked with a documentation extraction program for C/C++. We had 
problems and worked with the supplier of that program; the guys once 
mentioned that "all C++ compilers have warts, but the Microsoft 
compilers are worst. Every release comes up with new nonstandard 
extensions".

Regards,
Jo

Uncle Bob (Robert C. Martin) wrote:
> 
> Overall I agree with this.  On the other hand, I am working in both
> Java and C++ at the moment; and the tools for Java are so much nicer
> than the tools for C++ that there's really no comparison.  I can work
> much more quickly in Java.  
> 
> This isn't an indictment of C++; I love the language.

My observation is that C++ as a language is so complicated that it's 
horribly difficult to write reliable refactoring tools. The net effect 
is that authors of C++ tools have less time to spend on making their 
tools nicer (regardless of the definition of "nice").

Given that the dead simple languages (Lisp, Smalltalk) were the first to 
have nice tools, I suspect we have a spectrum here: simple languages 
with massive tool support to complex languages with little tool support.

If the language complexity isn't designed to replace the tools, the 
complex language will lose in the long term: even those who love it will 
be more productive in the simpler language.
(That's a large part of what I mean when I say that "C++ isn't powerful 
enough for its complexity".)

Regards,
Jo

In article <36wznf1ewas.fsf@chagall.ti.uni-mannheim.de>,
 Matthias <no@spam.pls> wrote:

> Bruce Hoult <bruce@hoult.org> writes:
> 
> > The best example of this I know of is the yearly ICFP programming 
> > contest, which is the only contest I know of that gives complete freedom 
> > of language, and realistically complex tasks.
> 
> I also like the ICFP-idea (although I never participated).
> Unfortunately, it gathers data very slowly (with one contest a year it
> takes long to capture enough data).  A website which does a mini-ICFP
> every month or so would be cute.  Does anybody know if such a thing
> exists?

TopCoder has a contest per week, but that has severely restricted 
language choice.

One a year does take a while to build up results, but it can be done if 
you stick to it for a while:

  http://www.gwydiondylan.org/contests.phtml

Certainly my co-conspirators and I hope this participation is helpful 
for gaining mind-share -- and I think it's working.  It does seem to be 
effective for getting our site slashdotted on a regular basis :-)

-- Bruce

"Muzzlebreak" <s@e.a> wrote in message
news:Xns94308E14A6DF2n@63.223.8.240...
> What I don't like is Microsoft, constantly EXTENDING the C language into
> oblivion. When C++ came out, I thought, "What is this crap?" When C# came
> out, I thought, "What the HELL is THIS crap?" Microsoft's C languages have
> such HUGE libraries

You are more than welcome to post your proposal of how to make C (or any
other language) effective for developing all the kinds of applications that
are developed today, without HUGE libraries.

> that it's impossible to know everything about them.

Who said you were expected to?

M.

In article <bot3po$g3h$1@news.oberberg.net>,
 Joachim Durchholz <joachim.durchholz@web.de> wrote:

> If the language complexity isn't designed to replace the tools, the 
> complex language will lose in the long term: even those who love it will 
> be more productive in the simpler language.
> (That's a large part of what I mean when I say that "C++ isn't powerful 
> enough for its complexity".)

Right.

I actually think the initial C++ work was brilliant.  The synergy of, 
for example, stack-based objects, copy constructor/assignment operator, 
destructors, and references was just amazing.

But then everything after that seemed to be full of bad decisions.  
Exceptions should have had call semantics, not termination semantics.  
The "inherited::" Smalltalk/Object Pascal-like proposal (or something 
better, such as Lisp/Dylan's "next-method") should have been accepted.  
Yes, I know there are rationalizations for these decisions in D&E, but 
they are wrong.

Really, each of the post-ARM developments looks OK in isolation, but 
they just don't have any synergies.  The whole isn't greater than the 
parts like it should be.

-- Bruce

Joachim Durchholz wrote (snipped):

> They have been extending the language with tons of modifiers (_near, 
> _far in olden DOS times; _stdcall, long long, extensions for IDL etc. 
> etc. etc.).

I am very far from being a Microsoft fan, but surely _near and _far were an
inevitable consequence of Intel's 16-bit instruction set?

George Russell wrote:
> I am very far from being a Microsoft fan, but surely _near and _far were an
> inevitable consequence of Intel's 16-bit instruction set?

wasn't it rather a consequence of MS-DOG's brain damage and lack of 
decent memory management? I'm just asking, glad to never have programmed 
for DOG :)

-- 
Segui il tuo corso, e lascia dir le genti.

Lars

[followups set]

L.J. Buitinck wrote:

> George Russell wrote:
> 
>> I am very far from being a Microsoft fan, but surely _near and _far 
>> were an
>> inevitable consequence of Intel's 16-bit instruction set?
> 
> wasn't it rather a consequence of MS-DOG's brain damage and lack of 
> decent memory management? I'm just asking, glad to never have programmed 
> for DOG :)

DOS's memory management was constrained by the architecture.  It's not 
like there was the option to set the PC into a flat memory model and use 
32-bit pointers at that point.  So to get around it, you had to use a 
pointer composed of a segment and an offset, and compilers had to either 
restrict programs to 64k or provide a mechanism for handling 'far' (ie: 
out-of-segment) pointers.

So step down off that high horse for a moment, put your Anti-MS 
prejudices on hold and tell us... how exactly do /YOU/ think it should 
have worked considering the architecture constraints?  How would /YOU/ 
have solved the problem, huh?

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:

> L.J. Buitinck wrote:
> 
> > George Russell wrote:
> > 
> >> I am very far from being a Microsoft fan, but surely _near and _far 
> >> were an
> >> inevitable consequence of Intel's 16-bit instruction set?
> > 
> > wasn't it rather a consequence of MS-DOG's brain damage and lack of 
> > decent memory management? I'm just asking, glad to never have programmed 
> > for DOG :)
> 
> DOS's memory management was constrained by the architecture.  It's not 
> like there was the option to set the PC into a flat memory model and use 
> 32-bit pointers at that point.  So to get around it, you had to use a 
> pointer composed of a segment and an offset, and compilers had to either 
> restrict programs to 64k or provide a mechanism for handling 'far' (ie: 
> out-of-segment) pointers.
> 
> So step down off that high horse for a moment, put your Anti-MS 
> prejudices on hold and tell us... how exactly do /YOU/ think it should 
> have worked considering the architecture constraints?  How would /YOU/ 
> have solved the problem, huh?

This depends on what problem I was trying to solve.  If the purpose
was to implement the language faithfully, I would have used 32-bit
(segment+offset) pointers by default (taking the performance hit this
implies) but allow several pointer values to share the same segment
where static analysis shows that this is possible.  If I wanted to
make a C-like language for making efficient code for 8086, I would
differentiate 16-bit and 32-bit quantities (both integers and
pointers) by type, but I wouldn't call the language C.  I might have
included in the manual a guide for how C programs could be ported to
the new language, though.

	Torben Mogensen

George Russell wrote:
> Joachim Durchholz wrote (snipped):
> 
>> They have been extending the language with tons of modifiers
>> (_near, _far in olden DOS times; _stdcall, long long, extensions
>> for IDL etc. etc. etc.).
> 
> I am very far from being a Microsoft fan, but surely _near and _far
> were an inevitable consequence of Intel's 16-bit instruction set?

Far from "inevitable" - near pointers never made much of a sense, so
32-bit pointers could have been the standard.
The remaining uses for 16-bit pointers were for low-level code, and in
these days, "low-level" meant assembly, not C...

Regards,
Jo

Corey Murtagh wrote:
> So step down off that high horse for a moment, put your Anti-MS 
> prejudices on hold and tell us... how exactly do /YOU/ think it should 
> have worked considering the architecture constraints?  How would /YOU/ 
> have solved the problem, huh?

I can't talk for Corey, but I'd have used 32-bit pointers by default.

Regards,
Jo

"Myles" <a@b.c> writes:

> You are more than welcome to post your proposal of how to make C (or any
> other language) effective for developing all the kinds of applications that
> are developed today, without HUGE libraries.

You seem to be labouring under the misconception that one single
language should be used for all kinds of application.

C was designed for writing the UNIX kernel, and did a reasonable job
of that by allowing programming close to the machine-level without
making it too difficult to port a program to a different architecture.
The problem is that C has since been used for a lot of things where it
is ill suited, and each such use has caused a large number of
libraries with wildly inconsistent conventions to be developed.

A modern language should be designed with a special purpose in mind
and fairly qiuckly get good libraries for that.  It may show itself
useful for a few other purposes apart from the one it was designed
for, and libraries for these purposes will eventually appear.

No language will be well-suited for all problems, so a programmer that
want to work with a wide range of problems should expect to learn a
wide range of programming languages.  Otherwise, we get the "Real
Programmer" syndrome�:

    * Real Programmers do List Processing in Fortran.

    * Real Programmers do String Manipulation in Fortran.

    * Real Programmers do Accounting (if they do it at all) in Fortran.

    * Real Programmers do Artificial Intelligence programs in Fortran.

  If you can't do it in Fortran, do it in assembly language. If you
  can't do it in assembly language, it isn't worth doing.


	Torben

�From "Real Programmers Don't Use Pascal" by Ed Post, see e.g.
http://www.pbm.com/~lindahl/real.programmers.html .

Joachim Durchholz wrote:

> Corey Murtagh wrote:
> 
>> So step down off that high horse for a moment, put your Anti-MS 
>> prejudices on hold and tell us... how exactly do /YOU/ think it should 
>> have worked considering the architecture constraints?  How would /YOU/ 
>> have solved the problem, huh?
> 
> I can't talk for Corey, but I'd have used 32-bit pointers by default.

On a 16-bit architecture which doesn't support them?  Nice trick, if you 
can achieve it.

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Torben �gidius Mogensen wrote (snipped):

> This depends on what problem I was trying to solve.  If the purpose
> was to implement the language faithfully, I would have used 32-bit
> (segment+offset) pointers by default (taking the performance hit this
> implies) but allow several pointer values to share the same segment
> where static analysis shows that this is possible.  If I wanted to
> make a C-like language for making efficient code for 8086, I would
> differentiate 16-bit and 32-bit quantities (both integers and
> pointers) by type, but I wouldn't call the language C.  I might have
> included in the manual a guide for how C programs could be ported to
> the new language, though.

I love it when people claim they can solve all the world's problems by
static analysis.  When you have a function which takes 3 pointer arguments,
whatttya gonna do, compile lots of different versions for all the different
combinations of same-segment, different segment.  (This will mean your code
explodes, meaning function calls which could have been near might end up having
to be made far.)  Or are you going to do whole-program analysis to determine
all the different ways each function might be called?  This will be fun,
prevent you producing libraries, and mean compilation takes much longer.
(It already took long enough in 1991, I remember.)

Microsoft C *did* I think have an option allowing you to specify whether
all pointers should be near, far or huge by default.  I don't see what more
they could have done, realistically.  Even that meant they had to include
umpteen different versions of the compiled libraries on the installation
disks (lots of floppies), for all the different combinations of near/far/huge
pointers to code and near/far/huge pointers to data.

And if you are going to add storage qualifiers _near and _far, why on earth
shouldn't you call your language C?  From what I can remember, such extensions
are explicitly permitted by the ANSI/ISO standard.

Joachim Durchholz wrote (snipped):

> Far from "inevitable" - near pointers never made much of a sense, so
> 32-bit pointers could have been the standard.
> The remaining uses for 16-bit pointers were for low-level code, and in
> these days, "low-level" meant assembly, not C...

Your memory of those days must be different from mine.  There is quite a lot
you can do with 16-bit pointers.  65kB seemed more than it does now ...

On Wed, 12 Nov 2003 04:33:08 GMT, James Rogers
<jimmaureenrogers@att.net> wrote:

> The common development model with C, and to a somewhat
>lesser extent with C++, is to code, compile, then execute an extended
>debug cycle, possibly including unit testing. Typically the debug
>cycle is much longer than the initial coding and compile times.

Not if I'm running the show ;-)

On a sizeable real project especially one with a significant user
interface, a large proportion of "time til release" is spent on
requirements and design, which you don't even mention. (This may be
the reason for your impression of what's "typical.")  Initial code and
compile is usually a rather small part of the time. Testing and debug
is an iterative process, but usually the testing takes longer than the
debugging, and I expect it to be shorter than the design phase.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Wed, 12 Nov 2003 14:22:22 +0100, Joachim Durchholz
<joachim.durchholz@web.de> wrote:

>George Russell wrote:
>> Joachim Durchholz wrote (snipped):
>> 
>>> They have been extending the language with tons of modifiers
>>> (_near, _far in olden DOS times; _stdcall, long long, extensions
>>> for IDL etc. etc. etc.).
>> 
>> I am very far from being a Microsoft fan, but surely _near and _far
>> were an inevitable consequence of Intel's 16-bit instruction set?
>
>Far from "inevitable" - near pointers never made much of a sense, so
>32-bit pointers could have been the standard.
>The remaining uses for 16-bit pointers were for low-level code, and in
>these days, "low-level" meant assembly, not C...
>
32-bit pointers are very slow on a 16-bit cpu.

Believe it or not, many useful programs have been written in 64K or
less.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

George Russell wrote:

> Joachim Durchholz wrote (snipped):
> 
>> Far from "inevitable" - near pointers never made much of a sense, so
>> 32-bit pointers could have been the standard.
>> The remaining uses for 16-bit pointers were for low-level code, and in
>> these days, "low-level" meant assembly, not C...
> 
> 
> Your memory of those days must be different from mine.  There is quite a 
> lot
> you can do with 16-bit pointers.  65kB seemed more than it does now ...

Programs programmed with 16-bit pointers always crashed on me, due to 
size restrictions. It was one of the more annoying phenomena of that time.

Regards,
Jo

Alan Balmer wrote:
> 32-bit pointers are very slow on a 16-bit cpu.

Agreed.
The '286 was a *very* braindead design.

> Believe it or not, many useful programs have been written in 64K or
> less.

Useful - well, yes. I'll admit that at gun point. If I must. ;-)

Seriously, working with that software was mostly a pain in the a**. I 
routinely wrote text documents at that time, and having to break up 
files to avoid hitting the 64K limit was hell.
Doing a database dump ended with a file that was largely unusable 
because it was bigger than 64K. Actually, any kind of dump was unusable 
once it went beyond the 64K limits.
/Much/ later, editors arrived that could handle large files. Until then, 
life was quite miserable.

Regards,
JO

On Wed, 12 Nov 2003 14:08:21 +1300, Bruce Hoult <bruce@hoult.org>
wrote:


I know that for myself when I'm programming in C++ I spent most of my 
time thinking about C++, while when I program in Dylan I spend most of

my time thinking about the problem.  Amazingly, I've seen this change
of 
focus happen to people (coming from C++ and Java) with as little as a 
day's experience in Dylan.
>I know that for myself when I'm programming in C++ I spent most of my 
>time thinking about C++, while when I program in Dylan I spend most of 
>my time thinking about the problem.  Amazingly, I've seen this change of 
>focus happen to people (coming from C++ and Java) with as little as a 
>day's experience in Dylan.


This is why I love Smalltalk.  With only a very few simple language
rules applied universally, I spend a lot less time thinking about
language syntax and semantics and more time thinking about actually
solving problems.

Coupled with the strength of the dev tools...

On Thu, 13 Nov 2003, Corey Murtagh wrote:
>
> Joachim Durchholz wrote:
> > Corey Murtagh wrote:
> >
> >> So step down off that high horse for a moment, put your Anti-MS
> >> prejudices on hold and tell us... how exactly do /YOU/ think it should
> >> have worked considering the architecture constraints?  How would /YOU/
> >> have solved the problem, huh?
> >
> > I can't talk for Corey, but I'd have used 32-bit pointers by default.
>
> On a 16-bit architecture which doesn't support them?  Nice trick, if you
> can achieve it.

The 8086 supported 32-bit pointers.  You'd stick the segment into
ES and the offset into BX, and then the machine would "compute" the
proper (20-bit) physical address for you.  Sure, the machine didn't
have a full 4GB of addressable memory, but there's no reason the
compilers of the day couldn't have used 32-bit pointers, plus some
extra code to keep them normalized and perform pointer comparisons
and so on.

  Recognizing the applicability of 64K apps, though, I'd have gone
the extra mile and made pointer size a configurable option.  Let
those small programs get the speed and size boost from only using
one data segment, but still allow big programs to work correctly
without mucking about with 'near' and 'far' and whatnot.

  [Maybe I'm talking through my hat, though, since the 8086 toy
compiler *I've* developed (not for C) doesn't have such an option
-- it's pure 64K.  Maybe I'll get around to putting one in.  Soon.
Maybe.    Plug: http://www.geocities.com/arthur_odwyer/day9/ ]

-Arthur

James Rogers wrote:

> I agree that writing something is often less productive than reusing
> existing libraries.

Sort of an aside...

I've been reading Richard Gabriel's PATTERNS OF SOFTWARE (patterns
not, AFAICT, in the way of the GOF book), and he wrote something
interesting about libraries. Heavily edited:

    First, you need to have a central repository of code. It
    doesn�t help if developers have to go around to other
    developers to locate code you might be able to use.

    Second, there has to be a means of locating the right piece
    of code, which usually requires a good classification scheme.
    [...] But few software organizations can afford a software
    cataloger, let alone a librarian to help find the software
    for its developers.

    Third, there must be good documentation of what each piece
    of code in the repository does. [...] In many cases such
    documentation is just the code itself, but this information
    could be better provided by ordinary documentation;...

    [Thus, for] a lot of pieces of code it is just plain simpler
    to write it yourself than to go through the process of finding
    and understanding reusable code.

Interesting paper (so far).  Available free:
    http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf

He uses the writings of architect, Christopher Alexander (who also
wrote the preface) in talking about design--something found very
interesting in that I've always considered architecture to be very
close analog to programming.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Muzzlebreak wrote:

> Personally, though, I think C has the one-up on all languages
> because it itself is very small and is independant of libraries.

Yet dependant upon them to do anything useful! (like I/O)

There is a theory that programmers tend to prefer smaller languages
because they can be retained mentally better.  I mentioned Richard
Gabriel's book, PATTERNS OF SOFTWARE (see elsethread).  He wrote
something I'd thought to start a thread with, but perhaps it fits
here better.  He is speaking about abstractions (something most
programmers hold up as entirely desireable--but some disagree):

    Abstractions must be carefully and expertly designed,
    especially when reuse or compression[1] is intended.
    However, because abstractions are designed in a partic-
    ular context and for a particular purpose, it is hard
    to design them while anticipating all purposes and
    forgetting all purposes, which is the hallmark of the
    well designed abstractions.

    This implies that abstractions are best designed by experts.
    Worse, average programmers are not well-equipped to design
    abstractions that have universal usage,...

[Ties in to a recent sorta conclusion we come to here talking about
OOP--that it requires more training and expertise to use well.]

    ....even though the programming languages used by average
    programmers and the programming language texts and courses
    average programmers read and attend to learn their trade
    emphasize the importance of doing exactly that.

    Not everyone is a poet, but most anybody can write usable
    documentation for small programs�we don�t expect poets to
    do this work. Yet we seem to expect that the equivalent of
    poets will use high-level programming languages, because
    only program-poets are able to use them. In light of this
    observation, is it any wonder that abstraction-poor
    languages like C are by far the most popular and that
    abstraction-rich ones like Lisp and Smalltalk are niche
    languages?

There is also that Lisp and Smalltalk have *huge* libraries that
are (in Lisp's case for sure, and IIRC, Smalltalk's) treated as
part of the language.  ANSI Common Lisp defines about 1000 keywords
(!!!!) and the language spec is about 1300 pages!  Compare that to
the K&R C book.

___________________________________________________________________
[1] Compression is an aspect of text where a piece of text has a
    greater meaning in context than it does intrinsically.  Gabriel
    prefers "compression" to "reuse" when talking of inheritance.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Joachim Durchholz wrote:

> Given that the dead simple languages (Lisp, Smalltalk)...

Dead simple?  As I just wrote, Lisp has about 1000 keywords defined
as part of the language (due the library being considered as part
of--and indistinquishable from--core Lisp), and the spec is about
1300 pages.

*Not* dead simple overall (although the Lisp core is).

(Don't get me wrong: I love Lisp!!)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:

>DOS's memory management was constrained by the architecture.  It's not 
>like there was the option to set the PC into a flat memory model and use 
>32-bit pointers at that point.

There was certainly an option to use 32-bit pointers.  It was called
"large model".  You couldn't actually use all of the 32 bits, only 28,
but apart from that, application programmers could essentially ignore
segmentation.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

George Russell <ger@tzi.de> writes:

>Microsoft C *did* I think have an option allowing you to specify whether
>all pointers should be near, far or huge by default.  I don't see what more
>they could have done, realistically.

Quite a bit, actually.  For example, they could have avoided referring
to "near" and "far" in their compiler error messages in cases where the
programmer was not using mixed-model programming.

>And if you are going to add storage qualifiers _near and _far, why on earth
>shouldn't you call your language C?  From what I can remember, such extensions
>are explicitly permitted by the ANSI/ISO standard.

You remember wrong.  The names "_near" and "_far" are in the user's namespace,
not the implementation's.  For example, the following is a strictly conforming
C program:

	int _near;
	int main() { return _near; }

But it didn't work with most versions of Microsoft's C compiler, IIRC.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

George Russell wrote:
> Joachim Durchholz wrote (snipped):
> 
> > They have been extending the language with tons of modifiers
> > (_near, _far in olden DOS times; _stdcall, long long, extensions
> > for IDL etc. etc. etc.).
> 
> I am very far from being a Microsoft fan, but surely _near and _far
> were an inevitable consequence of Intel's 16-bit instruction set?

Far from it.  Just as an example, it would be possible to have the
code generators always generate far calls (and returns), except in
the case where the function is marked static.  I will concede in
advance that other penalties would result, but the source would be
portable.  However, such usage would require innovation and
thought from Microsoft, rather than aping others and encouraging
lock-ins to their own systems.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Corey Murtagh wrote:
> Joachim Durchholz wrote:
> > Corey Murtagh wrote:
> >
> >> So step down off that high horse for a moment, put your Anti-MS
> >> prejudices on hold and tell us... how exactly do /YOU/ think it
> >> should have worked considering the architecture constraints? 
> >> How would /YOU/ have solved the problem, huh?
> >
> > I can't talk for Corey, but I'd have used 32-bit pointers by
> > default.
> 
> On a 16-bit architecture which doesn't support them?  Nice trick,
> if you can achieve it.

But it does support them.  However, pointers are not integers, as
has been pointed out before.  What the architecture does not
easily support is objects of 64K byte size and larger, and this is
not even required for standard C.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Wed, 12 Nov 2003 11:07:38 -0600, Programmer Dude
<Chris@Sonnack.com> wrote:

>James Rogers wrote:
>
>> I agree that writing something is often less productive than reusing
>> existing libraries.
>
>Sort of an aside...
>
>I've been reading Richard Gabriel's PATTERNS OF SOFTWARE (patterns
>not, AFAICT, in the way of the GOF book), and he wrote something
>interesting about libraries. Heavily edited:
>
>    First, you need to have a central repository of code. It
>    doesn�t help if developers have to go around to other
>    developers to locate code you might be able to use.
>
>    Second, there has to be a means of locating the right piece
>    of code, which usually requires a good classification scheme.
>    [...] But few software organizations can afford a software
>    cataloger, let alone a librarian to help find the software
>    for its developers.
>
>    Third, there must be good documentation of what each piece
>    of code in the repository does. [...] In many cases such
>    documentation is just the code itself, but this information
>    could be better provided by ordinary documentation;...
>
>    [Thus, for] a lot of pieces of code it is just plain simpler
>    to write it yourself than to go through the process of finding
>    and understanding reusable code.
>
Been there, done that. The man is exactly right. I set up a code reuse
program years ago. It was actually looking good, could probably have
increased efficiency of generating code, and certainly could have
increased the efficiency of maintaining code by re-using code which
was well-tested and well-documented. Unfortunately, it required
resources, and management didn't see an instant return ...



>Interesting paper (so far).  Available free:
>    http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Muzzlebreak wrote:

>>> Yes, but when C++ first appeared, Microsoft's had the biggest
>>> libraries,
>> 
>> C++ first appeared (under that name) in 1983. I don't recall Microsoft
>> producing a C++ compiler until around 1992 or 1993. They certainly
>> weren't the first to produce an MS-DOS implementation of C++, let
>> alone a Unix version.
>> 
> 
> Talking about Mainstream, but let's just break out the microscope on it. I
> remember Microsoft being around when I first noticed, so I will include
> them.

Fine by me, but what you actually said was incorrect.

If you don't want to be corrected, don't post incorrect statements.


> Peniswrinkle.

And that's your idea of an intelligent argument, is it? FCOL.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

On Wed, 12 Nov 2003 18:11:46 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
wrote:

>Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:
>
>>DOS's memory management was constrained by the architecture.  It's not 
>>like there was the option to set the PC into a flat memory model and use 
>>32-bit pointers at that point.
>
>There was certainly an option to use 32-bit pointers.  It was called
>"large model".  You couldn't actually use all of the 32 bits, only 28,
>but apart from that, application programmers could essentially ignore
>segmentation.

Having been one of those programmers, I'll testify that we didn't
ignore segmentation. The compiler and linker took care of many of the
details, but you couldn't ignore it. I'll also testify that it was a
long way from using a flat model. Things got better for DOS
programmers when CPUs were available which supported flat
("protected") mode, although the various DOS extenders had their own
quirks to worry about, and switching between real and protected mode
was painful, but necessary.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

[Followups set to comp.programming]

Fergus Henderson wrote:

> Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:
> 
>>DOS's memory management was constrained by the architecture.  It's not
>>like there was the option to set the PC into a flat memory model and use
>>32-bit pointers at that point.
> 
> There was certainly an option to use 32-bit pointers.  It was called
> "large model".  You couldn't actually use all of the 32 bits, only 28,

I thought it was 20 bits. Am I misremembering?

> but apart from that, application programmers could essentially ignore
> segmentation.

And we did. :-)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

"Torben �gidius Mogensen" <torbenm@diku.dk> wrote in message
news:w5islpvhtu.fsf@pc-032.diku.dk...
> "Myles" <a@b.c> writes:
> You seem to be labouring under the misconception that one single
> language should be used for all kinds of application.
> ...
> A modern language should be designed with a special purpose in mind
> and fairly qiuckly get good libraries for that.

and then someone whose application crosses several languages' domains (or
none of them) gets screwed?  That doesn't sound so desirable to me.

M.

"TLOlczyk" <olczyk2002@yahoo.com> wrote:
> Today I tackled a problem that I had done twelve years ago.
> I did it in four hours, and it took me about three months of
> weekends back then. Today I did it in OCaml, back then I
> did it in C++.
....
> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months 12 years ago if I had
> done it in OCaml.
>
> That goes for any language that is sophisticated enough.

Experience is a big part, but I think there is more to it.  For kicks about
a year ago I tried coding the KWIC program that David Parnas used for his
classic paper 'On the Criteria to be used in decomposing systems into
modules.'  I didn't time it but it took only an hour or so to do in Java and
he mentioned it taking a programmer a week or two.  Of course, there is no
guarantee that I was using the same spec, I just gleaned requirements from
the paper, but I strongly suspect that cumulative increases in machine and
language power have paid off far more than we recognize.

Michael Feathers
www.objectmentor.com

"Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
news:bosg1c$6oo$2@sparta.btinternet.com...
> [Followups set to comp.programming]
>
> James Rogers wrote:
>
> > Some languages are designed to maximize writing speed. C and Perl are
> > two examples. The common development model with C, and to a somewhat
> > lesser extent with C++, is to code, compile, then execute an extended
> > debug cycle, possibly including unit testing. Typically the debug
> > cycle is much longer than the initial coding and compile times.
>
> I accept that that may be your experience of C. It is not mine. I find
that
> the most time-consuming part of C programming is the thinking. "What is
the
> best way to solve this problem?" Coding and compiling don't take a
terribly
> long time, as you rightly point out. The debug cycle is generally short,
> too.
>
> The trick to C programming is to *know* the language.
>

The question is: does the fact that you can "code fast" makes C a good
langauge? What about the ability to expand the code and maintain it. Isn't
that a relevant factor? If you write fast, but it will take you month to
change some implementation detail (due to langauge design or bad coding
practices), were you really more productive?

--
____________________________
Lidor Wyssocky

http://www.QualityProgramming.org
Quality Oriented Programming

http://www.SharpDevelopment.com
Quality Objects Solutions



> Well, okay, the two tricks are to know the language and crank up the
warning
> level.
>
> Er, the three tricks...
>
> --
> Richard Heathfield : binary@eton.powernet.co.uk
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton

"Michael Feathers" <mfeathers@objectmentorNOSPAM.com> once said:
>Experience is a big part, but I think there is more to it.  For kicks about
>a year ago I tried coding the KWIC program that David Parnas used for his
>classic paper 'On the Criteria to be used in decomposing systems into
>modules.'  I didn't time it but it took only an hour or so to do in Java and
>he mentioned it taking a programmer a week or two.  Of course, there is no
>guarantee that I was using the same spec, I just gleaned requirements from
>the paper, but I strongly suspect that cumulative increases in machine and
>language power have paid off far more than we recognize.

Indeed, see "Yannis's Law: Programmer Productivity Doubles Every 6 Years"
   http://www.cc.gatech.edu/~yannis/law.html
for a similar perspective.

-- 
 Brian M. McNamara   lorgon@acm.org  :  I am a parsing fool!
   ** Reduce - Reuse - Recycle **    :  (Where's my medication? ;) )

olczyk2002@yahoo.com (TLOlczyk) wrote (abridged):
> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months [of weekends] 12 years
> ago if I had done it in OCaml.

Have you considered rewriting it now, in C++?

I imagine you made a few false starts in OCaml, even with your 12 years 
experience, so other things being equal I'd expect the C++ to take you 
less than the 4 hours. Perhaps much less - if you are really fluent in 
C++, you might be able to transcribe it as quickly as you can type. It 
might be interesting to compare the run-time performance of the finished 
projects, too. And the number of lines of code.

I appreciate you may not want to actually do this. To be honest, I suspect 
it would take /more/ than 4 hours, rather than less, at least if the 
project is reasonably complex, and that's a lot of leisure time to spend 
on a Usenet posting.

-- Dave Harris, Nottingham, UK

In article <bouat2$b5m$1@news-int2.gatech.edu>,
 gt5163b@prism.gatech.edu (Brian McNamara!) wrote:

> "Michael Feathers" <mfeathers@objectmentorNOSPAM.com> once said:
> >Experience is a big part, but I think there is more to it.  For kicks about
> >a year ago I tried coding the KWIC program that David Parnas used for his
> >classic paper 'On the Criteria to be used in decomposing systems into
> >modules.'  I didn't time it but it took only an hour or so to do in Java and
> >he mentioned it taking a programmer a week or two.  Of course, there is no
> >guarantee that I was using the same spec, I just gleaned requirements from
> >the paper, but I strongly suspect that cumulative increases in machine and
> >language power have paid off far more than we recognize.
> 
> Indeed, see "Yannis's Law: Programmer Productivity Doubles Every 6 Years"
>    http://www.cc.gatech.edu/~yannis/law.html
> for a similar perspective.

Eek.

cat textfile | perl -ne '
chomp;
@w = split " ";
for (1..scalar @w){
   print join(" ",@w),"\n";
   push @w,shift @w
}' | sort


That's a couple of *minutes* work, and will run in constant memory on 
any machine big enough to run Un*x and the Perl interpreter itself.

Or have I misunderstood the spec?

-- Bruce

"Myles" <a@b.c> wrote:
> "Torben �gidius Mogensen" <torbenm@diku.dk> wrote in message
> news:w5islpvhtu.fsf@pc-032.diku.dk...
> > "Myles" <a@b.c> writes:
> > You seem to be labouring under the misconception that one single
> > language should be used for all kinds of application.
> > ...
> > A modern language should be designed with a special purpose in mind
> > and fairly qiuckly get good libraries for that.

> and then someone whose application crosses several languages' domains (or
> none of them) gets screwed?  That doesn't sound so desirable to me.

Then use several languages to do it.

Dan.

On Wed, 12 Nov 2003 11:25:00 -0600, Programmer Dude wrote:

> Joachim Durchholz wrote:
> 
>> Given that the dead simple languages (Lisp, Smalltalk)...
> 
> Dead simple?  As I just wrote, Lisp has about 1000 keywords defined
> as part of the language (due the library being considered as part
> of--and indistinquishable from--core Lisp), and the spec is about
> 1300 pages.
> 
> *Not* dead simple overall (although the Lisp core is).

I parsed that as "dead, simple", not "dead-simple". I don't know that
either is really accurate. :-}

Josh

"Bruce Hoult" <bruce@hoult.org> wrote in message
news:bruce-D47632.12583213112003@copper.ipg.tsnz.net...
> In article <bouat2$b5m$1@news-int2.gatech.edu>,
>  gt5163b@prism.gatech.edu (Brian McNamara!) wrote:
>
> > "Michael Feathers" <mfeathers@objectmentorNOSPAM.com> once said:
> > >Experience is a big part, but I think there is more to it.  For kicks
about
> > >a year ago I tried coding the KWIC program that David Parnas used for
his
> > >classic paper 'On the Criteria to be used in decomposing systems into
> > >modules.'  I didn't time it but it took only an hour or so to do in
Java and
> > >he mentioned it taking a programmer a week or two.  Of course, there is
no
> > >guarantee that I was using the same spec, I just gleaned requirements
from
> > >the paper, but I strongly suspect that cumulative increases in machine
and
> > >language power have paid off far more than we recognize.
> >
> > Indeed, see "Yannis's Law: Programmer Productivity Doubles Every 6
Years"
> >    http://www.cc.gatech.edu/~yannis/law.html
> > for a similar perspective.
>
> Eek.
>
> cat textfile | perl -ne '
> chomp;
> @w = split " ";
> for (1..scalar @w){
>    print join(" ",@w),"\n";
>    push @w,shift @w
> }' | sort

Yeah, I think I need to use PERL often enough for it to stick.

Michael Feathers
www.objectmentor.com

James Rogers wrote:
> Statistics also show that the Ada program is
> likely to have one half to one third the number of bugs as the
 > released C or C++ program.

Any reference?

TIA,
Tak

Joachim Durchholz wrote:
> [Microsoft] have been extending the language with tons of modifiers
 > (_near, _far in olden DOS times; _stdcall, long long, extensions for
 > IDL etc. etc. etc.).

_near, _far and long long were reasonable extensions given the
awkward architecture of the Intel chips.  All the C/C++ compilers
for the Intel hardware platform have them.  _stdcall is equivalent
to a #pragma and is essential to inter-operability with
compilers and languages.  Extensions for IDL can also be seen as
an inter-operability issue; too bad it is for Microsoft's own IDL.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

FM wrote:
> [C++] is a highly extensible language.  The problem is that
> the extensibility was achieved by adding on a great deal
> of complexity, at every level of the language design,
> rather than orthogonality and elegance.

I am not sure what you mean by "extensible".  When I think
"extensible", I usually think Lisp, with its simple syntax
and powerful! macro capability.  I also don't understand
what do you mean by extendability in the expense of complexity.

I tend to think of C/C++ as highly "tunable" languages, second
perhaps only to assemblers.  The tunability allows the
programmers to specify many aspects of the program in great
details.  It is what gives the complexity and no doubt a huge
disadvantage in a lot of situations.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Alan Balmer <albalmer@att.net> writes:

>Fergus Henderson <fjh@cs.mu.oz.au> wrote:
>
>>Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:
>>
>>>DOS's memory management was constrained by the architecture.  It's not 
>>>like there was the option to set the PC into a flat memory model and use 
>>>32-bit pointers at that point.
>>
>>There was certainly an option to use 32-bit pointers.  It was called
>>"large model".  You couldn't actually use all of the 32 bits, only 28,
>>but apart from that, application programmers could essentially ignore
>>segmentation.
>
>Having been one of those programmers, I'll testify that we didn't
>ignore segmentation. The compiler and linker took care of many of the
>details, but you couldn't ignore it.

So, when did you have to worry about it?

AFAIK the only reasons for worrying about segmentation were
(1) being forced to learn about something that you didn't need 
    simply because these keywords popped up in compiler error messages,
    C textbooks and manuals, header files, etc.
(2) micro-optimization
(3) interfacing with someone else's micro-optimized code

Admittedly micro-optimization was more important back then than it is now,
but in my experience reason (1) was the most important one.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Joachim Durchholz wrote:
> My observation is that C++ as a language is so complicated
 > that it's horribly difficult to write reliable refactoring
 > tools. The net effect is that authors of C++ tools have
 > less time to spend on making their tools nicer
 > (regardless of the definition of "nice").

Pardon my ignorance.  What are "refactoring tools"?

> Given that the dead simple languages (Lisp, Smalltalk) were
 > the first to  have nice tools, I suspect we have a spectrum
 > here: simple languages  with massive tool support to complex
 > languages with little tool support.

Uh, what kind of tools you are talking about?

Btw, Lisp and Smalltalk are interpretor languages while C++
is a compiler language.

> If the language complexity isn't designed to replace the 
 > tools, the complex language will lose in the long term:
 > even those who love it will be more productive in the
 > simpler language.

Well, most the complexity of C++ is to allow the programmer
to specify different aspects of his program to great details.
They are certainly not intended to be replaced by

> (That's a large part of what I mean when I say that "C++
 > isn't powerful enough for its complexity".)

"Powerful" can have different meanings.  C++ can be said to
be powerful in that it gives the programmer great power in
specifying things.  It is easier to optimize a Fortran loop
than a C/C++ one, because one does not have to worry about
pointer alias in Fortran.  However, with pointer it is
possible to write more efficient code than Fortran in a
lot of situations.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

On Thu, 13 Nov 2003 04:48:17 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
wrote:

>AFAIK the only reasons for worrying about segmentation were
>(1) being forced to learn about something that you didn't need 
>    simply because these keywords popped up in compiler error messages,
>    C textbooks and manuals, header files, etc.
>(2) micro-optimization
>(3) interfacing with someone else's micro-optimized code

4) Working with monolithic data structures that were themselves larger
than what could be held in one segment (e.g., large blocks of text)

I remember it well...wanting to have <array of XYZ> but having to settle
for <array of pointers to XYZ> and allocating all of the XYZ's on the
heap to get around the per-segment limit. I think once I even had to
have an <array of pointers to array of pointers to XYZ>.

-Steve

Joachim Durchholz wrote:
JD> They have been extending the language with tons of
JD> modifiers (_near, _far in olden DOS times; _stdcall,
JD> long long, extensions for IDL etc. etc. etc.).

George Russell wrote:
GR> I am very far from being a Microsoft fan, but surely _near
GR> and _far were an inevitable consequence of Intel's 16-bit
GR> instruction set?

JD> Far from "inevitable" - near pointers never made much of a
JD> sense, so 32-bit pointers could have been the standard.
JD> The remaining uses for 16-bit pointers were for low-level
JD> code, and in these days, "low-level" meant assembly, not C...

Uh, which 32-bit DOS are you talking about?

Tak

George Russell wrote:
GR> I am very far from being a Microsoft fan, but surely _near and
GR> _far were an inevitable consequence of Intel's 16-bit instruction
GR> set?

CBFalconer wrote:
CB> Far from it.

It is inevitable if a goal is to allow the programmer to
choose what's best for him.

CB> Just as an example, it would be possible to have the code
CB> generators always generate far calls (and returns), except in
CB> the case where the function is marked static.  I will concede
CB> in advance that other penalties would result, but the source
CB> would be portable.

The source would be portable if one localizes platform dependence.
Eg.,

   #ifndef _MSDOS_
   #define _far
   #endif

CB> However, such usage would require innovation and thought from
CB> Microsoft, rather than aping others and encouraging lock-ins
CB> to their own system.

Btw, one doesn't really need _far or _near if one does not have
to worry about external compatibility (code from other compilers,
etc) and is not interested in minimizing memory requirement.
Back then, most compilers has 4 memory models, depending on
whether ones has 16 or 32 bit pointers in accessing code and
data.   The feature that you mentioned of using 32 bit pointer
for code with the _far keyword has always been a compile time
option.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

"FM" <dartdanfm@yahoo.com> writes:

>"Myles" <a@b.c> wrote:
>> "Torben �gidius Mogensen" <torbenm@diku.dk> wrote in message
>> news:w5islpvhtu.fsf@pc-032.diku.dk...
>> > "Myles" <a@b.c> writes:
>> > You seem to be labouring under the misconception that one single
>> > language should be used for all kinds of application.
>> > ...
>> > A modern language should be designed with a special purpose in mind
>> > and fairly qiuckly get good libraries for that.
>
>> and then someone whose application crosses several languages' domains (or
>> none of them) gets screwed?  That doesn't sound so desirable to me.
>
>Then use several languages to do it.

If there was no overhead to using several languages, that would be a great
strategy.  Unfortunately there usually _are_ significant costs in using
multiple languages:

	- Maintainers will need to learn multiple languages, and multiple
	  tool sets, which significantly increases the learning curve.

	- Application portability is dependent on the portability of the
	  languages used.  Using more languages reduces portability.

	- Using several languages often requires communicating via a
	  foreign function interface (FFI), and FFIs are often less
	  standardized than the languages themselves.  So this reduces
	  portability even further.

	- Even when all the required languages have implementations
	  for your required target platform, and when you are using
	  a standardized FFI, there is no guarantee that the different
	  language implementations will be willing to cooperate.
	  For example, it is often problematic to incorporate two
	  different garbage collectors in the same process.

	- Often using an FFI is far less convenient than writing an ordinary
	  procedure call.  FFIs also often fail to preserve nice qualities
	  such as static type safety or automatic propagation of exceptions,
	  even when the languages on both sides of the interface have it.

	- There is often a significant impedance mismatch between different
	  languages which makes interfacing between them difficult.
	  For example, in one language, it may be conventional to use
	  arbitrary precision integers, and to treat represent strings
	  as lists of characters, whereas in another it may be conventional
	  to use fixed precision integers and to treat strings as pointers
	  to null-terminated arrays of characters.  In some cases, the
	  language FFI can automatically compensate for some of these
	  mismatches, by automatically marshalling the data in the
	  appropriate form, but in many cases it can't, and even when it
	  can there is usually a performance penalty, and there may also
	  be issues with regard to dealing with exceptional cases
	  (e.g. integers that don't fit in 32 bits or strings that
	  contain null characters).

There is and always will be significant drawbacks to using multiple
languages.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To <takto@alum.mit.edu.-> writes:

>Joachim Durchholz wrote:
>> [Microsoft] have been extending the language with tons of modifiers
> > (_near, _far in olden DOS times; _stdcall, long long, extensions for
> > IDL etc. etc. etc.).
>
>_near, _far and long long were reasonable extensions given the
>awkward architecture of the Intel chips.

__near and __far would probably have been reasonable extensions,
but _near and _far violated the C standard.

>All the C/C++ compilers for the Intel hardware platform have them.

That's because they had to, to be compatible with the competition.

>_stdcall is equivalent to a #pragma

Not really -- _stdcall affects the type system.

Of course a #pragma could in theory affect the type system too, but only
in the sense that a #pragma could do anything, so saying that _stdcall
is equivalent to a #pragma in that sense is meaningless.

>and is essential to inter-operability with compilers and languages.

Some means of specifying the calling convention is indeed pretty much
essential.  However, they didn't have to use a name which is in the
user's namespace.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To <takto@alum.mit.edu.-> writes:

> Btw, Lisp and Smalltalk are interpretor languages while C++
> is a compiler language.

I am afraid this is wrong.

First, there is really no such thing as an interpreted or a compiled
*language*.  That would be a property of an *implementation* rather
than of a language.  C++ can be implemented as an interpreter and Lisp
and Smalltalk can be implemented as compilers.

It is important to get this right.  I have seen people choose the
wrong language for a task, because their reasoning went sort of like
this : Lisp ... Interpreted language ... slow ... not suitable for my
task.  But this chain of reasoning contains the fundamental flaw
indicated above. 

Second, at least as far as Lisp is concerned, most implementations
are compiled.  Indeed they often have excellent compilers, capable of
generating code with execution speed comparable to code generated by a
good C compiler.  And this has been the case for 15 years or so.  It
is sad that totally false statements like this are still presented as
facts. 

Finally, perhaps you are confusing "interpreted" with "interactive"?
Obviously, if one thinks that a language with an interaction loop
(like the Lisp Read-Eval-Print Loop) has to be interpreted, then one
is often going to make the wrong decision concerning the choice of
programming language.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

"Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message news:boscca$s39$7@sparta.btinternet.com...
> >>
> C++ first appeared (under that name) in 1983. I don't recall Microsoft
> producing a C++ compiler until around 1992 or 1993.

Yes. Originally it was called C with Classes.


> They certainly weren't the first to produce an MS-DOS
> implementation of C++, let alone a Unix version.

Right. The first one with an MS-DOS implementation was, uh, me
and a friend of mine, working out of his garage. I think that was
in 1986 or so.


Marshall

Bruce Hoult <bruce@hoult.org> writes:

> [The kwic challenge]'s a couple of *minutes* work

I don't by any means count myself as a very good programmer, but that
was my thought exactly.  So I measured; two minutes to ponder the
spec, six minutes to type it up in Haskell and test it with GHCi.  A
bit more verbose than your perl code (13 lines, excl. blanks and type
declarations). 

(What did a programmer make in '72?  Since I'm apparently eight
hundred times as efficient, perhaps it's time to ask for a rise? :-) 

There's also Fred Brooks'� famous prediction that while going from
low-level (i.e. assembly) language to higher-level languages gained an
order of magnitude in programmer efficiency, no further
order-of-magnitude improvements were likely due to language
improvements.  (To be fair, he's talking about larger systems, not
micro-benchmarks like KWIC.)

-kzm

� IIRC, he says this in "The mythical man-month".
-- 
If I haven't seen further, it is by standing in the footprints of giants

In article <956dnXVoR8PtiC6iRVn-jA@comcast.com>,
 Tak To <takto@alum.mit.edu.-> wrote:

> Joachim Durchholz wrote:
> > My observation is that C++ as a language is so complicated
>  > that it's horribly difficult to write reliable refactoring
>  > tools. The net effect is that authors of C++ tools have
>  > less time to spend on making their tools nicer
>  > (regardless of the definition of "nice").
> 
> Pardon my ignorance.  What are "refactoring tools"?

Editors that understand the code enough to allow you to incrementally 
and safely change the design of existing code.  A simple example is to 
globally rename all occurences of a variable without accidentally 
getting a different variable that happens to have the same name.
 

> > Given that the dead simple languages (Lisp, Smalltalk) were
>  > the first to  have nice tools, I suspect we have a spectrum
>  > here: simple languages  with massive tool support to complex
>  > languages with little tool support.
> 
> Uh, what kind of tools you are talking about?

Interactive browsers, debuggers, compilers...
 

> Btw, Lisp and Smalltalk are interpretor languages while C++
> is a compiler language.

That is NOT the case.  Lisp has been primarily a compiled language (and 
a very fast one) for the last 25+ years.  You should look at Guy 
Steele's papers from 1977 or so, showing how Scheme maps naturally and 
simply to very efficient machine code.

-- Bruce

Tak To <takto@alum.mit.edu.-> writes:

> 
> Btw, Lisp and Smalltalk are interpretor languages while C++
> is a compiler language.
This remark is nonsense. There exist Lisp which just compile and there
exist C++ interpreters, and every Common Lisp has to provide a
compiler. 

Regards
Friedrich

Fergus Henderson wrote (snipped):

> You remember wrong.  The names "_near" and "_far" are in the user's namespace,
> not the implementation's.  For example, the following is a strictly conforming
> C program:
> 
> 	int _near;
> 	int main() { return _near; }
> 
> But it didn't work with most versions of Microsoft's C compiler, IIRC.

 From section 7.1.3 of the proposed C9X standard:

    http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.pdf

(tell Acroread to find page 163 of 550)

 > All identifiers that begin with an underscore are always
 > reserved for use as identifiers with file scope in both the
 > ordinary and tag name spaces.

So far as I can remember, it was the same in ANSI C.

CBFalconer wrote (snipped):

> Far from it.  Just as an example, it would be possible to have the
> code generators always generate far calls (and returns), except in
> the case where the function is marked static.  I will concede in
> advance that other penalties would result, but the source would be
> portable.  However, such usage would require innovation and
> thought from Microsoft, rather than aping others and encouraging
> lock-ins to their own systems.

Er, do you remember those advertisements you used to get in PCW and similar
magazines about how Microsoft C took 9.7 seconds to execute some benchmark,
while Borland (Turbo) C only took 6.9, or vice-versa? I know this was all pretty
meaningless, but do you really think Microsoft should have scrapped all
such advertisements and said "Well, alright, code compiled by our compiler
DOES take twice as long to run as if compiled by Turbo C, but hell, you can
run it on Unix without first putting #define _near #define _far at the start
of your file!"  Make a great advertisement, that would.

George Russell <ger@tzi.de> writes:

> Torben �gidius Mogensen wrote (snipped):
> 
> > This depends on what problem I was trying to solve.  If the purpose
> > was to implement the language faithfully, I would have used 32-bit
> > (segment+offset) pointers by default (taking the performance hit this
> > implies) but allow several pointer values to share the same segment
> > where static analysis shows that this is possible.
> 
> I love it when people claim they can solve all the world's problems by
> static analysis.  When you have a function which takes 3 pointer arguments,
> whatttya gonna do, compile lots of different versions for all the different
> combinations of same-segment, different segment.  (This will mean your code
> explodes, meaning function calls which could have been near might end up having
> to be made far.)  Or are you going to do whole-program analysis to determine
> all the different ways each function might be called?  This will be fun,
> prevent you producing libraries, and mean compilation takes much longer.
> (It already took long enough in 1991, I remember.)

I would probably have taken the approach that only one version of each
function would be compiled, and only share segments if they are known
to be shared no matter what the call looks like, effectively
restricting sharing of segments to local variables.  While this may
seem conservative, a lot of pointer variables are local, e.g., used in
a loop to walk through an array.

	Torben

ketil+news@ii.uib.no wrote:

> Bruce Hoult <bruce@hoult.org> writes:
> 
>> [The kwic challenge]'s a couple of *minutes* work
> 
> I don't by any means count myself as a very good programmer, but that
> was my thought exactly.  So I measured; two minutes to ponder the
> spec, six minutes to type it up in Haskell and test it with GHCi.  A
> bit more verbose than your perl code (13 lines, excl. blanks and type
> declarations).

Gotcha beat..

import List(sort,words,unwords,concatMap)

kwic :: [String] -> [String]
kwic xs = sort $ map unwords $ concatMap (rotate . words) xs where
 rotate xs = rotate' (length xs) xs
 rotate' 0 _          = []
 rotate' n xs@(x:xs') = xs : rotate' (n-1) (xs' ++ [x])

nah nah nahnah nah :-)

Regards
--
Adrian Hey

Bruce Hoult wrote:
<snip>
> This year C++ did well, but in previous years it has been dominated by 
> staticly-typed languages such as O'Caml and ocassionally Haskell or C.  
> Dylan is the only dynamically-typed language to do well with the Judges' 
> Prize this year and 2nd Prize in 2001 [1]
> 
> C++ is getting to be a pretty formidable language in the hands of 
> experts.  The problem is that almost no one can become truly expert in 
> it, and even then only at great cost.

C++ is like one of those fat pen-knives with just about every 
conceivable gadget and gizmo attached.  Sure, the knife works.  But it 
also has a pair of scissors, a tooth-pick, a little magnifying glass, a 
cork-screw, a little saw, a ruler, a screwdriver, and half a dozen 
gadgets that are strangely shaped and have no apparent purpose.

Probably, all you wanted was a decent knife.

But then you realise, all those worthless gadgets do have a purpose to 
someone somewhere.  And you can spend plenty of time trying to open a 
tin with the knife and cutting yourself in the process, when there was a 
tin-opener there all along if only you'd taken the time to read the manual.

George Russell wrote:
>  From section 7.1.3 of the proposed C9X standard:

Largely irrelevant - this was written long after Microsoft published 
their compilers.
And I'm pretty sure that Microsoft had (and is having) its place in the 
language committee.

Regards,
Jo

Fergus Henderson wrote:
> So, when did you have to worry about it?
> 
> AFAIK the only reasons for worrying about segmentation were
> (1) being forced to learn about something that you didn't need 
>     simply because these keywords popped up in compiler error messages,
>     C textbooks and manuals, header files, etc.
> (2) micro-optimization
> (3) interfacing with someone else's micro-optimized code
> 
> Admittedly micro-optimization was more important back then than it is now,
> but in my experience reason (1) was the most important one.

You couldn't have data structures that were larger than 64K.
Usually. There used to be a "huge" memory model. Silly: the compiler 
should have been able to determine which data structures are smaller 
resp. larger than 64K and use the appropriate memory model. Library 
functions would have to be written using the huge model and somewhat 
less efficient, or there would have been versions of the library 
functions written for large and huge memory.
Instead, they included three or four mutually incompatible versions of 
libc, further conflated with "with debug" and "without debug" (and later 
versions multiplied this with another two options, "threadsafe" and "not 
threadsafe"). A mess.

An addition: (3) was relevant because many OS interfaces were 
microoptimized.
We all know who wrote those operating systems...

Regards,
Jo

Adrian Hey <ahey@NoSpicedHam.iee.org> writes:

> ketil+news@ii.uib.no wrote:

> Gotcha beat..

Well, you omitted the declaration of a Module and main function.

> import List(sort,words,unwords,concatMap)

(I think words, unwords and concatMap are imported by default?)

> kwic :: [String] -> [String]
> kwic xs = sort $ map unwords $ concatMap (rotate . words) xs where
>  rotate xs = rotate' (length xs) xs
>  rotate' 0 _          = []
>  rotate' n xs@(x:xs') = xs : rotate' (n-1) (xs' ++ [x])

> nah nah nahnah nah :-)

Ah, four lines, you say?

> kwicer_than_thou = unlines . sort . concatMap shift . lines
> shift1 ws = if null ws then [] else tail ws++[head ws]
> shift ln = let ws = words ln in map unwords $ take (length ws) $ iterate shift1 ws

nah nah youself!  (Although one of my lines admittedly exceed 80
chars, but I could have chosen shorter names)

Besides, refactoring took me an extra minute, and given the current
cost of disk space and bandwidths, I guess the programmer time is more
expensive. 

Oh well.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

Joachim Durchholz wrote (snipped):

> Largely irrelevant - this was written long after Microsoft published 
> their compilers.
> And I'm pretty sure that Microsoft had (and is having) its place in the 
> language committee.

But surely C compilers have used names beginning with underscores for
extensions since long before even ANSI C?  I don't think you can really
blame Microsoft for following the tradition.  Or, for that matter, for
being on the ANSI committee.

Really, they produce so much rotten software that this seems like
complaining that Dr Crippen didn't comb his hair.

Richard Heathfield wrote:
>>There was certainly an option to use 32-bit pointers.  It was called
>>"large model".  You couldn't actually use all of the 32 bits, only 28,
> 
> I thought it was 20 bits. Am I misremembering?

That depended on processor model.
I think it was 20 bits for the '286 and '386SX, and more for '386DX, 
'486 and up. This is just counting hardware address pins though, the 
software model was: a maximum of 16 bits per data structure for all 
models up to and including the '286, a flat 32-bit memory space from 
'386 (both SX and DX) and upwards.
One could work around the 16-bit limit, but that's something that the 
compiler should have done, not something that programmers should have 
worried about.

The 28 bits might be an interference with 68000 issues: that processor 
ignored the top 4 bits of addresses (which early versions of MacOS 
promptly abused to store flags together with addresses, and some 
software houses copied that technique).

(I don't read comp.programming, so I won't see responses.)

Regards,
Jo

Tak To wrote:
> JD> Far from "inevitable" - near pointers never made much of a
> JD> sense, so 32-bit pointers could have been the standard.
> JD> The remaining uses for 16-bit pointers were for low-level
> JD> code, and in these days, "low-level" meant assembly, not C...
> 
> Uh, which 32-bit DOS are you talking about?

I'm not talking about DOS at all, I'm talking about code generated by 
compilers.
It wasn't done because the '86 had a set of technical quirks that made 
it difficult to implement even modestly efficient pointer arithmetic. To 
be fair, I wouldn't have expected support for large data structures in 
the early versions of the compilers, but I'd have expected it after a 
year or two. Microsoft took the easy way out (as always).

Regards,
Jo

Tak To wrote:
> CBFalconer wrote:
> CB> Far from it.
> 
> It is inevitable if a goal is to allow the programmer to
> choose what's best for him.

You are giving Microsoft far too much credit.
Microsoft has always pursued what's best for Microsoft, not what's best 
for the programmers. (Other companies have done likewise, but Microsoft 
combines lock-in strategies while mobilizing heaps of impunity to give 
lip service to openness and programmer productivity.)

> The source would be portable if one localizes platform dependence.
> Eg.,
> 
>   #ifndef _MSDOS_
>   #define _far
>   #endif

Go tell this the programmers of Unix software... portability doesn't go 
just from DOS to elsewhere, it's also from elsewhere to DOS.

MS never added a compatibility mode that would have allowed us to 
compile, say, grep and company. When Borland wrote their own 
(restricted) version of grep, usability of DOS leapfrogged. (Speaking of 
MS making programmers happy - far from that.)

Regards,
Jo

George Russell <ger@tzi.de> writes:

> From section 7.1.3 of the proposed C9X standard:
>
> > All identifiers that begin with an underscore are always
> > reserved for use as identifiers with file scope in both the
> > ordinary and tag name spaces.
>
>So far as I can remember, it was the same in ANSI C.

Sorry, I got the example wrong.
Let's see if I can get it right this time:

	int main() {
		int _near = 0;
		return _near;
	}

Note that _near is used here as a variable with local scope, not file
scope.  So this program does not violate C99 7.1.3 (and likewise for the
corresponding paragraph in C89).  But implementations that treat _near
as a keyword will reject this program.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To wrote:

> Joachim Durchholz wrote:
> 
>> [Microsoft] have been extending the language with tons of modifiers
>> 
> 
>> (_near, _far in olden DOS times; _stdcall, long long, extensions
>> for IDL etc. etc. etc.).
> 
> _near, _far and long long were reasonable extensions given the 
> awkward architecture of the Intel chips.

Agreed.
Just as every other single extension is "reasonable".
I'm just wondering why Microsoft extended the language in incompatible
ways. Everything could have been packaged in library functions.

> All the C/C++ compilers for the Intel hardware platform have them.

Only because Microsoft had set the example, and they were more-or-less
forced to follow the lead.
Besides, MS compilers are still least compatible with the standard. The
guy with C/C++ parser exposure who I talked to told me that MS compilers
made more work due to extra features than all other compilers together,
including compilers with a long and well-known history of being braindead.
They would have loved to ignore MS' language extensions, but every
Windows program starts with #include <windows.h>, which means
approximately 5 megabytes of Microsoft code that have to be parsed...

> _stdcall is equivalent to a #pragma

Then why isn't it a #pragma?

> and is essential to inter-operability with compilers and languages.
> Extensions for IDL can also be seen as an inter-operability issue;
> too bad it is for Microsoft's own IDL.

Right, it's interoperability stuff.
It's *all* interoperability stuff.

It's not that these extensions don't serve useful purposes. It's the way 
that Microsoft integrated them into the language: with little care for 
portability.
It's one of Microsoft's worst sins, committed due to carelessness if not 
as a conscious lock-in strategy. (Again, speaking of "what's best for 
the programmer"...)

Regards,
Jo

George Russell <ger@tzi.de> writes:

>Er, do you remember those advertisements you used to get in PCW and similar
>magazines about how Microsoft C took 9.7 seconds to execute some benchmark,
>while Borland (Turbo) C only took 6.9, or vice-versa?  I know this was all
>pretty meaningless, but do you really think Microsoft should have scrapped all
>such advertisements and said "Well, alright, code compiled by our compiler
>DOES take twice as long to run as if compiled by Turbo C, but hell, you can
>run it on Unix without first putting #define _near #define _far at the start
>of your file!"  Make a great advertisement, that would.

Those sort of benchmarks didn't include _near or _far keywords, AFAIK.
They would just have been compiled in small (or tiny) model.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Programmer Dude wrote:

> Joachim Durchholz wrote:
> 
>>Given that the dead simple languages (Lisp, Smalltalk)...
> 
> Dead simple?  As I just wrote, Lisp has about 1000 keywords defined
> as part of the language (due the library being considered as part
> of--and indistinquishable from--core Lisp), and the spec is about
> 1300 pages.

I was talking about Lisp, not Common Lisp or Scheme.
I'm just an old fart :-)

> *Not* dead simple overall (although the Lisp core is).

OK, then I probably meant what you call the Lisp core.

> (Don't get me wrong: I love Lisp!!)

I hate it.
Or, rather, I might fall in love with Common Lisp if it were not such a 
monster of a multi-paradigm, multi-this, multi-that, keyword-riddled and 
mechanism-overladen system. In other words, it's too baroque for my taste.

Regards,
Jo

Tak To wrote:

> Joachim Durchholz wrote:
> 
>> My observation is that C++ as a language is so complicated
> 
>  > that it's horribly difficult to write reliable refactoring
>  > tools. The net effect is that authors of C++ tools have
>  > less time to spend on making their tools nicer
>  > (regardless of the definition of "nice").
> 
> Pardon my ignorance.  What are "refactoring tools"?

I was imprecise - I meant "code transformation tools". Refactoring is 
just a technical term for a group of transformations that are 
particularly common (or over-hyped if you will) in the OO community.

> Btw, Lisp and Smalltalk are interpretor languages while C++
> is a compiler language.

This doesn't affect the complexity of the language semantics. (Except 
that interpreted languages tend to be easier than compiled ones, though 
I'm unsure in which direction the causality flows or whether there's any 
direct connection at all.)

> It is easier to optimize a Fortran loop
> than a C/C++ one, because one does not have to worry about
> pointer alias in Fortran.  However, with pointer it is
> possible to write more efficient code than Fortran in a
> lot of situations.

Repeat that in a numerics newsgroup. But don't forget your asbestos suit ;-)

Regards,
Jo

George Russell wrote:
> Joachim Durchholz wrote (snipped):
> 
>> Largely irrelevant - this was written long after Microsoft
>> published their compilers. And I'm pretty sure that Microsoft had
>> (and is having) its place in the language committee.
> 
> But surely C compilers have used names beginning with underscores for
>  extensions since long before even ANSI C?

_near and _far are not names, they are modifiers. That's an entirely
different can of worms.

> I don't think you can really blame Microsoft for following the
> tradition.

I wouldn't if they had. Instead, they invented their own traditions (to
the point that people think that Microsoft's quirks are tradition).

> Or, for that matter, for being on the ANSI committee.

No, but it's clear that MS took care of its investments in the
committee. Probably not to the full extent (else C9X would be near to
useless), but they will have mustered all influence they could.

> Really, they produce so much rotten software that this seems like 
> complaining that Dr Crippen didn't comb his hair.

OK, to /that/ one I can agree :-))

Regards,
Jo

TLOlczyk wrote:

> It leaves me to believe that I would have taken four hours today
> if I had done it in C++, and three months 12 years ago if I had
> done it in OCaml.

Perhaps, for your problem it is a true statement.

I had some quite contradictionary experiences.

I know Ruby for years and I can program very fast in it.
Then, I learnt Haskell and after some days, I decided to
program a symbol manipulation program in Haskell, just
to test the language. It could simplify and differentiate
algebraic expressions containing polynomials and some
analytic functions as well. I quickly added some
abstract integration support and the whole code was ready
in some hours. Then I told to myself: it's nice, but
in Ruby, it would not have been a big deal also. So
I tried to write the same stuff in Ruby. I have even
used my Haskell code for template. It took about twice
as much time to write the code, I could implement only
a subset of the features and the code was much more
buggy and longer.

Some month later, I programmed a music generator combinator
library in Haskell which produced files in a simple self-defined
format. After that, I needed a converter which transformed my
file format to midi. I took me more than an
hour in Haskell and had a lot of trouble. As I was ready,
I decided to rewrite the same stuff in Ruby, because of
readability problems.  Not only was I ready in 20
minutes, it was even faster than the Haskell version.

So, my conclusion is that even for an experienced programmer,
there can be different tasks for which the choice of
the programming language really matters.

Tak To <takto@alum.mit.edu.-> wrote:
TT>_near, _far and long long were reasonable extensions given the
TT> awkward architecture of the Intel chips.

Fergus Henderson wrote:
FH> __near and __far would probably have been reasonable extensions,
FH> but _near and _far violated the C standard.

Yes, and that was why they were replaced by __near and __far soon
as the C committee reserved the leading double underscore symbols
for compiler usage only.  You can always use _far as a user symbol
if you edit out the #define in the standard include files.

      -----     -----

TT> _stdcall is equivalent to a #pragma

FH> Not really -- _stdcall affects the type system.

As in say, #pragma pack(1)?

FH> Of course a #pragma could in theory affect the type system too,
FH> but only in the sense that a #pragma could do anything, so saying
FH> that _stdcall is equivalent to a #pragma in that sense is
FH> meaningless.

You are quite right; I wasn't expressing my thoughts clearly.

What I meant to say was that _stdcall (__stdcall) was not born
out of necessity of accomodating the awkward Intel architecture
as were _near and _far; and by the time it was introduced,
#pragma has already been standardized so Microsoft could have
used a #pragma instead.

TT> and is essential to inter-operability with compilers and
TT> languages.

FH> Some means of specifying the calling convention is indeed
FH> pretty much essential.  However, they didn't have to use a
FH> name which is in the user's namespace.

__stdcall is not in user's namespace.  (And it is bad coding
style to define a symbol that looks like a predefined compiler
symbol.)

Btw there is something to be said about using a predefined
symbol vs relying solely on a #pragma.  The former allows one
to define anonymous types more easily.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

> > Pardon my ignorance.  What are "refactoring tools"?
> Editors that understand the code enough to allow you to incrementally
> and safely change the design of existing code.  A simple example is to
> globally rename all occurences of a variable without accidentally
> getting a different variable that happens to have the same name.

Did somebody call us?-)

See our project on "Refactoring Functional Programs":

    http://www.cs.kent.ac.uk/projects/refactor-fp/

for pointers, papers, etc., and especially our prototype of HaRe,
the Haskell Refactorer. A summary of recent activity is included
in section 5.3.2 of the new Haskell Communities report:

    http://www.haskell.org/communities/11-2003/html/report.html#sect5.3.2

> > > Given that the dead simple languages (Lisp, Smalltalk) were
> >  > the first to  have nice tools, I suspect we have a spectrum
> >  > here: simple languages  with massive tool support to complex
> >  > languages with little tool support.
> > Uh, what kind of tools you are talking about?
> Interactive browsers, debuggers, compilers...

Not having followed the thread, I'm prone to repeat what others
will have said, but anyway: the route to language simplicity is via
removing unnecessary complexity - complex languages are not
complex because of additional expressive power, they are complex
because of restrictions on the use of that power, leading to large
numbers of special cases and interactions. As van Wijngaarden
once put it: "Simplicity through generality" is the goal.

One might think that the more complex a language is, the more
its programmers are in need of tool support, but unfortunately,
the very same complexity makes it difficult to implement tools.
Lisp and Smalltalk are not quite as simple anymore, but they
have fairly well-designed simple and powerful roots - easy to
be productive in, easy to write tools for, which make it even
easier to be productive, ..

>>>If the language complexity isn't designed to replace the tools, the
>>>complex language will lose in the long term: even those who love it will
>>>be more productive in the simpler language.

The complex language should always lose - it is an interim stage
in language development: new features have been added, but are
still limited and ridden with restrictions and special cases. Once
the features are better understood, language designers will be
able to achieve simplicity again, by making the new features more
generally applicable, and better integrated with the rest of the language.

Tools are meta-programs - programs that operate on programs.
They give additional leverage in any language, but if the object
language is too complex to be understood, yet too limited to talk
about its own programs, meta-programmers and programmers
run into trouble: the language is difficult to be productive in,
difficult to write tools for, difficult to make any progress with..

Cheers,
Claus

Bruce Hoult <bruce@hoult.org> wrote in message news:<bruce-BE370C.21010913112003@copper.ipg.tsnz.net>...
> In article <956dnXVoR8PtiC6iRVn-jA@comcast.com>,
>  Tak To <takto@alum.mit.edu.-> wrote:
....
> > Btw, Lisp and Smalltalk are interpretor languages while C++
> > is a compiler language.
> 
> That is NOT the case.  Lisp has been primarily a compiled language (and 
> a very fast one) for the last 25+ years.  You should look at Guy 
> Steele's papers from 1977 or so, showing how Scheme maps naturally and 
> simply to very efficient machine code.

... and Smalltalk systems compile to bytecode very early
(whenever you edit a class declaration or a method). Then
they do JIT compilation to native code. 

The key aspect in terms of tool development is that the
Smalltalk class library and runtime environment is all
present in memory as Smalltalk data structures, giving
one much more power than the crude "reflection" supported
by Java.

Fergus Henderson wrote (snipped):

> Note that _near is used here as a variable with local scope, not file
> scope.  So this program does not violate C99 7.1.3 (and likewise for the
> corresponding paragraph in C89).  But implementations that treat _near
> as a keyword will reject this program.

Well, OK.  But if Draft ANSI C came along in 1989, then Microsoft C presumably
predates it.  I don't know whether there were any formal definitions of what
was reserved when Microsoft C was written, but perhaps there was not much more
than a general agreement that "Programmers use identifiers beginning with _ at their
own risk".  In which case it would have been quite reasonable for Microsoft to use
_near and _far, given that they had to use something.

Tak To <takto@alum.mit.edu.-> writes:
TT> Btw, Lisp and Smalltalk are interpretor languages while C++
TT> is a compiler language.

Robert STRANDH wrote:
RS> I am afraid this is wrong.

It depends on one's usage of these terms; see below.

RS> First, there is really no such thing as an interpreted or a compiled
RS> *language*.  That would be a property of an *implementation* rather
RS> than of a language.  C++ can be implemented as an interpreter and Lisp
RS> and Smalltalk can be implemented as compilers.

No, it is part of the definition of a language as well.

A compiler language has a distinct compilation phase and an
execution phase.  Features and facilities available in one phase
is not necessarily available in the other phase.  Macros in C/C++
are distinctly compiling phase only.

On the other hand, a compiler language leaves much of the execution
environment undefined, whereas an interpreter language explicitly
define it.

If Lisp is basically
   (eval (read))

then C is
   (exec (cc))

and the difference is that exec (the actual system function, not the C
library interface to it) is *not* part of the definition of C.

RS> It is important to get this right.  I have seen people choose the
RS> wrong language for a task, because their reasoning went sort of like
RS> this : Lisp ... Interpreted language ... slow ... not suitable for
RS> my task.  But this chain of reasoning contains the fundamental flaw
RS> indicated above.

The "misconception" has nothing to do with the nomenclature but by
the characteristics of existing languages that people know (or think
they know).  Call Lisp "interactive" and people can still think of
Lisp as slow.

RS> Second, at least as far as Lisp is concerned, most implementations
RS> are compiled.

?? Do you mean "most production Lisp programs are compiled"; or
perhaps "most Lisp implemenation comes with a compiler"?

RS> Indeed they often have excellent compilers, capable of
RS> generating code with execution speed comparable to code generated
RS> by a good C compiler.  And this has been the case for 15 years
RS> or so.  It is sad that totally false statements like this are
RS> still presented as facts.

RS> Finally, perhaps you are confusing "interpreted" with
RS> "interactive"?

No.

Note that I said "interpreter language", not "interpreted
language".  An interpreter language is one whose definition
includes an interpreter (e.g., eval in Lisp).

RS> Obviously, if one thinks that a language with an interaction
RS> loop (like the Lisp Read-Eval-Print Loop) has to be interpreted,
RS> then one is often going to make the wrong decision concerning
RS> the choice of programming language.

One might make the wrong decision; and then one might not.

I think a confusion far more ubiquitous than "interpreter
language is slow" is the comparison of the tightly coupled
nature of the eval-read relationship (or the eval-compile
relationship) in an interpreter language vs the loosely coupled
nature of the exec-cc relationship in a compiler language.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To <takto@alum.mit.edu.-> wrote:
TT> ardon my ignorance.  What are "refactoring tools"?

Bruce Hoult wrote:
BH> Editors that understand the code enough to allow you to
BH> incrementally and safely change the design of existing code.
BH> A simple example is to globally rename all occurences of a
BH> variable without accidentally getting a different variable
BH> that happens to have the same name.

Interesting feature.  I am not sure I will use it very often.

     -----     -----

TT> Btw, Lisp and Smalltalk are interpretor languages while C++
TT> is a compiler language.

BH> That is NOT the case.  Lisp has been primarily a compiled
BH> language (and a very fast one) for the last 25+ years.

Once again I said _interpreter_ (sorry for the typo) vs _compiler_
languages, not _interpreted_ vs _compiled_.  Please read my reply
post to Robert Strandh.

BH> You should look at Guy Steele's papers from 1977 or so,
BH> showing how Scheme maps naturally and simply to very efficient
BH> machine code.

Be as it may, one still will not get fast code if one invokes
eval to execute dynamically created program segments all the time.

In other words, there is a difference in programming style
involved.

Btw, code effiency has a lot to do with the granularity of
compilation.  A classic Lisp eval can be viewed as comprising a
compiler that compiles a token at a time.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

ketil+news@ii.uib.no wrote:

> Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
>> nah nah nahnah nah :-)
>
> Ah, four lines, you say?

No, I said "nah nah nahnah nah".
(Maybe children don't say that in Norway:-)

>> kwicer_than_thou = unlines . sort . concatMap shift . lines
>> shift1 ws = if null ws then [] else tail ws++[head ws]
>> shift ln = let ws = words ln in map unwords $ take (length ws) $ iterate
>> shift1 ws

What, three whole lines?
How about this for further obfuscation :-)

kwic xs = sort $ map unwords $ concat [rotate x | x<- map words xs, x/=[]] 
rotate xs = take (length xs) $ iterate (\(x:xs) -> xs ++ [x]) xs

Regards
--
Adrian Hey

Joachim Durchholz <joachim.durchholz@web.de> writes:

>George Russell wrote:
>>  From section 7.1.3 of the proposed C9X standard:
>
>Largely irrelevant - this was written long after Microsoft published 
>their compilers.

There is similar wording in C89 section 4.1.2:
"All external identifiers that begin with an underscore are reserved.
All other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved."

But MS did get it wrong.  Identifiers begining with an underscore and
a lowercase letter are not reserved for use as local variables, and so
must not be keywords.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

George Russell <ger@tzi.de> writes:

>But surely C compilers have used names beginning with underscores for
>extensions since long before even ANSI C?  I don't think you can really
>blame Microsoft for following the tradition.

We're blaming Microsoft for _not_ following the tradition properly.

In the earlier versions of Microsoft's C compiler, plain "near" and "far"
without any underscores at all were keywords, and if I recall correctly,
there was no way to turn that behaviour off.  Later, presumably after
people complained about it, they attempted to correct this by adding
"_near" and "_far", and providing a compiler switch which meant that
"near" and "far" were not keywords.  But this *still* didn't conform to
the C standard, because they hadn't added enough underscores!  I think
they probably get it right now, but I think it was many years after the
C standard was released before that happened.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To <takto@alum.mit.edu.-> writes:

>Fergus Henderson wrote:
>FH> __near and __far would probably have been reasonable extensions,
>FH> but _near and _far violated the C standard.
>
>Yes, and that was why they were replaced by __near and __far soon
>as the C committee reserved the leading double underscore symbols
>for compiler usage only.

"soon as"?  That doesn't match my recollection.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To <takto@alum.mit.edu.-> writes:

>Fergus Henderson wrote:
>FH> __near and __far would probably have been reasonable extensions,
>FH> but _near and _far violated the C standard.
>
>Yes, and that was why they were replaced by __near and __far soon
>as the C committee reserved the leading double underscore symbols
>for compiler usage only.

"soon as"?  That doesn't match my recollection.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Calum wrote:
> C++ is like one of those fat pen-knives with just about every 
> conceivable gadget and gizmo attached.  Sure, the knife works.  But it 
> also has a pair of scissors, a tooth-pick, a little magnifying glass, a 
> cork-screw, a little saw, a ruler, a screwdriver, and half a dozen 
> gadgets that are strangely shaped and have no apparent purpose.
> 
> Probably, all you wanted was a decent knife.

I would think C++ is more a like a whole set of knifes, offering one
choices to meet one's requirement in the shape of the cut, etc.
Its features are more analogous to the different angles of the edge,
thickness of the blade, serrated vs not serrated, left handed
vs right handed, etc.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To wrote:
> No, it is part of the definition of a language as well.
> A compiler language has a distinct compilation phase and an
> execution phase.  Features and facilities available in one phase
> is not necessarily available in the other phase.  Macros in C/C++
> are distinctly compiling phase only.
> On the other hand, a compiler language leaves much of the execution
> environment undefined, whereas an interpreter language explicitly
> define it.
> 
> If Lisp is basically
>   (eval (read))
> 
> then C is
>   (exec (cc))

why would it be impossible to produce an eval for C?  ofcourse, this
eval would probably need the entire program at once, but that wouldn't
mean it's a compiler.  macros could be expanded by read.

in fact, I believe Ch does something like that
(http://www.softintegration.com), though I have no experience with it.

-- 
Segui il tuo corso, e lascia dir le genti.

Lars

"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:bp08cq$4o0$2$8302bc10@news.demon.co.uk...
> ketil+news@ii.uib.no wrote:
>
> > Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
> >> nah nah nahnah nah :-)
> >
> > Ah, four lines, you say?
>
> No, I said "nah nah nahnah nah".
> (Maybe children don't say that in Norway:-)
>
> >> kwicer_than_thou = unlines . sort . concatMap shift . lines
> >> shift1 ws = if null ws then [] else tail ws++[head ws]
> >> shift ln = let ws = words ln in map unwords $ take (length ws) $
iterate
> >> shift1 ws
>
> What, three whole lines?
> How about this for further obfuscation :-)
>
> kwic xs = sort $ map unwords $ concat [rotate x | x<- map words xs, x/=[]]
> rotate xs = take (length xs) $ iterate (\(x:xs) -> xs ++ [x]) xs

Uh huh.  :-) The thing to remember is that Parnas' paper was about
modularity.  He defined about three or four modules to do the KWIC.

One thing I haven't figured out about Haskell.. is there separate
compilation?  Does the compiler have to see all used types and functions to
compile a file of functions?


Michael Feathers
www.objectmentor.com

Tak To wrote:

> Be as it may, one still will not get fast code if one invokes
> eval to execute dynamically created program segments all the time.
> 
> In other words, there is a difference in programming style
> involved.

AIUI, the use of eval in a Lisp program is *usually* considered a
sign of design failure.  It's a bit like goto that way.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Feathers wrote (snipped):

> Experience is a big part, but I think there is more to it.  For kicks about
> a year ago I tried coding the KWIC program that David Parnas used for his
> classic paper 'On the Criteria to be used in decomposing systems into
> modules.'  I didn't time it but it took only an hour or so to do in Java and
> he mentioned it taking a programmer a week or two.  Of course, there is no
> guarantee that I was using the same spec, I just gleaned requirements from
> the paper, but I strongly suspect that cumulative increases in machine and
> language power have paid off far more than we recognize.

I think Parnas must have been over-pessimistic about what might be
"expected from a good programmer".  I remember solving a similar (not identical)
problem to the KWIC problem in an evening back in 1989 (or thereabouts) with just
Pascal, the system sort routine, and the local command-line text-editor (implemented
c 1975).  I wasn't a good programmer then, and probably wasted too much time coding
unnecessary optimisations.

I would be surprised if you couldn't solve the KWIC problem in a similar amount of
time given just ISO Pascal and a sort routine.  Though it would help if the
programmer were allowed to specify a line length limit on the input.

On Thu, 13 Nov 2003 06:14:45 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
wrote:

>>_near, _far and long long were reasonable extensions given the
>>awkward architecture of the Intel chips.
>
>__near and __far would probably have been reasonable extensions,
>but _near and _far violated the C standard.

There was no C standard.

When there was, many compilers did indeed go to __near and __far.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Thu, 13 Nov 2003 06:47:42 -0500, Tak To <takto@alum.mit.edu.->
wrote:

>What I meant to say was that _stdcall (__stdcall) was not born
>out of necessity of accomodating the awkward Intel architecture
>as were _near and _far; and by the time it was introduced,
>#pragma has already been standardized so Microsoft could have
>used a #pragma instead.

As Watcom did. In fact, Watcom provides programmer-defined calling
conventions via pragmas.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Tak To <takto@alum.mit.edu.-> writes:

> Note that I said "interpreter language", not "interpreted
> language".  An interpreter language is one whose definition
> includes an interpreter (e.g., eval in Lisp).
>

But is eval actually an interpreter?  The Common Lisp spec seems to go
out of it's way to call it the interface to the evaluator instead.
E.g. from the spec:

From the section on eval:


(eval) Evaluates form in the current dynamic environment and the null
lexical environment.

eval is a user interface to the evaluator. 

From the glossary:

evaluation n. a model whereby forms are executed, returning zero or
more values. Such execution might be implemented directly in one step
by an interpreter or in two steps by first compiling the form and then
executing the compiled code; this choice is dependent both on context
and the nature of the implementation, but in any case is not in
general detectable by any program. The evaluation model is designed in
such a way that a conforming implementation might legitimately have
only a compiler and no interpreter, or vice versa. See Section 3.1.2
(The Evaluation Model).

interpreted function n. a function that is not a compiled
function. (It is possible for there to be a conforming implementation
which has no interpreted functions, but a conforming program must not
assume that all functions are compiled functions.)

--
Howard Ding
<hading@hading.dnsalias.com>

George Russell <ger@tzi.de> writes:

>Fergus Henderson wrote (snipped):
>
>> Note that _near is used here as a variable with local scope, not file
>> scope.  So this program does not violate C99 7.1.3 (and likewise for the
>> corresponding paragraph in C89).  But implementations that treat _near
>> as a keyword will reject this program.
>
>Well, OK.  But if Draft ANSI C came along in 1989, then Microsoft C presumably
>predates it.

Draft ANSI C was pretty much finalized already in 1988.
The release of the standard was delayed for procedural reasons,
but the contents didn't change substantially in the year
before it was actually released in 1989.

Microsoft C 6.0 was released in the following year, 1990 [1],
and apparently it still only supported "_far", not "__far" [2],
failing to conform to the previously released standard.

[1] See e.g. <http://pages.prodigy.net/michaln/history/exhibits/>.

[2] See the following Usenet news article, which
    describes how programs written for Watcom C needed to have
    "__far" changed to "_far" to run in Microsoft C 6.0:
    <http://groups.google.com.au/groups?selm=d93-cwi.841066249%40nada.kth.se>.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Bruce Hoult wrote:
> 
> Eek.

Eek indeed!

> cat textfile | perl -ne '

Useless use of cat.

> chomp;
> @w = split " ";

The argument to split is redundant as split with no arguments does
exactly the same thing and chomp is redundant because split removes ALL
whitespace.  If you use the -a switch then perl will do the split for
you and store the contents in the @F array.

> for (1..scalar @w){

The scalar operator is redundant because the range operator forces
scalar context.

>    print join(" ",@w),"\n";

The join is unnecessary as putting an array in a double quoted string
will do the same thing and you can use the -l switch to remove and add
the newline for you.

>    push @w,shift @w
> }' | sort

To summarize:

perl -lane'
for (1..@F){
  print "@F";
  push @F,shift @F
}' textfile | sort



John
-- 
use Perl;
program
fulfillment

Richard Heathfield <dontmail@address.co.uk.invalid> writes:

>Fergus Henderson wrote:
>
>> Corey Murtagh <emonk@slingshot.co.nz.no.uce> writes:
>> 
>>>DOS's memory management was constrained by the architecture.  It's not
>>>like there was the option to set the PC into a flat memory model and use
>>>32-bit pointers at that point.
>> 
>> There was certainly an option to use 32-bit pointers.  It was called
>> "large model".  You couldn't actually use all of the 32 bits, only 28,
>
>I thought it was 20 bits. Am I misremembering?

No, you're correct.  It was 20 for the 8086, and 24 for 80286 protected mode.

My apologies for the mistake.  Before posting the above article,
I had in mind the number 24, but that seemed a little odd,
and I wasn't very confident about my own recollection, so I
googled for "msdos large model" to check it.  The first hit was
<http://www.scit.wlv.ac.uk/cbook/chap6.msdos.memory.html>, which says in
the first paragraph that "An actual far address is constructed from the
sum of a 16 bit segment number and a 16 bit offset with a 4 bit overlap
so it is effectively 28 bits long.".  Unfortunately, I then made the
mistake of accepting this source's validity without double-checking it,
and unfortunately that source was wrong.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

"Joachim Durchholz" <joachim.durchholz@web.de> wrote in message
news:bovnoc$ja2$1@news.oberberg.net...
> Tak To wrote:
> > CBFalconer wrote:
> > CB> Far from it.

> > It is inevitable if a goal is to allow the programmer to
> > choose what's best for him.
>
> You are giving Microsoft far too much credit.
> Microsoft has always pursued what's best for Microsoft, not what's
best
> for the programmers. (Other companies have done likewise, but
Microsoft
> combines lock-in strategies while mobilizing heaps of impunity to give
> lip service to openness and programmer productivity.)

La da-da da-da da.  da-Da!

You said that brother!

[IBPD-In'tl Brotherhood of Programmers & Developers :- ]

However, don't writer is an M$ shill, but thinking about what we all,
with the best being hoped for, *expect* to be nature of what was going
on.

Ohhh, I dislike Bill "Alfred Nueman looking" Gates, Steve "Dogus Goofus"
Ballmer, and even Allchin for leaving a high flying LAN firm for the
Bea$ts Who Shun the East!

Dang!!  Now my bp is up!  ;- }

Elliott
-- 
                      *~* Theory Leads, Practice Verifies *~*
     *~*  Global Plans + IID (Iterative & Incremental Development) *~*

"Alan Balmer" <albalmer@att.net> wrote in message
news:tpa7rvkdofs1c7iqaam5k3873fk8ajtiji@4ax.com...
> On Thu, 13 Nov 2003 06:14:45 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
> wrote:
>
> >>_near, _far and long long were reasonable extensions given the
> >>awkward architecture of the Intel chips.

Yeah, seems it was more Sh'Imtel fault, with that daffy architecture.
Or did Gates get 'em going?

Death to "Wintel!!!!!!!"

Arrrrgggghhhhh!

 ;- }

Elliott

> >
> >__near and __far would probably have been reasonable extensions,
> >but _near and _far violated the C standard.
>
> There was no C standard.
>
> When there was, many compilers did indeed go to __near and __far.
>
> -- 
> Al Balmer
> Balmer Consulting
> removebalmerconsultingthis@att.net

Alan Balmer <albalmer@att.net> writes:

>On Thu, 13 Nov 2003 06:14:45 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
>wrote:
>
>>>_near, _far and long long were reasonable extensions given the
>>>awkward architecture of the Intel chips.
>>
>>__near and __far would probably have been reasonable extensions,
>>but _near and _far violated the C standard.
>
>There was no C standard.

There was when Microsoft C 6.0 was released, I'm pretty sure.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Michael Feathers wrote:
> 
.... snip ...
> 
> Experience is a big part, but I think there is more to it.  For
> kicks about a year ago I tried coding the KWIC program that David
> Parnas used for his classic paper 'On the Criteria to be used in
> decomposing systems into modules.'  I didn't time it but it took
> only an hour or so to do in Java and he mentioned it taking a
> programmer a week or two.  Of course, there is no guarantee that
> I was using the same spec, I just gleaned requirements from the
> paper, but I strongly suspect that cumulative increases in machine
> and language power have paid off far more than we recognize.

About 25 years ago I did the same thing, except in Pascal, and
primarily because I disagreed with his partioning.  I recall
timing the effort, and it took one or two days, developed on a
CP/M machine.  I sent him the results and heard nothing back.

IIRC I disagreed with the partitioning primarily because the
result did not model the problem directly, not because of the
efficiency.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Programmer Dude wrote:

> Muzzlebreak wrote:
> 
> 
>>Personally, though, I think C has the one-up on all languages
>>because it itself is very small and is independant of libraries.
> 
> 
> Yet dependant upon them to do anything useful! (like I/O)
> 
> There is a theory that programmers tend to prefer smaller languages
> because they can be retained mentally better.  I mentioned Richard
> Gabriel's book, PATTERNS OF SOFTWARE (see elsethread).  He wrote
> something I'd thought to start a thread with, but perhaps it fits
> here better.  He is speaking about abstractions (something most
> programmers hold up as entirely desireable--but some disagree):
> 
>     Abstractions must be carefully and expertly designed,
>     especially when reuse or compression[1] is intended.
>     However, because abstractions are designed in a partic-
>     ular context and for a particular purpose, it is hard
>     to design them while anticipating all purposes and
>     forgetting all purposes, which is the hallmark of the
>     well designed abstractions.
> 
>     This implies that abstractions are best designed by experts.
>     Worse, average programmers are not well-equipped to design
>     abstractions that have universal usage,...

[...]

To compensate for the average programmer's poor ability to anticipate 
and forget all purposes, the language should provide powerful tools for 
extending and modifying others' abstractions, ideally without needing 
their source code so as not to kill portability.

Unfortunately, the current fashionable languages are more interested in 
preventing changes of abstractions than encouraging them.  The "client 
programmer is the enemy" mentality is very foreign to me.

George Russell wrote:

> Well, OK.  But if Draft ANSI C came along in 1989, then Microsoft C 
> presumably predates it.  I don't know whether there were any formal
> definitions of what was reserved when Microsoft C was written, but
> perhaps there was not much more than a general agreement that
> "Programmers use identifiers beginning with _ at their own risk".  In
> which case it would have been quite reasonable for Microsoft to use 
> _near and _far, given that they had to use something.

I agree that selecting _near and _far as keywords was reasonable at that
time.
However, I disagree that they made them extensions to the function
syntax. And that they used "memory models", forcing programmers to use
one particular addressing mode throughout the entire program, whether
that was appropriate or not. And that they didn't offer functions to 
properly manipulate pointers. And that pointer arithmetic would 
positively break when going beyond the 64K limits, even in the "huge" 
memory model.
In other words, I don't object that they used _near and _far for their 
crap, I object to their crap. (Things have become better over the years 
- on a scale from 1 to 1000, I'd rate DOS a 1, the C compiler and Win 
3.x a 10, and current Windows APIs a 100...)

Regards,
Jo

On Thu, 13 Nov 2003 15:53:27 GMT
"Michael Feathers" <mfeathers@objectmentorNOSPAM.com> wrote:
> Uh huh.  :-) The thing to remember is that Parnas' paper was about
> modularity.  He defined about three or four modules to do the KWIC.
> 
> One thing I haven't figured out about Haskell.. is there separate
> compilation?  

Yes.  There's a module system, hence the 'import List ( ... )' in one of
the earlier examples.

> Does the compiler have to see all used types and functions to
> compile a file of functions?

No, even with inference, i.e. you don't have to declare the types of
exported functions.

A related topic (and a clarification for something on another thread) is
intersection type systems (which Haskell doesn't use).  These have
principal typings (v. principle types). Principal typings allow
compositional type analysis and that makes separate compilation easier,
increases modularity, allows incremental type inference, enables
"smartest" recompilation and can have more accurate error messages.  All
this while being very expressive.  It looks like an interesting
topic to keep an eye on.

On Thu, 13 Nov 2003 17:44:01 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
wrote:

>Alan Balmer <albalmer@att.net> writes:
>
>>On Thu, 13 Nov 2003 06:14:45 GMT, Fergus Henderson <fjh@cs.mu.oz.au>
>>wrote:
>>
>>>>_near, _far and long long were reasonable extensions given the
>>>>awkward architecture of the Intel chips.
>>>
>>>__near and __far would probably have been reasonable extensions,
>>>but _near and _far violated the C standard.
>>
>>There was no C standard.
>
>There was when Microsoft C 6.0 was released, I'm pretty sure.

I didn't know we were talking about a particular release of a
particular compiler. Anyway, when MSC 6 was released there couldn't
have been a standard for very long - I may still have a copy
somewhere, I'll look for the date.

I used MS C when it was really Lattice C (version 2 or 3) and up
through version 7, the last before the "Visual" series. The PWB was
actually one of the better IDEs at the time.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

"FM" <dartdanfm@yahoo.com> wrote in message
news:jaAsb.81932$Gq.13366029@twister.nyc.rr.com...
> "Myles" <a@b.c> wrote:
> > "Torben �gidius Mogensen" <torbenm@diku.dk> wrote in message
> > news:w5islpvhtu.fsf@pc-032.diku.dk...
> > > "Myles" <a@b.c> writes:
> > > You seem to be labouring under the misconception that one single
> > > language should be used for all kinds of application.
> > > ...
> > > A modern language should be designed with a special purpose in mind
> > > and fairly qiuckly get good libraries for that.
>
> > and then someone whose application crosses several languages' domains
(or
> > none of them) gets screwed?  That doesn't sound so desirable to me.
>
> Then use several languages to do it.

That's a screw. A platform that doesn't make all of its application services
available through at least one language is imposing costs on both the
maintainers of the platform and the application developers.

Besides that, dividing up the services among several languages probably
would not satisfy the gastrically challenged poster who started this line of
discussion. He seemed to be very annoyed that the services exist at all.

M.

"Tak To" <takto@alum.mit.edu.-> wrote in message
news:XfOdnUKRlK9zaS-iRVn-ig@comcast.com...
> James Rogers wrote:
> > Statistics also show that the Ada program is
> > likely to have one half to one third the number of bugs as the
>  > released C or C++ program.
>
> Any reference?

and are the projects in question using similar QA processes?

M.

"Myles" <a@b.c> wrote in news:bp0o8i$k61$1@news.Stanford.EDU:

> 
> "Tak To" <takto@alum.mit.edu.-> wrote in message
> news:XfOdnUKRlK9zaS-iRVn-ig@comcast.com...
>> James Rogers wrote:
>> > Statistics also show that the Ada program is
>> > likely to have one half to one third the number of bugs as the
>>  > released C or C++ program.
>>
>> Any reference?
> 
> and are the projects in question using similar QA processes?

There are several references. The one with the fewest independent
variables is http://www.adaic.com/whyada/ada-vs-c/cada_art.html
a pdf version is available at 
http://www.adaic.com/whyada/ada-vs-c/cada_art.pdf

Jim Rogers

In article <3fb3a396$1@news.unimelb.edu.au>,
	Fergus Henderson <fjh@cs.mu.oz.au> writes:
> ...
> In the earlier versions of Microsoft's C compiler, plain "near" and "far"
> without any underscores at all were keywords, and if I recall correctly,
> there was no way to turn that behaviour off. 

you probabaly could have circumvented it with the preprocessor:

#define near
#define far

probably would have made them invisible to the compoiler

> ...

hs

-- 

Not everything that counts can be counted,
not everything that can be counted counts.
	A. Einstein

Tak To wrote:
TT> No, it is part of the definition of a language as well.
TT> A compiler language has a distinct compilation phase and an
TT> execution phase.  Features and facilities available in one phase
TT> is not necessarily available in the other phase.  Macros in C/C++
TT> are distinctly compiling phase only.
TT> On the other hand, a compiler language leaves much of the execution
TT> environment undefined, whereas an interpreter language explicitly
TT> define it.
TT>
TT> If Lisp is basically
TT>   (eval (read))
TT>
TT> then C is
TT>   (exec (cc))

L.J. Buitinck wrote:
LB> why would it be impossible to produce an eval for C?

I did not say an eval is impossible; only it is not part
of the definition of C.

LB> ofcourse,
LB> this eval would probably need the entire program at once, but
LB> that wouldn't mean it's a compiler.  macros could be expanded
LB> by read.

As I said before, an interpreter comprises of a compiler
that compiles one token at a time.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To <takto@alum.mit.edu.-> writes:

> A compiler language has a distinct compilation phase and an
> execution phase.  Features and facilities available in one phase
> is not necessarily available in the other phase.  Macros in C/C++
> are distinctly compiling phase only.
> 
> On the other hand, a compiler language leaves much of the execution
> environment undefined, whereas an interpreter language explicitly
> define it.

I am sorry that I confused "compiled language" and your definition of
"compiler language" (idem for "interpreted language" and your
definition of "interpreter language").

You are naturally free to define whatever words you choose to mean
whatever you want them to mean, but these definitions of yours (I
don't think I have ever seen anything similar in the literature) are
very confusing indeed. 

For instance, a "compiler language" according to your definition can
very well be implemented as an interpreter without a compiler, and an
"interpreter language" can be implemented with no interpreter and only
a compiler.  I would recommend you alter your terminology to avoid
this kind of confusion.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Tak To <takto@alum.mit.edu.-> writes:

> RS> Second, at least as far as Lisp is concerned, most implementations
> RS> are compiled.
> 
> ?? Do you mean "most production Lisp programs are compiled"; or
> perhaps "most Lisp implemenation comes with a compiler"?

The latter.  But I suspect the former is true as well. 

> Note that I said "interpreter language", not "interpreted
> language".  An interpreter language is one whose definition
> includes an interpreter (e.g., eval in Lisp).

As someone else already pointed out, there is no requirement that eval
in Lisp be implemented as an interpreter.  Indeed, there is at least
one implementation that does not have an interpreter at all.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

On Fri, 14 Nov 2003 00:16:48 -0500, Tak To wrote:
> Sorry I couldn't figure out what has been discussed up to this
> point.  Let me understand this, what was contemporary with
> the release of MSC 6.0?

I believe it was disco.


-- 
..................................................
"Beam me aboard, Scotty." "Sure. Will a 2x10 do?"

Rod Davison -  Critical Knowledge Systems Inc. 

Fergus Henderson wrote:
 > [...]
> There was when Microsoft C 6.0 was released, I'm pretty sure.

Sorry I couldn't figure out what has been discussed up to this
point.  Let me understand this, what was contemporary with
the release of MSC 6.0?

Tak

"Tak To" <takto@alum.mit.edu.-> wrote:
> FM wrote:
> > [C++] is a highly extensible language.  The problem is that
> > the extensibility was achieved by adding on a great deal
> > of complexity, at every level of the language design,
> > rather than orthogonality and elegance.

> I am not sure what you mean by "extensible".

It supports all common forms of polymorphism (runtime,
parametric, and ad hoc) and has a functional, albeit
highly broken, macro system.  These features do allow
the language to be extended to a high degree (as in,
it's possible to add abstractions at various levels).

> When I think
> "extensible", I usually think Lisp, with its simple syntax
> and powerful! macro capability.

Yes, all dialects of Lisp that I'm aware of are highly
extensible.


> I also don't understand
> what do you mean by extendability in the expense of complexity.

There are a lot of special syntactic and semantic rules
that exist in order to support those features.  As
opposed to, say, Scheme, which is highly extensible
without nearly as much complexity.


> I tend to think of C/C++ as highly "tunable" languages, second
> perhaps only to assemblers.  The tunability allows the
> programmers to specify many aspects of the program in great
> details.  It is what gives the complexity

No, C is just as tunable, but is nowhere near as complex as
C++.  C++ is complex because it is essentially a combination
of C and a whole bunch of features allowing the language to
be extended in various ways, while still allowing what was
possible in C.

Dan.

Fergus Henderson wrote:
FH> __near and __far would probably have been reasonable extensions,
FH> but _near and _far violated the C standard.

Tak To <takto@alum.mit.edu.-> writes:
TT> Yes, and that was why they were replaced by __near and __far soon
TT> as the C committee reserved the leading double underscore symbols
TT> for compiler usage only.

FH> "soon as"?  That doesn't match my recollection.

What was your recollection?

Tak

Tak To wrote:
TT> Btw, Lisp and Smalltalk are interpretor languages while C++
TT> is a compiler language.

Joachim Durchholz wrote:
JD> This doesn't affect the complexity of the language semantics.

And I did not say it either.

My comment was on the contrast of availability of "other tools" such
as a debugger.  (When the language is designed to have an interpreter,
it is easy to fit in a debugger.)

And my point was really: don't compare apples with oranges.

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

[Followups set to comp.programming]

Tak To wrote:

> As I said before, an interpreter comprises of a compiler
> that compiles one token at a time.

That isn't actually true. "Simply stated, a compiler is a program that reads 
a program written in one language - the /source/ language - and translates 
it into an equivalent program in another language - the /target/ language." 
(Dragon book: page 1.)

"Instead of producing a target program as a translation, an interpreter 
performs the operations implied by the source program."
(Dragon book: page 3.)

Since the interpreter does not produce a translation of the source program 
in another language, it is not a compiler.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Tak To wrote:
TT> _near, _far and long long were reasonable extensions given the awkward
TT> architecture of the Intel chips.

Joachim Durchholz wrote:
JD> Agreed.
JD> Just as every other single extension is "reasonable".

Is it really?  I have not examined every extension. :-)

JD> I'm just wondering why Microsoft extended the language in
JD> incompatible ways.  Everything could have been packaged
JD> in library functions.

As I mentioned in another post, the double underscore prefix was
not available as a standard at that point (mid 80's).  Pretty
sure #pragma was not either.

TT> All the C/C++ compilers for the Intel hardware platform have them.

JD> Only because Microsoft had set the example, and they were more-or
JD> -less forced to follow the lead.

You might be right that MS (or Lattice C back then) was the first to
start using the names _near and _far, but it does not mean that other
compilers would have stayed away from introducing special keywords to
accomodate the Intel architecture.  Better the same keyword then
different ones.

      -----     -----

TT> _stdcall is equivalent to a #pragma

JD> Then why isn't it a #pragma?

This I agree with you that it should have been a #pragma.

TT> and is essential to inter-operability with compilers and languages.

JD> Right, it's interoperability stuff.  It's *all* interoperability stuff.
JD>
JD> It's not that these extensions don't serve useful purposes. It's the
JD> way that Microsoft integrated them into the language: with little care
JD> for portability.

Let me understand this.  Are you opposed to __near as well?  __near is
not portable either but legal within the definition of C.

And what in your opinion should a compiler writer do if he thinks
the language can benefit from an extension?

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

George Russell wrote:
GR> I am very far from being a Microsoft fan, but surely _near and
GR> _far were an inevitable consequence of Intel's 16-bit instruction
GR> set?

CBFalconer wrote:
CB> Far from it.

Tak To wrote:
TT> It is inevitable if a goal is to allow the programmer to
TT> choose what's best for him.

Joachim Durchholz wrote:
JD> You are giving Microsoft far too much credit.
JD> Microsoft has always pursued what's best for Microsoft, not what's best
JD> for the programmers. (Other companies have done likewise, but Microsoft
JD> combines lock-in strategies while mobilizing heaps of impunity to give
JD> lip service to openness and programmer productivity.)

I think you are too cynical.

      -----     -----

JD> MS never added a compatibility mode that would have allowed us to
JD> compile, say, grep and company.

What happened when you compiled the source code of grep with MSC?

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

In article <3FB3B7C5.9C091952@acm.org>,
 "John W. Krahn" <krahnj@acm.org> wrote:

> Bruce Hoult wrote:
> > 
> > Eek.
> 
> Eek indeed!
> 
> > cat textfile | perl -ne '
> 
> Useless use of cat.

*That* was deliberate, to emphasise the stream-processing nature of the 
program.


> > chomp;
> > @w = split " ";
> 
> The argument to split is redundant as split with no arguments does
> exactly the same thing and chomp is redundant because split removes ALL
> whitespace.  If you use the -a switch then perl will do the split for
> you and store the contents in the @F array.
> 
> > for (1..scalar @w){
> 
> The scalar operator is redundant because the range operator forces
> scalar context.
> 
> >    print join(" ",@w),"\n";
> 
> The join is unnecessary as putting an array in a double quoted string
> will do the same thing and you can use the -l switch to remove and add
> the newline for you.
> 
> >    push @w,shift @w
> > }' | sort
> 
> To summarize:
> 
> perl -lane'
> for (1..@F){
>   print "@F";
>   push @F,shift @F
> }' textfile | sort


Fair cop, guv'nor.  I'm a lot less expert in Perl than I am in C or 
Dylan.  But then it *did* only take about two minutes to write.  Looking 
up all the defaults and options to get your several lines shorter 
version might well have taken me another half hour.

-- Bruce

In article <PeGdnX9c5sBJPS6iRVn-uA@comcast.com>,
 Tak To <takto@alum.mit.edu.-> wrote:

> TT> Btw, Lisp and Smalltalk are interpretor languages while C++
> TT> is a compiler language.
> 
> BH> That is NOT the case.  Lisp has been primarily a compiled
> BH> language (and a very fast one) for the last 25+ years.
> 
> Once again I said _interpreter_ (sorry for the typo) vs _compiler_
> languages, not _interpreted_ vs _compiled_.  Please read my reply
> post to Robert Strandh.
> 
> BH> You should look at Guy Steele's papers from 1977 or so,
> BH> showing how Scheme maps naturally and simply to very efficient
> BH> machine code.
> 
> Be as it may, one still will not get fast code if one invokes
> eval to execute dynamically created program segments all the time.

But one *doesn't*.  Using "eval" a lot is a sure sign of a Lisp 
beginner.  Many or most Lisp programs *never* use it, and such famous 
books as _On Lisp_ take pains to make it clear that when they talk about 
creating functions at runtime they are talking about *closures*, not 
"eval".


The Lisp dialect I mostly use (Dylan) doesn't even *have* eval.

-- Bruce

NFish wrote:
> Programmer Dude wrote:
> 
>> Muzzlebreak wrote:
>>
>>
>>> Personally, though, I think C has the one-up on all languages
>>> because it itself is very small and is independant of libraries.
>>
>>
>>
>> Yet dependant upon them to do anything useful! (like I/O)
>>
>> There is a theory that programmers tend to prefer smaller languages
>> because they can be retained mentally better.  I mentioned Richard
>> Gabriel's book, PATTERNS OF SOFTWARE (see elsethread).  He wrote
>> something I'd thought to start a thread with, but perhaps it fits
>> here better.  He is speaking about abstractions (something most
>> programmers hold up as entirely desireable--but some disagree):
>>
>>     Abstractions must be carefully and expertly designed,
>>     especially when reuse or compression[1] is intended.
>>     However, because abstractions are designed in a partic-
>>     ular context and for a particular purpose, it is hard
>>     to design them while anticipating all purposes and
>>     forgetting all purposes, which is the hallmark of the
>>     well designed abstractions.
>>
>>     This implies that abstractions are best designed by experts.
>>     Worse, average programmers are not well-equipped to design
>>     abstractions that have universal usage,...
> 
> 
> [...]
> 
> To compensate for the average programmer's poor ability to anticipate 
> and forget all purposes, the language should provide powerful tools for 
> extending and modifying others' abstractions, ideally without needing 
> their source code so as not to kill portability.
> 
> Unfortunately, the current fashionable languages are more interested in 
> preventing changes of abstractions than encouraging them.  The "client 
> programmer is the enemy" mentality is very foreign to me.

Most programming is team-work.  We all need protecting from our bosses 
who still think they can code, and juniors who are learning on the job...

Bullet-proofing your code is actually a help to the client programmer. 
Of course they will make mistakes and invalid assumptions, that is what 
programming is all about.  It's far better for the compiler to tell them 
what shouldn't be done, than for them to go running to you with a "bug".

A language without compile-time protection mechanisms is more vulnerable 
to accidental abuse by client programmers.

Tak To wrote:
> As I said before, an interpreter comprises of a compiler
> that compiles one token at a time.

shouldn't that be one expression at a time?

-- 
Segui il tuo corso, e lascia dir le genti.

Lars

Richard Heathfield wrote:
> Since the interpreter does not produce a translation of the source program 
> in another language, it is not a compiler.

it could be argued that it does -- the other language being its data
structures.  contrived, but not much more than the rest of this
discussion ;)

-- 
Segui il tuo corso, e lascia dir le genti.

Lars

Bruce Hoult wrote:
> In article <bouat2$b5m$1@news-int2.gatech.edu>,
>  gt5163b@prism.gatech.edu (Brian McNamara!) wrote:
> 
> 
>>"Michael Feathers" <mfeathers@objectmentorNOSPAM.com> once said:
>>
>>>Experience is a big part, but I think there is more to it.  For kicks about
>>>a year ago I tried coding the KWIC program that David Parnas used for his
>>>classic paper 'On the Criteria to be used in decomposing systems into
>>>modules.'  I didn't time it but it took only an hour or so to do in Java and
>>>he mentioned it taking a programmer a week or two.  Of course, there is no
>>>guarantee that I was using the same spec, I just gleaned requirements from
>>>the paper, but I strongly suspect that cumulative increases in machine and
>>>language power have paid off far more than we recognize.
>>
>>Indeed, see "Yannis's Law: Programmer Productivity Doubles Every 6 Years"
>>   http://www.cc.gatech.edu/~yannis/law.html
>>for a similar perspective.
> 
> 
> Eek.
> 
> cat textfile | perl -ne '
> chomp;
> @w = split " ";
> for (1..scalar @w){
>    print join(" ",@w),"\n";
>    push @w,shift @w
> }' | sort
> 

same with awk (who needs perl when one can do it in AWK ;-)

echo that is my try to do kwic |
awk '{for (i=1; i<=NF; i++) {
        $(NF+1)=$1; $1=""
        sub(/^ */,""); print}
    }' | sort

-- 
Vale !
		Christianus Auriocus

Tak To wrote:
> 
> Joachim Durchholz wrote:
> JD> You are giving Microsoft far too much credit.
> JD> Microsoft has always pursued what's best for Microsoft, not what's best
> JD> for the programmers. (Other companies have done likewise, but Microsoft
> JD> combines lock-in strategies while mobilizing heaps of impunity to give
> JD> lip service to openness and programmer productivity.)
> 
> I think you are too cynical.

No, you can't be cynical enough when it comes to judging the behaviour 
of commercial enterprises. Create one yourself if you don't believe me 
(I did - it wasn't successful, but it taught be a lot).

> JD> MS never added a compatibility mode that would have allowed us to
> JD> compile, say, grep and company.
> 
> What happened when you compiled the source code of grep with MSC?

It wouldn't compile because header files were in different places, were 
named slightly differently, or defined things in slightly different ways.
Once that was out of the way, it wouldn't link because a couple of 
routines was missing, one of them usually fork() or one of the exec*() 
functions (having no fork() was the worst single problem, but even with 
that it would have been difficult).
Even if you got that working, the programs usually wouldn't work: 
directory separators are \ instead of / (for no good reason at all), or 
other slight semantic differences. Each single difference is small, but 
in summary, it's enough to seriously discourage any attempt at porting 
the tools. The total binary size of a Posix emulation on Windows is 
currently at 949KB and still increasing (it's the cygwin1 dll, and its 
size has a reason).

Given that the majority of these differences serves no technical 
purpose, I can imagine only two reasons: laziness, and intentional 
lock-in strategies. I leave it to you to decide which reason should be 
considered worse.

Regards,
Jo

Tak To wrote:
> Joachim Durchholz wrote:
>> Right, it's interoperability stuff.  It's *all* interoperability 
>> stuff.
>> 
>> It's not that these extensions don't serve useful purposes. It's
>> the way that Microsoft integrated them into the language: with
>> little care for portability.
> 
> Let me understand this.  Are you opposed to __near as well?

Yes.
There would have been more portable alternatives.
For example, a pointer arithmetic that handled 64K bounds correctly.
And: Recommendations to work with indexing instead of pointer arithmetic 
when accessing arrays smaller than 64K, so that the compiler could use 
near addressing.
And, in general, simply sticking with what was called the "huge memory 
model", offering library routines to interface with assembly language 
that used a different memory model.

> __near is not portable either but legal within the definition of C.

Agreed.
Though it wasn't when MS introduced it.

> And what in your opinion should a compiler writer do if he thinks the
> language can benefit from an extension?

He should ask the programmer community to see whether there's a better
way than extending the language.
Extending a language is the worst sin that a compiler writer can commit.

Regards,
Jo

Joachim Durchholz wrote (snipped):

> It wouldn't compile because header files were in different places, were 
> named slightly differently, or defined things in slightly different ways.
> Once that was out of the way, it wouldn't link because a couple of 
> routines was missing, one of them usually fork() or one of the exec*() 
> functions (having no fork() was the worst single problem, but even with 
> that it would have been difficult).
> Even if you got that working, the programs usually wouldn't work: 
> directory separators are \ instead of / (for no good reason at all), or 
> other slight semantic differences. Each single difference is small, but 
> in summary, it's enough to seriously discourage any attempt at porting 
> the tools. The total binary size of a Posix emulation on Windows is 
> currently at 949KB and still increasing (it's the cygwin1 dll, and its 
> size has a reason).

I agree that's it's a pity Microsoft didn't make DOS a bit more like Unix,
but implementing Unix on very early PCs might have been a bit tricky, and
after that they were rather locked in.

Joachim Durchholz wrote (snipped):

> He should ask the programmer community to see whether there's a better
> way than extending the language.
> Extending a language is the worst sin that a compiler writer can commit.

Please don't say this to the Microsoft Researchers currently working on
Glasgow Haskell, since I would find a lot of the things I do impossible
without their extensions to Haskell.

Joachim Durchholz wrote:
> 
> And: Recommendations to work with indexing instead of pointer arithmetic
> when accessing arrays smaller than 64K, so that the compiler could use
> near addressing.

Er, in C, indexing is just syntactic sugar for pointer arithmetics.

        - Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.

On Fri, 14 Nov 2003, Andreas Rossberg wrote:
>
> Joachim Durchholz wrote:
> >
> > And: Recommendations to work with indexing instead of pointer arithmetic
> > when accessing arrays smaller than 64K, so that the compiler could use
> > near addressing.
>
> Er, in C, indexing is just syntactic sugar for pointer arithmetics.

But it may be more amenable to near-addressing optimizations in
some cases.  Or that's the way it looked to me at first, though
I am having trouble coming up with a good example.
  The idea, I think, was that when you index an array, the compiler
can know the range of that pointer right away (from arr[0] to
arr[length]) and use near addressing.  When you use direct pointer
arithmetic, the compiler has fewer clues as to how big a structure
you're accessing, and might not be able to optimize the access as
well as it could otherwise.

my $.02,
-Arthur

Tak To wrote:
> Fergus Henderson wrote:
> FH> __near and __far would probably have been reasonable extensions,
> FH> but _near and _far violated the C standard.
> 
> Tak To <takto@alum.mit.edu.-> writes:
> TT> Yes, and that was why they were replaced by __near and __far soon
> TT> as the C committee reserved the leading double underscore symbols
> TT> for compiler usage only.
> 
> FH> "soon as"?  That doesn't match my recollection.
> 
> What was your recollection?

Don't know about FH, but my recollection is that as late as MSVC++7.1 
their adherence to the C++ standard was infamously terrible. Even 
without underscores "near" and "far" were unavailable as variable names. 
The one time I looked into trying to make their compiler more 
standards-compliant, I discovered a flag for turning off Microsoft 
"extensions." Unfortunately this flag rendered their implementation of 
the STL uncompilable. But the compiler suffered from more than 
standards-incompliance. I paid $300 for the Intel compiler on top of the 
price of Visual Studio to get a compiler that didn't suck (and yet had 
to be deliberately feature-for-bug compatible with MSVC++). C++2003 
seems to be a big improvement, but it's still buggy.

-thant

"L.J. Buitinck" wrote:

>> Since the interpreter does not produce a translation of the
>> source program in another language, it is not a compiler.
> 
> it could be argued that it does -- the other language being its
> data structures.  contrived, but not much more than the rest of
> this discussion ;)

I think the implicit distinction is that a compiler produces a
*complete* translation as its *output*.  In interpreter produces a
"bit-by-bit" translation as an *intermediate* and produces action
as its "output".

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"John W. Krahn" wrote:

> To summarize:
> 
> perl -lane'for(1..@F){print "@F";push @F,shift @F}' textfile |
> sort

And *that's* why we love Perl!  (-:

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Arthur wrote:
) But it may be more amenable to near-addressing optimizations in
) some cases.  Or that's the way it looked to me at first, though
) I am having trouble coming up with a good example.
)   The idea, I think, was that when you index an array, the compiler
) can know the range of that pointer right away (from arr[0] to
) arr[length]) and use near addressing.  When you use direct pointer
) arithmetic, the compiler has fewer clues as to how big a structure
) you're accessing, and might not be able to optimize the access as
) well as it could otherwise.

The problem is that in C it's perfectly legal to address an array outside
of its boundaries.  So the compiler can *not* know the range of that
pointer.


SaSW, Willem (at stack dot nl)
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Joachim Durchholz wrote:

> Given that the majority of these differences serves no technical
> purpose, I can imagine only two reasons: laziness, and intentional
> lock-in strategies.

Two more might be: misguided sense of creativity or (and this is
similar, actually) a sense of NIH.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

NFish wrote:

>> ...Richard Gabriel's book, PATTERNS OF SOFTWARE...
>>
>>     Abstractions must be carefully and expertly designed, [...]
>>     However, [...] it is hard to design them while anticipating
>>     all purposes and forgetting all purposes, which is the
>>     hallmark of the well designed abstractions.
>>
>>     This implies that abstractions are best designed by experts.
>>     Worse, average programmers are not well-equipped to design
>>     abstractions that have universal usage,...
> 
> To compensate for the average programmer's poor ability to
> anticipate and forget all purposes, the language should provide
> powerful tools for extending and modifying others' abstractions,
> ideally without needing their source code so as not to kill
> portability.

That would be quite a trick, I think.  I think, too, it risks a
what I view as a problem with a language, like Smalltalk: divergence.
Smalltalkers modify the Smalltalk image and environment considerably.
This customization does make them more productive, but (IMO) at the
expense of compatibility with their fellow workers.

I've heard stories about person 'A' sitting down at co-worker 'B's
system and not being able to use it effectively, because 'B' has
so heavily customized it.  (OTOH, there is something very attractive
about treating programming as a form of sculpture.)

Gabriel suggests another tactic: don't use abstraction so much.
It's find for truly abstract things (e.g. a stack), but most classes
don't need to be written with inheritance in mind (Gabriel and others
suggest a class heirarchy that *much* wider than it is deep).

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

On Fri, 14 Nov 2003 16:23:01 +0000, Willem wrote:

> Arthur wrote:
> ) But it may be more amenable to near-addressing optimizations in
> ) some cases.  Or that's the way it looked to me at first, though
> ) I am having trouble coming up with a good example.
> )   The idea, I think, was that when you index an array, the compiler
> ) can know the range of that pointer right away (from arr[0] to
> ) arr[length]) and use near addressing.  When you use direct pointer
> ) arithmetic, the compiler has fewer clues as to how big a structure
> ) you're accessing, and might not be able to optimize the access as
> ) well as it could otherwise.
> 
> The problem is that in C it's perfectly legal to address an array outside
> of its boundaries.

Actually it isn't legal at all, with the exception that it is legal to
compute a pointer to "one past the last element of the array object".
That pointer may not be dereferenced, however.

George Russell wrote:
> Joachim Durchholz wrote (snipped):
> 
>> He should ask the programmer community to see whether there's a
>> better way than extending the language. Extending a language is the
>> worst sin that a compiler writer can commit.
> 
> Please don't say this to the Microsoft Researchers currently working
> on Glasgow Haskell, since I would find a lot of the things I do
> impossible without their extensions to Haskell.

*shrug* Haskell is a great language, and it's headed towards becoming
even better. However, this makes it a moving target, and that's a
liability in commercial projects.
For Haskell, that's OK - it's still more of a testbed for lazy FPL
implementation. For C, this was most definitely not OK, since it was a
platform for commercial development.

OT3H, it's the Evil Empire of Redmont again... ;-)

Regards,
Jo

Andreas Rossberg wrote:

> Joachim Durchholz wrote:
> 
>> And: Recommendations to work with indexing instead of pointer
>> arithmetic when accessing arrays smaller than 64K, so that the
>> compiler could use near addressing.
> 
> Er, in C, indexing is just syntactic sugar for pointer arithmetics.

No, it isn't. Indexing retains more information that the compiler can 
exploit.
On machines with a linear flat address space, the two idioms are indeed 
roughly equivalent, but on segmented architectures, there /is/ a 
difference unless you implement all pointers in a base-plus-offset 
format - which is exactly what the C compilers for x86 processors tried 
to avoid due to efficiency concerns.

Regards,
Jo

On Fri, 14 Nov 2003 19:56:24 +0100, Joachim Durchholz wrote:

> Andreas Rossberg wrote:
> 
>> Joachim Durchholz wrote:
>> 
>>> And: Recommendations to work with indexing instead of pointer
>>> arithmetic when accessing arrays smaller than 64K, so that the
>>> compiler could use near addressing.
>> 
>> Er, in C, indexing is just syntactic sugar for pointer arithmetics.
> 
> No, it isn't. Indexing retains more information that the compiler can 
> exploit.

The C Standard states:

  The definition of the subscript operator [] is that E1[E2] is identical
  to (*((E1)+(E2))).

In article <bp386o$t0j$1@news.oberberg.net>,
Joachim Durchholz  <joachim.durchholz@web.de> wrote:
(snip)
>*shrug* Haskell is a great language, and it's headed towards becoming
>even better. However, this makes it a moving target, and that's a
>liability in commercial projects.
(snip)

We're using Haskell in commercial projects, but are simply being
careful to use only Haskell 98 plus extensions that are very likely to
make it into the next standard in much their present form. For
instance, we're avoiding Template Haskell even though it looks really
cool, but we are using things like multi-parameter type classes.
(comp.object trimmed from followups.)

-- Mark

On Fri, 14 Nov 2003, Sheldon Simms wrote:
>
> On Fri, 14 Nov 2003 19:56:24 +0100, Joachim Durchholz wrote:
> > Andreas Rossberg wrote:
> >> Joachim Durchholz wrote:
> >>
> >>> And: Recommendations to work with indexing instead of pointer
> >>> arithmetic when accessing arrays smaller than 64K, so that the
> >>> compiler could use near addressing.
> >>
> >> Er, in C, indexing is just syntactic sugar for pointer arithmetics.
> >
> > No, it isn't. Indexing retains more information that the compiler can
> > exploit.
>
> The C Standard states:
>
>  The definition of the subscript operator [] is that E1[E2] is identical
>  to (*((E1)+(E2))).

Right.  So indexing retains more information.  Which is more verbose,

   a[i]   --or--   *p

So, which one contains more information?  Obviously, the one that
specifies "base address plus offset" (a and i, respectively), as
opposed to the one that only specifies "address" (p).  You see,
nobody ever writes expressions involving '*(p+i)' in C, because
that would in the *vast* majority of cases be silly.
  <strawman analogy> In C, the literal -1 is defined as the result
of applying the unary minus operator to the literal 1.  Which is
more amenable to compiler optimization,

  i = -1;  --or--  i = 1; i = -i;

See the point?  (You seem to have seen the point already, else-
thread; I think you're just being pedantic pro gratia pedantry
about the pointer-array duality.)

HTH,
-Arthur

On Fri, 14 Nov 2003 14:01:32 +0100, Andreas Rossberg
<rossberg@ps.uni-sb.de> wrote:

>Joachim Durchholz wrote:
>> 
>> And: Recommendations to work with indexing instead of pointer arithmetic
>> when accessing arrays smaller than 64K, so that the compiler could use
>> near addressing.
>
>Er, in C, indexing is just syntactic sugar for pointer arithmetics.
>
>        - Andreas
I think it was Borland that introduced "based" objects to do this.

It allowed them to load a segment register, then use near offsets.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Fri, 14 Nov 2003 15:56:44 -0500, Arthur J. O'Dwyer wrote:
>
> On Fri, 14 Nov 2003, Sheldon Simms wrote:
>>
>> On Fri, 14 Nov 2003 19:56:24 +0100, Joachim Durchholz wrote:
>> > Andreas Rossberg wrote:
>> >>
>> >> Er, in C, indexing is just syntactic sugar for pointer arithmetics.
>> >
>> > No, it isn't. Indexing retains more information that the compiler can
>> > exploit.
>>
>> The C Standard states:
>>
>>  The definition of the subscript operator [] is that E1[E2] is
>>  identical to (*((E1)+(E2))).
> 
> Right.  So indexing retains more information.  Which is more verbose,
> 
>    a[i]   --or--   *p
> 
> So, which one contains more information?  Obviously, the one that
> specifies "base address plus offset" (a and i, respectively), as opposed
> to the one that only specifies "address" (p).

The assertion made was "indexing retains more information" than pointer
arithmetic. That is false. The expression *p does not involve any pointer
arithmetic. The expression p+i _is_ pointer arithmetic and the expression
*(p+i) uses pointer arithmetic to access an element of an array. In fact,
as we see from the C standard, *(p+i) is exactly the same as p[i] or i[p].
There is no question about which kind of expression "retains more
information".

> You see, nobody ever writes expressions involving '*(p+i)' in C,
> because that would in the *vast* majority of cases be silly.

Well gee, *I* write that sort of expression occasionally. Does that
make me silly?

>   <strawman analogy> In C, the literal -1 is defined as the result
> of applying the unary minus operator to the literal 1.  Which is
> more amenable to compiler optimization,
> 
>   i = -1;  --or--  i = 1; i = -i;

Neither is more amenable to compiler optimization. The abstract semantics
are slightly different, but unless i is declared volatile, the observed
behavior would be the same, unless the compiler is *very* stupid.

I don't know what this example has to do with indexing vs. pointer
arithmetic in any case.

On Fri, 14 Nov 2003, Sheldon Simms wrote:
>
> On Fri, 14 Nov 2003 15:56:44 -0500, Arthur J. O'Dwyer wrote:
> > On Fri, 14 Nov 2003, Sheldon Simms wrote:
> >> On Fri, 14 Nov 2003 19:56:24 +0100, Joachim Durchholz wrote:
> >> >
> >> > No, it isn't. Indexing retains more information that the compiler can
> >> > exploit.
> >>
> >>  The definition of the subscript operator [] is that E1[E2] is
> >>  identical to (*((E1)+(E2))).
> >
> > Right.  So indexing retains more information.  Which is more verbose,
> >
> >    a[i]   --or--   *p

> The assertion made was "indexing retains more information" than pointer
> arithmetic. That is false. The expression *p does not involve any pointer
> arithmetic.

The usual idiom is

   for (i=0; i < array_size; ++i)
     f(a[i]);

versus

   end = a+array_size;
   for (p=a; p < end; ++p)
     f(*p);

The pointer arithmetic involved with '*p' was implied.  Sure, if
you don't advance the pointer, you're not doing pointer arithmetic
-- but you can't usefully index an array with pointer arithmetic
without advancing the pointer, and we were talking about arrays,
right?

> > You see, nobody ever writes expressions involving '*(p+i)' in C,
> > because that would in the *vast* majority of cases be silly.
>
> Well gee, *I* write that sort of expression occasionally. Does that
> make me silly?

Yes, naturally. :-)
  Seriously, in what contexts would *(p+i) be a more natural
idiom than p[i]?  I can't think of any.


> >   <strawman analogy> In C, the literal -1 is defined as the result
> > of applying the unary minus operator to the literal 1.  Which is
> > more amenable to compiler optimization,
> >
> >   i = -1;  --or--  i = 1; i = -i;
>
> Neither is more amenable to compiler optimization. The abstract semantics
> are slightly different, but unless i is declared volatile, the observed
> behavior would be the same, unless the compiler is *very* stupid.

Right.  But on the average '80s-technology compiler (remember,
we were talking about pre-"protected mode" 80x86 architectures?),
the first would become

   mov si, -1

and the second would become

   mov si, 1
   neg si

That was my point -- that *yes*, the C Standard says they do the
same thing.  But one of them does it in a more contorted fashion,
and pays the price of efficiency (on the average compiler).  This
is comp.programming, so I can say that. :-D

> I don't know what this example has to do with indexing vs. pointer
> arithmetic in any case.

Analogy.

  for (i=0; i < n; ++i)
    foo(a[i]);

  for (p=a; p < a+n; ++p)
    foo(*p);

These loops *will* produce different machine code on the average
8086-based compiler.  More relevantly, the a[i] version
encapsulates the array's base address and extent within the
expression a[i] (base is a, extent is sizeof a), while the *p
version smears that information out over the whole for(...)
part (base is a, extent is probably n-1?).  The former IMHO
makes for much easier segment-offset optimization, should the
compiler wish to make such optimizations.

-Arthur

Mark Carroll wrote:

> In article <bp386o$t0j$1@news.oberberg.net>,
> Joachim Durchholz  <joachim.durchholz@web.de> wrote:
> (snip)
> 
>>*shrug* Haskell is a great language, and it's headed towards becoming
>>even better. However, this makes it a moving target, and that's a
>>liability in commercial projects.
> 
> (snip)
> 
> We're using Haskell in commercial projects, but are simply being
> careful to use only Haskell 98 plus extensions that are very likely to
> make it into the next standard in much their present form. For
> instance, we're avoiding Template Haskell even though it looks really
> cool, but we are using things like multi-parameter type classes.
> (comp.object trimmed from followups.)

Ah, this helps clarify things.
In Haskell, it's possible and practical to avoid nonstandard extensions. 
With MS C, it was impractical if not impossible to avoid them.

Well, enough of this subthread. I think the issues are clear enough now :-)

Regards,
Jo

Joachim Durchholz wrote:
> Andreas Rossberg wrote:
> > Joachim Durchholz wrote:
> >
> >> And: Recommendations to work with indexing instead of pointer
> >> arithmetic when accessing arrays smaller than 64K, so that the
> >> compiler could use near addressing.
> >
> > Er, in C, indexing is just syntactic sugar for pointer arithmetics.
> 
> No, it isn't. Indexing retains more information that the compiler
> can exploit.
>
> On machines with a linear flat address space, the two idioms are
> indeed roughly equivalent, but on segmented architectures, there
> /is/ a difference unless you implement all pointers in a
> base-plus-offset format - which is exactly what the C compilers
> for x86 processors tried to avoid due to efficiency concerns.

However, by returning to base-plus-offset with base being a handle
into a system table, it is possible to implement range checking
and general pointer safety even in the C language.  I believe the
technique is used in the DeathStation 9000.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Joachim Durchholz" <joachim.durchholz@web.de> wrote:
> Tak To wrote:
> > Joachim Durchholz wrote:
> > JD> MS never added a compatibility mode that would have allowed us to
> > JD> compile, say, grep and company.
> >
> > What happened when you compiled the source code of grep with MSC?
>
> It wouldn't compile because header files were in different places, were
> named slightly differently, or defined things in slightly different ways.
> Once that was out of the way, it wouldn't link because a couple of
> routines was missing, one of them usually fork() or one of the exec*()
> functions (having no fork() was the worst single problem, but even with
> that it would have been difficult).

fork() is not part of the C language.  DOS didn't even
have the notion of processes.


> Even if you got that working, the programs usually wouldn't work:
> directory separators are \ instead of / (for no good reason at all),

I thought that was from pre-Microsoft DOS?


> Each single difference is small, but
> in summary, it's enough to seriously discourage any attempt at porting
> the tools. The total binary size of a Posix emulation on Windows is
> currently at 949KB and still increasing (it's the cygwin1 dll, and its
> size has a reason).

> Given that the majority of these differences serves no technical
> purpose, I can imagine only two reasons: laziness, and intentional
> lock-in strategies. I leave it to you to decide which reason should be
> considered worse.

I don't think very many of those decisions were made when
DOS/Windows was considered to be in the same market as
Unix.  When they came up with NT to start competing with
Unix, I don't think they were in a position to use lock-in
strategies, as they were the ones trying to gain
marketshare.  Besides, the way various versions of Windows
differ from Unix is not systematically distinct from the
way operating systems tend to differ from one another.

Dan.

"FM" <dartdanfm@yahoo.com> wrote in message
news:NYhtb.95480$ri.14638619@twister.nyc.rr.com...
> "Joachim Durchholz" <joachim.durchholz@web.de> wrote:
> > Even if you got that working, the programs usually wouldn't work:
> > directory separators are \ instead of / (for no good reason at all),
>
> I thought that was from pre-Microsoft DOS?

Sort of. CP/M (from Digital Research) had no directories and used / as a
command-line option flag, so that character was not available as a separator
when Microsoft added directories to DOS.

M.

Joachim Durchholz wrote:

> Tak To wrote:
> 
>>
>> Joachim Durchholz wrote:
>> JD> You are giving Microsoft far too much credit.
>> JD> Microsoft has always pursued what's best for Microsoft, not what's 
>> best
>> JD> for the programmers. (Other companies have done likewise, but 
>> Microsoft
>> JD> combines lock-in strategies while mobilizing heaps of impunity to 
>> give
>> JD> lip service to openness and programmer productivity.)
>>
>> I think you are too cynical.
> 
> 
> No, you can't be cynical enough when it comes to judging the behaviour 
> of commercial enterprises. Create one yourself if you don't believe me 
> (I did - it wasn't successful, but it taught be a lot).
> 
>> JD> MS never added a compatibility mode that would have allowed us to
>> JD> compile, say, grep and company.
>>
>> What happened when you compiled the source code of grep with MSC?
> 
> 
> It wouldn't compile because header files were in different places, were 
> named slightly differently, or defined things in slightly different ways.

This is still a problem today.  I've found the Linux include hierarchy 
needlessly complex compared to what I've gotten used to on various DOS 
and Windows C and C++ compilers over the years, but then there's no 
standard saying that either is "right" so I can't complain too bitterly.

> Once that was out of the way, it wouldn't link because a couple of 
> routines was missing, one of them usually fork() or one of the exec*() 
> functions (having no fork() was the worst single problem, but even with 
> that it would have been difficult).

As already pointed out, this is a platform-specific difference.  Unix 
and its derivatives (including Linux) are inherently multi-process.  DOS 
never was.  Windows is, but the mechanism is very different... they 
chose to go with threads instead of using fork to clone a process.

> Even if you got that working, the programs usually wouldn't work: 
> directory separators are \ instead of / (for no good reason at all), or 
> other slight semantic differences. Each single difference is small, but 
> in summary, it's enough to seriously discourage any attempt at porting 
> the tools. The total binary size of a Posix emulation on Windows is 
> currently at 949KB and still increasing (it's the cygwin1 dll, and its 
> size has a reason).

The platforms are significantly different, so trying to get Windows to 
act like Unix is a non-trivial task.  Cygwin is hideous, but it's about 
the best thing going in that line.

But then if programs are written with an eye towards portability, cygwin 
is unnecessary, and undesirable.

> Given that the majority of these differences serves no technical 
> purpose, I can imagine only two reasons: laziness, and intentional 
> lock-in strategies. I leave it to you to decide which reason should be 
> considered worse.

Uh, no.  There were pre-existing factors that dictated some of the 
differences, and the platform-specific differences account for much of 
the rest.  DOS wasn't designed to be Unix-like, so the Unix-like APIs 
and extensions were not suitable for it.  Why would you ever implement 
fork() on a single-process system?

You Unix and Linux types like to toss around terms like lock-in and so 
on, and in /some/ cases you're 100% on the mark.  In lots of other cases 
you're just FUDing on a level Microsoft themselves would envy. 
Microsoft may well be the root of all evil, but even they are not as bad 
as some Linux people (in particular) would have us believe.

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Willem wrote:
<snip>
> 
> The problem is that in C it's perfectly legal to address an array outside
> of its boundaries.  So the compiler can *not* know the range of that
> pointer.

Accessing an element beyond the boundaries of an array is undefined 
behaviour at best, and certainly /not/ legal.  The fact that you can do 
it, and get results /you/ expect, is not relevant.

The number one software bug for many years was buffer overruns.  Surely 
this tells you how wrong your statement is.

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

On Sat, 15 Nov 2003 04:29:33 GMT, "FM" <dartdanfm@yahoo.com>
wrote:

> marketshare.  Besides, the way various versions of Windows
> differ from Unix is not systematically distinct from the
> way operating systems tend to differ from one another.

I missed the beginning of this thread but it does seem to be
focussed on portability with *nix. However MS did (at least 
for a while - c1995?, MSC v4?) issue a posix portability pack for

NT versions of MSC, and posix is a cross OS standard (OS/400,
OpenVMS, *nix etc) Unfortunately MS's posix wasn't complete but
it did provide many of the missing functions (and, ISTR, most of
the missing headers and include structure).

I don't know if they still provide a separate posix library?.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Alan Gauld wrote:
> I missed the beginning of this thread but it does seem to be focussed
> on portability with *nix. However MS did (at least for a while -
> c1995?, MSC v4?) issue a posix portability pack for NT versions of
> MSC, and posix is a cross OS standard (OS/400, OpenVMS, *nix etc)
> Unfortunately MS's posix wasn't complete but it did provide many of
> the missing functions (and, ISTR, most of the missing headers and
> include structure).
> 
> I don't know if they still provide a separate posix library?.

It's part of the normal API or C libraries now.
Unfortunately, it's still far from usable if you want to port stuff.
(Which is why cygwin is relevant at all.)

Regards,
Jo

Corey Murtagh wrote:
> But then if programs are written with an eye towards portability,
> cygwin is unnecessary, and undesirable.

That's simply wrong.
Sure, there's much code written that's needlessly nonportable. But there
are issues that no amount of goodwill on the side of the programmer will
cover - stuff like shared memory, privilege management, and the like.

Things are improving slowly. The portability issues now are more serious
(and have more of a technical justifiction) now than they had in the 80ies.

Still, I blame Microsoft for never caring about portability, neither in
DOS nor in their C products.
The only attempt at portability that they ever did was implementing
pipes in COMMAND.COM ("foo | bar" actually worked, it used a file to
buffer the pipe's contents).

Coming back to the original topic of this subthread: MS never cared
about what's good for programmers. They started to care only when
serious competitors arrived, the most relevant challenge being DR DOS.
All of a sudden, MS decided to add some things to DOS that had been
missing for years, such as moving the OS to high memory, serious support
for EMS/XMS, help texts for all programs.

>> Given that the majority of these differences serves no technical 
>> purpose, I can imagine only two reasons: laziness, and intentional
>>  lock-in strategies. I leave it to you to decide which reason
>> should be considered worse.
> 
> Uh, no.  There were pre-existing factors that dictated some of the 
> differences, and the platform-specific differences account for much
> of the rest.  DOS wasn't designed to be Unix-like, so the Unix-like
> APIs and extensions were not suitable for it.  Why would you ever
> implement fork() on a single-process system?

Agreed.
However, DOS deviated from its predecessors quite quickly: hierarchical
file systems, abandonment of the tiny memory model as the default,
dropping the original copy command in favor of their own COPY, etc. etc.
Actually, many of these deviations existed right from the beginning; the
entire process of dropping CP/M compatibility took about five years,
including marking the CP/M-compatible APIs as obsolete.
After that, there were ten years of stasis, both compatibility-wise and
ease-of-use-wise.

> You Unix and Linux types like to toss around terms like lock-in and
> so on, and in /some/ cases you're 100% on the mark.  In lots of other
> cases you're just FUDing on a level Microsoft themselves would envy.
> Microsoft may well be the root of all evil, but even they are not as
> bad as some Linux people (in particular) would have us believe.

Oh, we're dropping to the level of name calling.
Well, in that case I'm considering dropping out.

"You MS types" simply don't know how regular an API can be if it's not 
done by MS, that's all. I tended to disbelieve the quality of the 
difference myself - I have been done MS programming in the last decade.
Recently, I had the opportunity to do some platform-independent 
programming. Some things in the Linux world are just as brain-damaged as 
in the MS world - but if you really want to see the difference, simply 
take a look at the MS tree view and list view APIs, and compare them to 
the APIs for the equivalent controls in Qt, Tk, GTK+, or GDK (hope I got 
the TLAs right, I'm not really a "Linux type"). The Linux equivalents 
have their shortcomings, but the difference is that MS is 85% crap while 
the Linux stuff is 30% crap.
It's just that MS is unceasingly doing propaganda, and very few people 
know enough about both sides of the fence to do a realistic 
hype-to-reality comparison. (Oh, and Linuxers aren't all beneath 
distributing FUD, of course, but I don't think I'm one of them. Also, 
the Linux camp distributes less FUD than the MS camp, by orders of 
magnitude.)

-Jo

Corey wrote:
) The number one software bug for many years was buffer overruns.  Surely 
) this tells you how wrong your statement is.

That tells me how *right* my statement is.

If it were illegal to address an array outside of its boundaries, things
like buffer overruns would have never happened in the first place.

It's perfectly legal to access elements outside of an array.  The behaviour
is that you access memory which is outside of said array.  The fact that
it's undefined what that memory contains, and if it exists at all, doesn't
make it illegal to do so.


SaSW, Willem (at stack dot nl)
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem wrote:

> Corey wrote:
> ) The number one software bug for many years was buffer overruns.  Surely
> ) this tells you how wrong your statement is.
> 
> That tells me how *right* my statement is.

It tells me that you guys are using different definitions of "legal". :-)

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Tak To <takto@alum.mit.edu.-> wrote in message news:<OqydncPO5fdMBi6iRVn-ig@comcast.com>...

> Note that I said "interpreter language", not "interpreted
> language".  An interpreter language is one whose definition
> includes an interpreter (e.g., eval in Lisp).

EVAL is not the sign of an interpreter in Lisp.
Especially if EVAL is implemented by calling the
(usually incremental) compiler.

Conforming Common Lisp implementations can be
fully compiler-based. Some are.

FM wrote:

><snip> Besides, the way various versions of Windows
>differ from Unix is not systematically distinct from the
>way operating systems tend to differ from one another.
>
>  
>
I think the way MS has blended the OS and the GUI, and now seems to be 
creating more dependencies between the OS and applications (eg browsers) 
is a significant departure from how operating systems conventionally 
differ.  MS's is about market control at the expense of secure and 
reliable OS design.  MS wins by fortifying its control on the desktop, 
and users lose with continuously fragile and increasingly complex and 
bloated systems.

Of course, if they separated their GUI from their OS both would be 
easier to replace with substitutes--weakening MS's grip.

-- 
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

In article <3FB64207.70007@wide-open-west.com>, =?ISO-8859-1?Q?Thomas_Gagn=E9?= <tgagne@wide-open-west.com> wrote:

>I think the way MS has blended the OS and the GUI, and now seems to be 
>creating more dependencies between the OS and applications (eg browsers) 
>is a significant departure from how operating systems conventionally 
>differ.  MS's is about market control at the expense of secure and 
>reliable OS design.  MS wins by fortifying its control on the desktop, 
>and users lose with continuously fragile and increasingly complex and 
>bloated systems.
>
>Of course, if they separated their GUI from their OS both would be 
>easier to replace with substitutes--weakening MS's grip.

One might think that if an operating system departs from conventional 
styles, and subsequently achieves great success in the marketplace, 
open-minded individuals might wish to consider whether the conventional 
modes of operation might have some defects that are remedied by the 
non-conventional one.

Note that the OS is named "Windows" - obviously the GUI is central to 
its function.

Developers of Windows applications may feel glad that they can rely on a 
great deal of standard functionality.  For example, if you want to 
integrate a browser window in your application to provide a convenient 
informational interface, you know that a version of IE will be present.  
This is good - you don't have to worry about whether the browser is 
missing or replaced by some half-baked alternative.

- Gerry Quinn

In article <3FB50417.CDE7B2B6@Sonnack.com>
Programmer Dude  <Chris@Sonnack.com> writes:
>Gabriel suggests another tactic: don't use abstraction so much.
>It's find for truly abstract things (e.g. a stack), but most classes
>don't need to be written with inheritance in mind (Gabriel and others
>suggest a class heirarchy that *much* wider than it is deep).

I would generally agree with this.

The argument goes beyond "classes" in object-oriented languages,
too.  Indeed, it goes beyond programming entirely: it is just a
restatement of Occam's Razor, "entia non sunt multiplicanda praetor
necessitatem" -- "ideas should not be multiplied unnecessarily".

The arguments generally set in around the "unnecessary" part. :-)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

On Fri, 14 Nov 2003 00:30:20 -0500, Tak To <takto@alum.mit.edu.->
wrote:

>And I did not say it either.
>
>My comment was on the contrast of availability of "other tools" such
>as a debugger.  (When the language is designed to have an interpreter,
>it is easy to fit in a debugger.)
Haskell and SML/NJ are itnerpreted yet have no debuggers.
----------------------------
The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess.
----------------
Thaddeus L. Olczyk, PhD
Think twice, code once.

On Fri, 14 Nov 2003 12:34:53 +0100, Joachim Durchholz
<joachim.durchholz@web.de> wrote:

>Even if you got that working, the programs usually wouldn't work: 
>directory separators are \ instead of / (for no good reason at all)

 \foo is a path spec
 /foo is a command line option

-Steve

In article <s9vcrv0p9l1dvjevql5osktcmprcm122n3@4ax.com>,
TLOlczyk  <olczyk2002@yahoo.com> wrote:
(snip)
>Haskell and SML/NJ are itnerpreted yet have no debuggers.

Uh? I don't know about SML/NJ but, for Haskell, compilers like GHC
provide good enough profiling that you can go hunting space leaks and
other inefficiencies and suchlike, and there are some great debuggers.
I'm not sure what state Hood's in right now, but people seem to be
working on buddha AFAIK and Hat is pretty good. Maybe you should look
again, unless you have some unusually narrow view of what a debugger
is that you conveniently failed to mention.

<troll>And, maybe, with static typing, there's less need for runtime
debugging anyway? (-:</troll>

TBH, with an interpreted environment where, as is usual in Haskell,
your code is broken into lots of little functions, I often find it
more than enough to just be able to interactively invoke a variety of
those little functions to see what's really going on ("deriving Show"
helps a lot). I guess that's related to unit testing.

(comp.object trimmed from followups)

-- Mark

Gerry Quinn wrote:
> 
> One might think that if an operating system departs from conventional 
> styles, and subsequently achieves great success in the marketplace, 
> open-minded individuals might wish to consider whether the conventional 
> modes of operation might have some defects that are remedied by the 
> non-conventional one.

You're talking about what's good for the end user.
I have been talking about what's good for the programmer.
The two converge when it comes to long-term reliability, but it's not a 
quality that's easily recognized by end users, so it didn't play the 
role in end-user decisions that it should have.

> Note that the OS is named "Windows" - obviously the GUI is central to 
> its function.

It shouldn't be.

> Developers of Windows applications may feel glad that they can rely on a 
> great deal of standard functionality.  For example, if you want to 
> integrate a browser window in your application to provide a convenient 
> informational interface, you know that a version of IE will be present.  
> This is good - you don't have to worry about whether the browser is 
> missing or replaced by some half-baked alternative.

I have programmed in Windows, and I have actually actively considered 
including the Internet Explorer as a control in an application.
I (and, actually, the rest of the team as well) decided to scrap the 
idea. We didn't have control of the IE version that would be present on 
the end users' machines; we could have forced an IE upgrade on the 
users, but we didn't know in what ways future versions of IE might offer 
different, incompatible functionality.
We opted for a lean-and-mean HTML display engine that we could use in 
our tests, and that didn't come with a ton of baggage that we didn't need.

Regards,
Jo

"Joachim Durchholz" <joachim.durchholz@web.de> wrote in message
news:bp640j$3no$1@news.oberberg.net...
> > Note that the OS is named "Windows" - obviously the GUI is central to
> > its function.
>
> It shouldn't be.

Why shouldn't it be? Developers wanted it. Users wanted it. Competitors were
doing it. Nostalgia is not a sufficient reason to exclude features from an
OS.

M.

TLOlczyk <olczyk2002@yahoo.com> writes:

> Haskell and SML/NJ are itnerpreted yet have no debuggers.
Wrong, wrong, and (used to be) wrong.

FM wrote:
FM> [C++] supports all common forms of polymorphism (runtime,
FM> parametric, and ad hoc) and has a functional, albeit
FM> highly broken, macro system. [...]
FM> There are a lot of special syntactic and semantic rules
FM> that exist in order to support those features.  As
FM> opposed to, say, Scheme, which is highly extensible
FM> without nearly as much complexity.

As an aside: I view the different polymorphisms as rather
distinct animals sharing only the name (and a misleading one too).
Hence I don't mind them having disparate syntaxes.

TT> I tend to think of C/C++ as highly "tunable" languages, second
TT> perhaps only to assemblers.  The tunability allows the
TT> programmers to specify many aspects of the program in great
TT> details.  It is what gives the complexity

FM> No, C is just as tunable, but is nowhere near as complex as
FM> C++.  C++ is complex because it is essentially a combination
FM> of C and a whole bunch of features allowing the language to
FM> be extended in various ways, while still allowing what was
FM> possible in C.

You have made a point -- it is not particularly meaningful to
compare tunability of languages that have disparate feature space.
So let me rephrase.  For languages that off limited support for
user defined types (or ADT, or classes, etc), C is more tunable
than, say, Pascal.  For languages that support user defined types
extensively, C++ is more tunable than, say, Java.  (Assembler
languages, which have only one built-in type and no user defined
types, should be a group by themselves.)

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Robert STRANDH wrote:
RS> As someone else already pointed out, there is no requirement
RS> that eval in Lisp be implemented as an interpreter.

?? eval _is_ an interpreter.

RS> Indeed, there is at least one implementation that does not
RS> have an interpreter at all.

Does that implementation has an integrated IDE with debugger
etc?

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To wrote:
TT> As I said before, an interpreter comprises of a compiler
TT> that compiles one token at a time.

Richard Heathfield wrote:
RH> That isn't actually true. "Simply stated, a compiler is a
RH> program that reads a program written in one language - the
RH> /source/ language - and translates it into an equivalent program
RH> in another language - the /target/ language."
RH> (Dragon book: page 1.)
RH>
RH> "Instead of producing a target program as a translation, an
RH> interpreter performs the operations implied by the source program."
RH> (Dragon book: page 3.)
RH>
RH> Since the interpreter does not produce a translation of the source
RH> program in another language, it is not a compiler.

In order for an interpreter to carry out the intention of a
program, an interpreter must look up the semantics of each token.
This lookup process can be seen as a translation process.
For example, in order to interpret the expression sin 1,
the interpreter must map the token "sin" to a procedure that
calculates sine.

Anyways, I think we have digressed too far.  What I said originally
was that one should not compare interpreter languages and compiler
languages (in the context of what languages have better tools).

Tak
--
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To wrote:
TT> As I said before, an interpreter comprises of a compiler
TT> that compiles one token at a time.

L.J. Buitinck wrote:
LJ> shouldn't that be one expression at a time?

It depends.  Some interpreter always process one token at a time,
while others would process several tokens all at once at various
times.  However, one can view the latter situation as having a
"linking" phase.

Anyways, I think we have digressed too far.  What I said originally
was that one should not compare interpreter languages and compiler
languages (in the context of what languages have better tools).

Tak
-- 
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Joachim Durchholz wrote:
JD> MS never added a compatibility mode that would have allowed us to
JD> compile, say, grep and company.

Tak To wrote:
TT> What happened when you compiled the source code of grep with MSC?

JD> It wouldn't compile because header files were in different places, were
JD> named slightly differently, or defined things in slightly different ways.
JD> Once that was out of the way, it wouldn't link because a couple of
JD> routines was missing, one of them usually fork() or one of the exec*()
JD> functions (having no fork() was the worst single problem, but even with
JD> that it would have been difficult).
JD> Even if you got that working, the programs usually wouldn't work:
JD> directory separators are \ instead of / (for no good reason at all), or
JD> other slight semantic differences. Each single difference is small, but
JD> in summary, it's enough to seriously discourage any attempt at porting
JD> the tools.

Except for the header files (which is still debatable), these issues
have nothing to do with whether the MSC is "standard".

I took "compatible mode" to mean "ANSI C mode" -- or did you mean
"Unix compatible mode"?

Anyways, I thought we were discussing whether _near and _far were
more of the product of necessity due to hardware idiosyncracy or
the product of MS's strategy of deliberate incompatibility.

Tak
-- 
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To wrote:
TT> Let me understand this.  Are you opposed to __near as well?

Joachim Durchholz wrote:>
JD> Yes.
JD>
JD> There would have been more portable alternatives.

Of using 2 bytes instead of 4 bytes to hold a pointer? (To
minimize memory usage and faster code, for example.)  It seems that
we have different ideas as to what __near pointers are used for.

JD> For example, a pointer arithmetic that handled 64K bounds correctly.

FWIW, there are __huge pointers that does exactly what you want.

JD> And: Recommendations to work with indexing instead of pointer arithmetic
JD> when accessing arrays smaller than 64K, so that the compiler could use
JD> near addressing.

See above.

JD> And, in general, simply sticking with what was called the "huge
JD> memory  model",

And deprive the user a choice?  Not a plus in my book.

JD> offering library routines to interface with assembly language
JD> that used a different memory model.

And make things slower?

      -----     -----

TT> And what in your opinion should a compiler writer do if he thinks the
TT> language can benefit from an extension?

JD> He should ask the programmer community to see whether there's a better
JD> way than extending the language.
JD> Extending a language is the worst sin that a compiler writer can commit.

But it is a reasonable way for many programmers (including me).
Personally, I prefer MS's solution than what you have proposed.
It is not clear to me that yours is the majority opinion.

Tak
-- 
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Tak To <takto@alum.mit.edu.-> writes:
TT> [_near and _far] were replaced by __near and __far soon
TT> as the C committee reserved the leading double underscore symbols
TT> for compiler usage only.

FH> "soon as"?  That doesn't match my recollection.

TT> What was your recollection?

Thant Tessman wrote:
Th> Don't know about FH, but my recollection is that as late as MSVC++7.1
Th> their adherence to the C++ standard was infamously terrible.

Could be, but it does not mean it was the same situation back
when _near and _far (or __near and __far) were introduced.

Th> Even without underscores "near" and "far" were unavailable as variable
Th> names.

Are "near" and "far" reserved words or are they just defined in the
header files as __near and __far respectively?

Tak
-- 
----------------------------------------------------------------------
Tak To                                            takto@alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr

Rainer Joswig wrote:
RJ> EVAL is not the sign of an interpreter in Lisp.
RJ> Especially if EVAL is implemented by calling the
RJ> (usually incremental) compiler.

?? eval _is_ an interpreter.

Tak

Tak To wrote:

> Tak To wrote:
> TT> As I said before, an interpreter comprises of a compiler
> TT> that compiles one token at a time.
> 
> Richard Heathfield wrote:
> RH> That isn't actually true. "Simply stated, a compiler is a
> RH> program that reads a program written in one language - the
> RH> /source/ language - and translates it into an equivalent program
> RH> in another language - the /target/ language."
> RH> (Dragon book: page 1.)
> RH>
> RH> "Instead of producing a target program as a translation, an
> RH> interpreter performs the operations implied by the source program."
> RH> (Dragon book: page 3.)
> RH>
> RH> Since the interpreter does not produce a translation of the source
> RH> program in another language, it is not a compiler.
> 
> In order for an interpreter to carry out the intention of a
> program, an interpreter must look up the semantics of each token.

Yes, indeed.

> This lookup process can be seen as a translation process.

No, it is no more to be considered a translation than the process of reading 
one's native written language.

> For example, in order to interpret the expression sin 1,
> the interpreter must map the token "sin" to a procedure that
> calculates sine.

Yes, but this is not a translation in the computery sense - i.e. that the 
program is being converted from a source language to an object language.

> 
> Anyways, I think we have digressed too far.

Welcome to Usenet.

> What I said originally
> was that one should not compare interpreter languages and compiler
> languages (in the context of what languages have better tools).

It makes more sense to speak of interpreter-based implementations and 
compiler-based implementations than to speak of "interpreter languages and 
compiler languages".

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Tak To <takto@alum.mit.edu.-> wrote in message news:<C--dnRMDV6b7tyqiRVn-uw@comcast.com>...
> Rainer Joswig wrote:
> RJ> EVAL is not the sign of an interpreter in Lisp.
> RJ> Especially if EVAL is implemented by calling the
> RJ> (usually incremental) compiler.
> 
> ?? eval _is_ an interpreter.
> 
> Tak

Welcome to the real world.

No. In Lisp EVAL _is_ a function that takes code and executes
it. How it makes the code executable is not said and by which method
it does execute it is not said.

Usually there are two options:

- it is based on an interpreter
- it calls the compiler and then calls the resulting compiled code

The latter is conceptually something like this:

CL-USER 11 > (defun my-eval (code) (funcall (compile nil `(lambda () ,code))))
MY-EVAL

CL-USER 12 > (my-eval '(+ 1 2))
3

MY-EVAL does zero interpretation. COMPILE compiles the
code to direct machine code in this above used Lisp system.

Several Lisp systems are implementing EVAL similar to this.

An interpreter does something very different. It walks
over some code representation and executes the
statements it sees, etc.

Tak To <takto@alum.mit.edu.-> writes:

> Robert STRANDH wrote:
> RS> As someone else already pointed out, there is no requirement
> RS> that eval in Lisp be implemented as an interpreter.
> 
> ?? eval _is_ an interpreter.

What makes you think so? 

> RS> Indeed, there is at least one implementation that does not
> RS> have an interpreter at all.
> 
> Does that implementation has an integrated IDE with debugger
> etc?

Why is that important in determining whether Lisp is an "interpreter
language"?

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Tak To <takto@alum.mit.edu.-> writes:

> Tak To wrote:
> Anyways, I think we have digressed too far.  What I said originally
> was that one should not compare interpreter languages and compiler
> languages (in the context of what languages have better tools).

Actually, you also said that Lisp is an "interpreter language",
because you claim that "eval" is an interpreter, and thus that the
existence of an interpreter is part of the definition of Lisp.  

As I have already said, I believe it is very important for other
readers of comp.programming to understand that this is not true, at
least not with a widely-agreed-upon definition of interpreter.  I also
made it clear *why* I think that is important.  

In fact, I believe that it is important to understand that interpreter
or compiler is an implementation technique and that few, perhaps no,
languages would require an implementation to use an interpreter or a
compiler to achieve the effect of the language definition.  Certainly,
the definition of Lisp does not.  For that reason, I think claiming
that this or that *language* is "compiler" or "interpreter" is just
not useful, and indeed may be confusing to some people. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Sorry, I'm dropping out - this discussion is too far off-topic, and if 
you can't see my points without further argument, it would require me at 
least several more hours of writing posts to get my point across.

Regards,
Jo

"Tak To" <takto@alum.mit.edu.-> wrote in message <news:-oWdnZG9GMssnyqiRVn-iw@comcast.com>...

> You have made a point -- it is not particularly meaningful to
> compare tunability of languages that have disparate feature space.
> So let me rephrase.  For languages that off limited support for
> user defined types (or ADT, or classes, etc), C is more tunable
> than, say, Pascal.  For languages that support user defined types
> extensively, C++ is more tunable than, say, Java.  (Assembler
> languages, which have only one built-in type and no user defined
> types, should be a group by themselves.)

TASM?

 URL:http://mujweb.atlas.cz/www/komsbomb/article/progobj.htm

--
Joe Foster <mailto:jlfoster%40znet.com>     Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:L1stb.674$nm6.1723@news.indigo.ie>...

> Developers of Windows applications may feel glad that they can rely on a
> great deal of standard functionality.  For example, if you want to
> integrate a browser window in your application to provide a convenient
> informational interface, you know that a version of IE will be present.
> This is good - you don't have to worry about whether the browser is
> missing or replaced by some half-baked alternative.

The browser could always be zapped by some half-baked "service pack"
or botched successive version.  Also look at what happened to some
supposedly "standard functionality" in Winblows XP's OLE libraries.
THE LORD Billweh giveth, and THE LORD Billweh taketh away.

--
Joe Foster <mailto:jlfoster%40znet.com>   Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joachim Durchholz" <joachim.durchholz@web.de> wrote in message <news:bp2ejo$n4a$1@news.oberberg.net>...

> Even if you got that working, the programs usually wouldn't work:
> directory separators are \ instead of / (for no good reason at all), or

CP/M used "/" for command-line options, so QDOS^H^H^H^HMS-DOS
could either maintain compatibility with CP/M or ape UNIX, but
not both.  I vaguely recall a utility which could replace the
meanings of "\" and "/" in DOS with "/" and "-", respectively,
but it didn't work with everything, and it may have just been
a VP/ix thing.

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Willem" <willem@stack.nl> wrote in message <news:slrnbrc9k0.2594.willem@toad.stack.nl>...

> Corey wrote:
> ) The number one software bug for many years was buffer overruns.  Surely
> ) this tells you how wrong your statement is.
>
> That tells me how *right* my statement is.
>
> If it were illegal to address an array outside of its boundaries, things
> like buffer overruns would have never happened in the first place.
>
> It's perfectly legal to access elements outside of an array.  The behaviour
> is that you access memory which is outside of said array.  The fact that
> it's undefined what that memory contains, and if it exists at all, doesn't
> make it illegal to do so.

Where's a DeathStation 9000 when you need one?!

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Tak To wrote:
> 
.... snip ...
> 
> Except for the header files (which is still debatable), these issues
> have nothing to do with whether the MSC is "standard".
> 
> I took "compatible mode" to mean "ANSI C mode" -- or did you mean
> "Unix compatible mode"?
> 
> Anyways, I thought we were discussing whether _near and _far were
> more of the product of necessity due to hardware idiosyncracy or
> the product of MS's strategy of deliberate incompatibility.

Much as I hate to miss any opportunity to bash MS, the use of near
and far (with or without underscores) predates Microsoft
graduation to largest overgrown bully.  I believe it first appears
in the assembly language for the 8086 processor, from Intel.  That
would make it somewhere around 1978, and roughly contemporary with
K&R 1.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In article <slrnbrc9k0.2594.willem@toad.stack.nl>,
Willem  <willem@stack.nl> wrote:
>Corey wrote:
>) The number one software bug for many years was buffer overruns.  Surely 
>) this tells you how wrong your statement is.
>
>That tells me how *right* my statement is.
>
>If it were illegal to address an array outside of its boundaries, things
>like buffer overruns would have never happened in the first place.
>
>It's perfectly legal to access elements outside of an array.  The behaviour
>is that you access memory which is outside of said array.  The fact that
>it's undefined what that memory contains, and if it exists at all, doesn't
>make it illegal to do so.

This reminds me of a quote:

    "Someone once told me it's illegal to carry the ball around
    the court in basketball [i.e., to walk or run without bouncing
    the ball on the ground -- `dribbling'].  Well, I tried it
    last night, and it worked fine.  I did not get arrested.
    Whoever told me that must be an idiot!"

It is sadly true that people -- programmers and users alike --
appear to be more interested in having buggy code produce the wrong
result as fast as possible, than they are in detecting the problem.
In this case, it means that, e.g., nobody wants to run bounds-checking-gcc
binaries as their regular execution environment for C code.
Bounds-checking-gcc will trap out-of-bounds array accesses at
runtime, at a small performance cost -- say, anywhere from 30% to
200% slower (1.3x to 3x as long to run programs).

This, incidentally, ties back into the __near and __far goop.
Those old C compilers that had __near and __far, and indeed had
compiler models at all, instead of just having the compiler compile
everything the best it could in what amounted to "huge model" all
the time.  Why?  Because it was important to get the wrong answer
as fast as possible. :-)

(Admittedly, it also enables one to get the right answer faster,
*if* one puts in quite a bit of work.  But the emphasis was put on
"SPEED AT ALL COSTS": instead of providing just a single extension
like __near, and allowing programmers to tweak code with it once
the program worked and once they were sure it was OK to do so, the
*default* was to run the lawnmower with the blade fully exposed at
all times.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

In article <6w65hkiak4.fsf@serveur4.labri.fr>,
Robert STRANDH  <strandh@labri.fr> wrote:
>In fact, I believe that it is important to understand that interpreter
>or compiler is an implementation technique and that few, perhaps no,
>languages would require an implementation to use an interpreter or a
>compiler to achieve the effect of the language definition.  Certainly,
>the definition of Lisp does not.  For that reason, I think claiming
>that this or that *language* is "compiler" or "interpreter" is just
>not useful, and indeed may be confusing to some people. 

Probably so.  On the other hand, one can describe particular
languages or language-features as being "targeted towards"
interpretation or compilation.

In particular, early binding of names, types, and so on are
"compilation targets", while late binding and an "eval" function
are "interpretation targets".  Languages like Fortran, Ada, and
C++ are clearly targeted towards compilation, while languages like
awk and perl are targeted towards interpretation.  Languages with
a mix of the two (e.g., Common Lisp with its kitchen-sink approach)
are not really targeted towards either type of implementation.
A few oddballs, like APL, are just off in the weeds. :-)

(Actually I think we need more programmers exposed to more languages
like APL, as well as Lisp and ML and Prolog and Ada and C and
machine-level instruction sets and even low-level hardware details
like gates and funnel-shifters and TLBs.  There is danger in learning
too many details about one particular approach, without learning
other approaches.  I never did any serious APL programming [nor
any J at all], but it always struck me as odd that the high-energy
physics lab folks were writing Fortran code using BLAS and LINPACK
instead of just writing in APL.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

Tak To wrote:

> Are "near" and "far" reserved words or are they just defined in the
> header files as __near and __far respectively?

I don't care about near and far per se.

It is blindingly obvious that compatibility with industry standards has 
never been a high priority for Microsoft. More than that, Microsoft 
seems to deliberately avoid--as much as the market will allow--making 
developers' lives easier in any way that might favor their competition 
at their expense. I'm not a free software nut. I don't consider this 
somehow criminal, or unique to Microsoft. It is, however, foolish to 
pretend either that this isn't true, or that it isn't something 
developers should take into consideration.

-thant

Chris Torek <nospam@elf.eng.bsdi.com> writes:

> In article <6w65hkiak4.fsf@serveur4.labri.fr>,
> 
> Probably so.  On the other hand, one can describe particular
> languages or language-features as being "targeted towards"
> interpretation or compilation.

I am sure some language designers have an implementation in mind when
they design their language.  Most good ones probably do, because they
do not want a feature to be hard to generate fast code for. 

> In particular, early binding of names, types, and so on are
> "compilation targets", while late binding and an "eval" function
> are "interpretation targets".  Languages like Fortran, Ada, and
> C++ are clearly targeted towards compilation, while languages like
> awk and perl are targeted towards interpretation.  Languages with
> a mix of the two (e.g., Common Lisp with its kitchen-sink approach)
> are not really targeted towards either type of implementation.
> A few oddballs, like APL, are just off in the weeds. :-)

I know what you are saying, but I don't think "compilation" and
"interpretation" is the right terminology here.  Many people think
that (though I know that is not your case) "compilation" means
translating the entire program to some executable code before starting
the execution.  This view excludes any incremental compilation
technique.  People with that view will think more dynamic languages,
e.g., languages that allow redefinition of classes and functions at
runtime such as Common Lisp, cannot be implemented using a compiler.
Their reasoning further goes that if they cannot be implemented using
a compiler, they must be implemented using an interpreter, and since
we know that interpreters are intrinsically slower than compilers
these languages must be intrinsically slow.  

Perhaps a better terminology would be "batch" and "interactive".  A
"batch" language would be one where the compiler (and linker) must (or
at least is allowed to) look at large chunks of the code, perhaps the
entire program, before the execution of the program can start [I am
improvising this definition; it almost certainly has some fundamental
flaw], whereas an "interactive" language allows the code to be
presented to the system in smaller chunks, allows definitions of
variables, functions, and classes to be redefined interactively, and
allows the program to be executed before it is completely written.

When a "batch" language is implemented using a compiler, it guarantees
that the compiler need not be present at runtime.  This feature allows
a "batch" language to have a relatively "simple" implementation.  A
batch language could be implemented using an interpreter for
portability, but such an implementation would be relatively slow (and
for no good reason).

An "interactive" language needs either an interpreter or an
incremental compiler, capable of translating smaller chunks of code (a
function, an expression, or a statement), since the user cannot wait
between each interaction for the compiler and linker to look at the
entire code.  An interpreter is a lot simpler to write, so it would be
easier to implement an interactive language using an interpreter.
Some designers of interactive languages are so convinced that it has
to be interpreted that they include features that are intrinsically
hard to compile into efficient code, which is too bad because such
features essentially makes it impossible to ever produce an efficient
implementation. 

In the specific case of Common Lisp, the standards committee made sure
not to include features that might prevent it from being implemented
using a compiler.  It is particularly interesting to read the book
"The Art of the Meta-Object Protocol" concerning the implementation of
the Common Lisp Object System, which is a wonderful exercise in
allowing as much interactivity as possible without sacrificing the
possibility of efficient compilation. 

> (Actually I think we need more programmers exposed to more languages
> like APL, as well as Lisp and ML and Prolog and Ada and C and
> machine-level instruction sets and even low-level hardware details
> like gates and funnel-shifters and TLBs.  There is danger in learning
> too many details about one particular approach, without learning
> other approaches.  I never did any serious APL programming [nor
> any J at all], but it always struck me as odd that the high-energy
> physics lab folks were writing Fortran code using BLAS and LINPACK
> instead of just writing in APL.)

I can't agree more.  APL seems to be a perfect match for machines with
vector instructions.  Instead, they were using parallelizing Fortran
compilers for these machines.

Many of the religious wars about programming languages have their roots
in ignorance.  Compounded with some strong psychological phenomena
(see http://dept-info.labri.fr/~strandh/Essays/psychology.html) this
ignorance is largely responsible for the sad state of our software
industry. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Calum wrote:

> NFish wrote:
> 
>> Programmer Dude wrote:
>>
>>> Muzzlebreak wrote:
>>>
>>>
>>>> Personally, though, I think C has the one-up on all languages
>>>> because it itself is very small and is independant of libraries.
>>>
>>>
>>>
>>>
>>> Yet dependant upon them to do anything useful! (like I/O)
>>>
>>> There is a theory that programmers tend to prefer smaller languages
>>> because they can be retained mentally better.  I mentioned Richard
>>> Gabriel's book, PATTERNS OF SOFTWARE (see elsethread).  He wrote
>>> something I'd thought to start a thread with, but perhaps it fits
>>> here better.  He is speaking about abstractions (something most
>>> programmers hold up as entirely desireable--but some disagree):
>>>
>>>     Abstractions must be carefully and expertly designed,
>>>     especially when reuse or compression[1] is intended.
>>>     However, because abstractions are designed in a partic-
>>>     ular context and for a particular purpose, it is hard
>>>     to design them while anticipating all purposes and
>>>     forgetting all purposes, which is the hallmark of the
>>>     well designed abstractions.
>>>
>>>     This implies that abstractions are best designed by experts.
>>>     Worse, average programmers are not well-equipped to design
>>>     abstractions that have universal usage,...
>>
>>
>>
>> [...]
>>
>> To compensate for the average programmer's poor ability to anticipate 
>> and forget all purposes, the language should provide powerful tools 
>> for extending and modifying others' abstractions, ideally without 
>> needing their source code so as not to kill portability.
>>
>> Unfortunately, the current fashionable languages are more interested 
>> in preventing changes of abstractions than encouraging them.  The 
>> "client programmer is the enemy" mentality is very foreign to me.
> 
> 
> Most programming is team-work.  We all need protecting from our bosses 
> who still think they can code, and juniors who are learning on the job...
> 
> Bullet-proofing your code is actually a help to the client programmer. 
> Of course they will make mistakes and invalid assumptions, that is what 
> programming is all about.  It's far better for the compiler to tell them 
> what shouldn't be done, than for them to go running to you with a "bug".

You make a great case for warning messages, but not the fatal error 
messages that the compilers emit.

> 
> A language without compile-time protection mechanisms is more vulnerable 
> to accidental abuse by client programmers.

This is true, but the protection should be advisory rather than 
absolute.  On the flip side, languages that don't support cleanly 
extending abstractions often force client programmers to intentionally 
abuse them.

"Robert STRANDH" <strandh@labri.fr> wrote in message <news:6whe13mt7m.fsf@serveur4.labri.fr>...

> I can't agree more.  APL seems to be a perfect match for machines with
> vector instructions.  Instead, they were using parallelizing Fortran
> compilers for these machines.

How much of this is due to "learning curve" issues?  Also, existing
Fortran code would presumably still work with the parallelizing
compilers even before tweaking the code to take advantage of the
parallelization features, so only the critical loops need to be
rewritten.  Meanwhile, converting to APL means a complete re-write!
Think of it as boiling a frog -- if the temperature/difficulty
gradient is too steep, the frog jumps out.

> Many of the religious wars about programming languages have their roots
> in ignorance.  Compounded with some strong psychological phenomena
> (see http://dept-info.labri.fr/~strandh/Essays/psychology.html) this
> ignorance is largely responsible for the sad state of our software
> industry.

The mathematics professors who loved learning mathematics but hated
learning word processors probably viewed an hour spent learning the
word processor as an hour wasted by not learning more mathematics!

I wonder which language Strandh is talking about in the second to
last paragraph.  A lot can happen with a language in ten years.
Did it just need some time to marinate?

 URL:http://joelonsoftware.com/articles/fog0000000017.html

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> writes:

> "Robert STRANDH" <strandh@labri.fr> wrote in message <news:6whe13mt7m.fsf@serveur4.labri.fr>...
> 
> > I can't agree more.  APL seems to be a perfect match for machines with
> > vector instructions.  Instead, they were using parallelizing Fortran
> > compilers for these machines.
> 
> How much of this is due to "learning curve" issues?  

In this particular case, I do not know, but my experience is that
people overestimate the importance of these issues.  In fact, it is
rare that anyone even takes the time to make a rough risk analysis,
i.e., the estimate of potential loss and potential gain.  Take a
simple example: many of my students stick to a very small subset of
very basic Emacs commands.  Observing some random student during a
three hour session on the computer, I estimate conservatively that
more than half an hour was wasted due to unnecessary typing.
Estimating conservatively again that a random student spend 12h per
week typing, this amounts to a waste of 2h per week, or around a full
week of work per year.  I seriously doubt that it would take more than
a total of a full-time week to learn enough Emacs to save a week per
year.  Thus, the investment pays off in less than a year.  Yet, few
people even bother making such an estimate.  

> Also, existing
> Fortran code would presumably still work with the parallelizing
> compilers even before tweaking the code to take advantage of the
> parallelization features, so only the critical loops need to be
> rewritten.  

Yes.  

> Meanwhile, converting to APL means a complete re-write!
> Think of it as boiling a frog -- if the temperature/difficulty
> gradient is too steep, the frog jumps out.

Re-writing existing code is no doubt too expensive, but new code could
be written in a better language.  The usual objection is that it is
disadvantageous to have code in several different languages, but
again, nobody seems to bother estimating this disadvantage compared to
the benefit of using a more productive language for new code.  

Also, old code could be gradually converted to something better as
part of the normal maintenance process.  This requires the possibility
of mixing different languages in an application, but that is usually
possible. 

> > Many of the religious wars about programming languages have their roots
> > in ignorance.  Compounded with some strong psychological phenomena
> > (see http://dept-info.labri.fr/~strandh/Essays/psychology.html) this
> > ignorance is largely responsible for the sad state of our software
> > industry.
> 
> The mathematics professors who loved learning mathematics but hated
> learning word processors probably viewed an hour spent learning the
> word processor as an hour wasted by not learning more mathematics!

Right.  But the hour spent learning the word processor would free up
many more hours in the future that could be spent on mathematics.  

> I wonder which language Strandh is talking about in the second to
> last paragraph.  A lot can happen with a language in ten years.
> Did it just need some time to marinate?

The feature was CLOS (the Common Lisp Object System) and the language
was Common Lisp.  At the time, I was mainly a user of a different
programming language and found it psychologically convenient not to
have to learn Common Lisp.  My colleague "helped me out" by affirming
that CLOS was "not the answer".  When I finally decided to give it a
try, I realized I should have given it a try a long time ago.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Chris Torek wrote:
> 
.... snip ...
> 
> It is sadly true that people -- programmers and users alike --
> appear to be more interested in having buggy code produce the
> wrong result as fast as possible, than they are in detecting the
> problem. In this case, it means that, e.g., nobody wants to run
> bounds-checking-gcc binaries as their regular execution
> environment for C code. Bounds-checking-gcc will trap
> out-of-bounds array accesses at runtime, at a small performance
> cost -- say, anywhere from 30% to 200% slower (1.3x to 3x as
> long to run programs).

This is what "info gcc invok" and s/bounds-check brings up:

`-fbounds-check'
     For front-ends that support it, generate additional code to
check
     that indices used to access arrays are within the declared
range.
     This is currenly only supported by the Java and Fortran 77
     front-ends, where this option defaults to true and false
     respectively.

So, while I would love to have that added security, it doesn't
appear to be feasible for the C language.  Even gpc is only now
just beginning to implement bounds checking.

> 
> This, incidentally, ties back into the __near and __far goop.
> Those old C compilers that had __near and __far, and indeed had
> compiler models at all, instead of just having the compiler compile
> everything the best it could in what amounted to "huge model" all
> the time.  Why?  Because it was important to get the wrong answer
> as fast as possible. :-)
> 
> (Admittedly, it also enables one to get the right answer faster,
> *if* one puts in quite a bit of work.  But the emphasis was put on
> "SPEED AT ALL COSTS": instead of providing just a single extension
> like __near, and allowing programmers to tweak code with it once
> the program worked and once they were sure it was OK to do so, the
> *default* was to run the lawnmower with the blade fully exposed at
> all times.)

I don't believe proper range checking is even possible in the C
language, lacking the existence of a sub-range construct.  I can
conceive of methods (involving handles and offsets) that can
detect out of range indices and pointers, but that is only a
portion (but an important portion) of the range check problem.  As
a result I think your rant is better directed at the "always use C
for everything" or the "don't get in my way" attitudes.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

hs@heaven.nirvananet (Hartmann Schaffer) writes:

>In article <3fb3a396$1@news.unimelb.edu.au>,
>	Fergus Henderson <fjh@cs.mu.oz.au> writes:
>> ...
>> In the earlier versions of Microsoft's C compiler, plain "near" and "far"
>> without any underscores at all were keywords, and if I recall correctly,
>> there was no way to turn that behaviour off. 
>
>you probabaly could have circumvented it with the preprocessor:
>
>#define near
>#define far

No, that wouldn't have worked.  That would cause programs which used
"near" or "far" as ordinary identifiers to have syntax errors.
It would probably also cause syntax errors in Microsoft's header files.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Tak To <takto@alum.mit.edu.-> writes:

>Fergus Henderson wrote:
>FH> __near and __far would probably have been reasonable extensions,
>FH> but _near and _far violated the C standard.
>
>Tak To <takto@alum.mit.edu.-> writes:
>TT> Yes, and that was why they were replaced by __near and __far soon
>TT> as the C committee reserved the leading double underscore symbols
>TT> for compiler usage only.
>
>FH> "soon as"?  That doesn't match my recollection.
>
>What was your recollection?

My recollection is that it took many years.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Bruce Hoult wrote:

> In article <PeGdnX9c5sBJPS6iRVn-uA@comcast.com>,
>  Tak To <takto@alum.mit.edu.-> wrote:
> 
>> TT> Btw, Lisp and Smalltalk are interpretor languages while C++
>> TT> is a compiler language.
>> 
>> BH> That is NOT the case.  Lisp has been primarily a compiled
>> BH> language (and a very fast one) for the last 25+ years.
>> 
>> Once again I said _interpreter_ (sorry for the typo) vs _compiler_
>> languages, not _interpreted_ vs _compiled_.  Please read my reply
>> post to Robert Strandh.
>> 
>> BH> You should look at Guy Steele's papers from 1977 or so,
>> BH> showing how Scheme maps naturally and simply to very efficient
>> BH> machine code.
>> 
>> Be as it may, one still will not get fast code if one invokes
>> eval to execute dynamically created program segments all the time.
> 
> But one *doesn't*.  Using "eval" a lot is a sure sign of a Lisp
> beginner.  Many or most Lisp programs *never* use it, and such famous
> books as _On Lisp_ take pains to make it clear that when they talk about
> creating functions at runtime they are talking about *closures*, not
> "eval".

Verily: the Lispiest language I'ved used extensively (Pop11) has an
eval, and I used it in almost no code. (And it had no interpreter:
aside from the AlphaPop side-branch, all Pop11 implementations compiled
to native code, using an incremental compiler.)

One used "partial application" [freezing in argument values, later
used to implement full lexical scope] and properties [address-based
garbage-collected hash tables] a *lot*, but not `eval`.

-- 
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Tak To wrote:

> Robert STRANDH wrote:
> RS> As someone else already pointed out, there is no requirement
> RS> that eval in Lisp be implemented as an interpreter.
> 
> ?? eval _is_ an interpreter.
> 
> RS> Indeed, there is at least one implementation that does not
> RS> have an interpreter at all.
> 
> Does that implementation has an integrated IDE with debugger
> etc?

For arguable values of "IDE" and "debugger", Poplog Common Lisp has
no interpreter, and IDE, and a debugger.

Showing its age - after all the system's been around for fifteen
years with Common Lisp as a sublanguage - but it serves as a
counterexample.

[And it includes Pop11, Standard ML, and Prolog as core languages,
and a multi-method multiple-inheritance ObjectClass system.]

-- 
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Willem wrote:

> The problem is that in C it's perfectly legal to address an array outside
> of its boundaries. 

This is not true, and has been not true since at least the first C
standard.

You may compute (but not dereference) the address one element beyond
the last element of an array. Otherwise, indexing outside the bounds
of an array is not legal, as in, the behaviour is undefined, as in,
the C standard places no restrictions on the behaviour of your code.

-- 
Chris "demons fly out of my snout" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Thant Tessman wrote:
> I don't care about near and far per se.
> 
> It is blindingly obvious that [good points snipped]

Thanks for nicely summing up what I was trying to get across.

Regards,
Jo

On Sun, 16 Nov 2003 02:04:15 -0500, Tak To <takto@alum.mit.edu.->
wrote:
> Anyways, I think we have digressed too far.  What I said originally
> was that one should not compare interpreter languages and compiler
> languages (in the context of what languages have better tools).

A point that seems to have been missed is that there is no clear
split between the two categories.

For example there are C and C++ interpreters available for those
who want them (and are prepared to pay). And if you allow Jython
then there is at least one Java interpreter too. And there are
compilers for almost all so called interpreted languages.

The distinction is not clear cut and is a faitrly pointless basis
upon which to base language productivity comparisons. 

And  as has already been said programming productivity is a
matter of ever decreasing importance. In most projects nowadays
programming only takes up ~10% of the total time/budget. Much
better to focus productivity improvements on the bits that matter
- testing, design, deployment, training etc.

Alan G
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

>Chris Torek wrote:
>> ... In this case, it means that, e.g., nobody wants to run
>> bounds-checking-gcc [object code]

In article news:3FB8853F.2B8458F@yahoo.com
CBFalconer <cbfalconer@worldnet.att.net> writes:
>"info gcc invok" ... [says] `-fbounds-check' ... is currenly only
>supported by the Java and Fortran 77 front-ends ...
>
>So, while I would love to have that added security, it doesn't
>appear to be feasible for the C language.  Even gpc is only now
>just beginning to implement bounds checking.

Bounds-checking-gcc is a completely separate compiler from regular
gcc, and is built off an older branch of the compiler (2.7.x perhaps?
I have forgotten).  The -fbounds-check flag you are reading about
is integrated into current (3.x) release versions.

>I don't believe proper range checking is even possible in the C
>language, lacking the existence of a sub-range construct. ...

It is indeed not possible for integral types, but it *is* possible
for array and pointer arithmetic.  On typical hardware, it requires
co-operation from the runtime library -- in particular, malloc()
and company must conspire with the compiler to produce the
arena-bounding information to be stored with pointer values.

(Pointers themselves may be represented as <base, current, limit>
triples, or <descriptor, offset> pairs; or the system may use some
kind of hash techniques to find the base and descriptor values for
pointers as needed.  The latter is similar to the techniques used
in the Boehm "conservative garbage collector" for C.)

Note that bounds checking, including pointer range-checking, would
catch the "illegal" code mentioned elsethread, including buffer overruns.
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

In article <3FB7C585.4CF6CF40@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> wrote:
>Tak To wrote:
>> Anyways, I thought we were discussing whether _near and _far were
>> more of the product of necessity due to hardware idiosyncracy or
>> the product of MS's strategy of deliberate incompatibility.
>
>Much as I hate to miss any opportunity to bash MS, the use of near
>and far (with or without underscores) predates Microsoft
>graduation to largest overgrown bully.  I believe it first appears
>in the assembly language for the 8086 processor, from Intel.  That
>would make it somewhere around 1978, and roughly contemporary with
>K&R 1.

   Multics had them too, IIRC.  Packed pointers for storage
economy, at the expense of flexibility, and unpacked for
full power, even if they were twice as big.

        Regards.        Mel.

Richard Heathfield wrote:

> It tells me that you guys are using different definitions of "legal".

Yeah.  I think Willem's definition is: the compiler doesn't complain.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

On Sat, 15 Nov 2003 08:57:37 GMT, alan.gauld@btinternet.com (Alan
Gauld) wrote:

>On Sat, 15 Nov 2003 04:29:33 GMT, "FM" <dartdanfm@yahoo.com>
>wrote:
>
>> marketshare.  Besides, the way various versions of Windows
>> differ from Unix is not systematically distinct from the
>> way operating systems tend to differ from one another.
>
>I missed the beginning of this thread but it does seem to be
>focussed on portability with *nix. However MS did (at least 
>for a while - c1995?, MSC v4?) issue a posix portability pack for
>
>NT versions of MSC, and posix is a cross OS standard (OS/400,
>OpenVMS, *nix etc) Unfortunately MS's posix wasn't complete but
>it did provide many of the missing functions (and, ISTR, most of
>the missing headers and include structure).
>
>I don't know if they still provide a separate posix library?.
>
I'm not current, but they did supply what they called a "Posix
subsystem" which met the minimum requirements for FIPS, but not much
more. There are better attempts (Cygwin is one) but I don't know any
that are free for general use.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On 16 Nov 2003 17:08:05 -0700, Chris Torek <nospam@elf.eng.bsdi.com>
wrote:

>It is sadly true that people -- programmers and users alike --
>appear to be more interested in having buggy code produce the wrong
>result as fast as possible, than they are in detecting the problem.
>In this case, it means that, e.g., nobody wants to run bounds-checking-gcc
>binaries as their regular execution environment for C code.
>Bounds-checking-gcc will trap out-of-bounds array accesses at
>runtime, at a small performance cost -- say, anywhere from 30% to
>200% slower (1.3x to 3x as long to run programs).

When performance is a factor, those are not "small" costs.
>
>This, incidentally, ties back into the __near and __far goop.
>Those old C compilers that had __near and __far, and indeed had
>compiler models at all, instead of just having the compiler compile
>everything the best it could in what amounted to "huge model" all
>the time.  Why?  Because it was important to get the wrong answer
>as fast as possible. :-)

It was (and often still is) important to get the *right* answer as
fast as possible. It was also important to make the code fit in the
available memory.
>
>(Admittedly, it also enables one to get the right answer faster,
>*if* one puts in quite a bit of work.  But the emphasis was put on
>"SPEED AT ALL COSTS": instead of providing just a single extension
>like __near, and allowing programmers to tweak code with it once
>the program worked and once they were sure it was OK to do so, the
>*default* was to run the lawnmower with the blade fully exposed at
>all times.)
>-
The emphasis you describe, when it existed, was due to the programmer,
not the language or the compiler.

C is like that.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Chris Torek wrote:

> (Admittedly, it also enables one to get the right answer faster,
> *if* one puts in quite a bit of work.  But the emphasis was put on
> "SPEED AT ALL COSTS":

Do you think that, back then, perhaps it was viewed as a necessary
evil (due to processor speeds)?

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Chris Torek wrote:

> (Actually I think we need more programmers exposed to more languages
> like APL, as well as Lisp and ML and Prolog and Ada and C and
> machine-level instruction sets and even low-level hardware details
> like gates and funnel-shifters and TLBs. There is danger in learning
> too many details about one particular approach, without learning
> other approaches.

I agree completely.  To paraphrase your response Saturday to my
post about class heirarchies:

} The argument goes beyond {programming} languages, too.  Indeed, it
} goes beyond programming entirely: 

The more *different* ways of doing something (anything) one is exposed
to, the broader and deeper ones own understanding of life becomes.  I
think those with 'problem-solving' or 'engineering' minds can fall
into the trap of thinking there is *one* correct solution for any
given problem.

Usually, that is not the case.  (Even simple math problems often
have more than one equally valid answer.)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Chris Torek wrote:

>> (Gabriel and others suggest a class heirarchy that *much* wider
>> than it is deep).
> 
> I would generally agree with this.
> 
> The argument goes beyond "classes" in object-oriented languages,
> too.  Indeed, it goes beyond programming entirely: it is just a
> restatement of Occam's Razor, "entia non sunt multiplicanda praetor
> necessitatem" -- "ideas should not be multiplied unnecessarily".

Agreed.  When I read that part of Gabriel's paper, I recalled how
(long ago) I learned that 'wider-over-deeper' was better for my
directory structures, too.

WRT class heirarchies, Gabriel makes the point that inheritance
has the feature of "compression".  That is, of being context-
sensitive and of the whole being more than the sum of parts.

A class that inherits "references" (uses the context of) the
super class.  Thus, a programmer cannot know the sub-class without
referring to the super class.  One has to balance the "re-use"
(or, as Gabriel perfers, the compressive) elements with the extra
effort required to fully understand the full context.

Modern IDE tools help a lot, but I must say his paper really hit
a major chord with me.

> The arguments generally set in around the "unnecessary" part. :-)

Ah, yes!  (-:

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Robert STRANDH wrote:

> Perhaps a better terminology would be "batch" and "interactive".

Batch is good; not sure I like interactive, although I can't think
of anything better ("piecemeal"?).

> When a "batch" language is implemented using a compiler, it
> guarantees that the compiler need not be present at runtime.

Although a run-time engine might be required, yes?

> An interpreter is a lot simpler to write,

Why do you think so?  I've only written very simple compilers and
interpreters, but, IME, they were about equally complex.  Both
need to lex and parse; both need to emit *something*.  It almost
seems the interpreter could be harder, because you also need to
implement some form of RTE.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude wrote:
> Chris Torek wrote:
> 
> > (Admittedly, it also enables one to get the right answer faster,
> > *if* one puts in quite a bit of work.  But the emphasis was put
> > on "SPEED AT ALL COSTS":
> 
> Do you think that, back then, perhaps it was viewed as a necessary
> evil (due to processor speeds)?

I have yet to see a case where a wrong answer quickly arrived at
was more useful than a correct answer.  However, just to forestall
any nonsense, there are cases where a poorer approximation quickly
found is more useful than a more accurate value leisurely found.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

CBFalconer wrote:

>>> (Admittedly, it also enables one to get the right answer faster,
>>> *if* one puts in quite a bit of work.  But the emphasis was put
>>> on "SPEED AT ALL COSTS":
>>
>> Do you think that, back then, perhaps it was viewed as a necessary
>> evil (due to processor speeds)?
> 
> I have yet to see a case where a wrong answer quickly arrived at
> was more useful than a correct answer.

As true as that is, it doesn't much address the question.  (-:

> However, just to forestall any nonsense, there are cases where a
> poorer approximation quickly found is more useful than a more
> accurate value leisurely found.

"Incoming!!!!!!!!!!   Duck!!!!!!!!!!!!!!"

(IOW, yes, sometimes raw speed is a Good Idea!)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Joe "Nuke Me Xemu" Foster wrote:
> I vaguely recall a utility which could replace the
> meanings of "\" and "/" in DOS with "/" and "-", respectively,
> but it didn't work with everything, and it may have just been
> a VP/ix thing.

The path delimitor character of DOS was stored at
a well known memory location and could be patched to be
anything.  This is completely separated from the flag
prefix of the built-in commands.

Tak

Thant Tessman wrote:
 > It is blindingly obvious that compatibility with industry standards has
> never been a high priority for Microsoft. More than that, Microsoft 
> seems to deliberately avoid--as much as the market will allow--making 
> developers' lives easier in any way that might favor their competition 
> at their expense. I'm not a free software nut. I don't consider this 
> somehow criminal, or unique to Microsoft. It is, however, foolish to 
> pretend either that this isn't true, or that it isn't something 
> developers should take into consideration.

Whether Microsoft has the habit of deliberate incompatibility is
not the issue that I am concerned with in this thread; the issue is
whether the example of _near and _far is really supports the
above claim.

I have no intention of defending MS in general, and I think some of
their acts in the past were down right despicable. (E.g., they
sabotaged the entire DOS extender industry by announcing the
DPMI 1.0 spec, promising Window's compliance then failing to deliver
it.)  However, in the case of _near and _far I think MS is not guilty
of deliberate incompatibility.

Tak

Chris Torek <nospam@elf.eng.bsdi.com> wrote in 
news:bpal52$ble$1@elf.eng.bsdi.com:

>>Chris Torek wrote:
>>> ... In this case, it means that, e.g., nobody wants to run
>>> bounds-checking-gcc [object code]
> 
> In article news:3FB8853F.2B8458F@yahoo.com
> CBFalconer <cbfalconer@worldnet.att.net> writes:
>>"info gcc invok" ... [says] `-fbounds-check' ... is currenly only
>>supported by the Java and Fortran 77 front-ends ...
>>
>>So, while I would love to have that added security, it doesn't
>>appear to be feasible for the C language.  Even gpc is only now
>>just beginning to implement bounds checking.
> 

If you want decent bounds checking you should use a language that
implements bounds checking. While some C compilers may implement
bounds checking, the C language clearly does not.

The rule is very simple. Use the correct tool for the task at hand.
C is good for many uses. It is not the only, or even always the best
tool for every situation.

Jim Rogers

"Programmer Dude" <Chris@Sonnack.com> wrote:
> Robert STRANDH wrote:
>
> > Perhaps a better terminology would be "batch" and "interactive".
>
> Batch is good; not sure I like interactive, although I can't think
> of anything better ("piecemeal"?).
>
> > When a "batch" language is implemented using a compiler, it
> > guarantees that the compiler need not be present at runtime.
>
> Although a run-time engine might be required, yes?
>
> > An interpreter is a lot simpler to write,
>
> Why do you think so?  I've only written very simple compilers and
> interpreters, but, IME, they were about equally complex.  Both
> need to lex and parse; both need to emit *something*.  It almost
> seems the interpreter could be harder, because you also need to
> implement some form of RTE.

If the language in which the interpreter is written is of a
higher level than the language to be interpreted, you can
often get the RTE for almost free.  The same benefit applies
for compilers when the target language is of a a higher
level than the source language, but that rarely happens.

Dan.

Tak To <takto@alum.mit.edu.-> writes:
>in the case of _near and _far I think MS is not guilty
>of deliberate incompatibility.

I don't think the engineers at MS deliberately violated the standard.
But I do think that the managers at MS made quite deliberate decisions
about how much of their resources to put into standards conformance and
compatibility, and how much to put into other areas, and that these
decisions resulted quite predictably in incompatibilities and standard
violations in their products.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

"Robert STRANDH" <strandh@labri.fr> wrote in message <news:6wd6brml99.fsf@serveur4.labri.fr>...

> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> writes:
>
> > "Robert STRANDH" <strandh@labri.fr> wrote in message <news:6whe13mt7m.fsf@serveur4.labri.fr>...
> >
> > > I can't agree more.  APL seems to be a perfect match for machines with
> > > vector instructions.  Instead, they were using parallelizing Fortran
> > > compilers for these machines.
> >
> > How much of this is due to "learning curve" issues?
>
> In this particular case, I do not know, but my experience is that
> people overestimate the importance of these issues.  In fact, it is
> rare that anyone even takes the time to make a rough risk analysis,
> i.e., the estimate of potential loss and potential gain.  Take a
> simple example: many of my students stick to a very small subset of
> very basic Emacs commands.  Observing some random student during a
> three hour session on the computer, I estimate conservatively that
> more than half an hour was wasted due to unnecessary typing.
> Estimating conservatively again that a random student spend 12h per
> week typing, this amounts to a waste of 2h per week, or around a full
> week of work per year.  I seriously doubt that it would take more than
> a total of a full-time week to learn enough Emacs to save a week per
> year.  Thus, the investment pays off in less than a year.  Yet, few
> people even bother making such an estimate.

They're afraid of forgetting it all immediately after finals.  =)
(Now was that macro bound to ctrl-alt-shift-compose-home, or...)

> > Also, existing
> > Fortran code would presumably still work with the parallelizing
> > compilers even before tweaking the code to take advantage of the
> > parallelization features, so only the critical loops need to be
> > rewritten.
>
> Yes.
>
> > Meanwhile, converting to APL means a complete re-write!
> > Think of it as boiling a frog -- if the temperature/difficulty
> > gradient is too steep, the frog jumps out.
>
> Re-writing existing code is no doubt too expensive, but new code could
> be written in a better language.  The usual objection is that it is
> disadvantageous to have code in several different languages, but
> again, nobody seems to bother estimating this disadvantage compared to
> the benefit of using a more productive language for new code.
>
> Also, old code could be gradually converted to something better as
> part of the normal maintenance process.  This requires the possibility
> of mixing different languages in an application, but that is usually
> possible.

Here's the only thing I could find about calling Fortran from APL:

 URL:http://groups.google.com/groups?selm=393%40e-street.Morgan.COM

I dunno if there are versions of APL which can prevent their garbage
collectors from moving memory blocks around, to make interoperating
with "foreign" libraries easier.

> > > Many of the religious wars about programming languages have their roots
> > > in ignorance.  Compounded with some strong psychological phenomena
> > > (see http://dept-info.labri.fr/~strandh/Essays/psychology.html) this
> > > ignorance is largely responsible for the sad state of our software
> > > industry.
> >
> > The mathematics professors who loved learning mathematics but hated
> > learning word processors probably viewed an hour spent learning the
> > word processor as an hour wasted by not learning more mathematics!
>
> Right.  But the hour spent learning the word processor would free up
> many more hours in the future that could be spent on mathematics.

Perhaps he tried it and "bounced off"?  Something similar happened
to me when I tried a version of LISP for MS-DOS back around 1990.
However, I'm unafraid to admit it.  I did better with Turbo Prolog,
but the cut operator, required in order to keep things out of NP,
was just such a filthy hack...

> > I wonder which language Strandh is talking about in the second to
> > last paragraph.  A lot can happen with a language in ten years.
> > Did it just need some time to marinate?
>
> The feature was CLOS (the Common Lisp Object System) and the language
> was Common Lisp.  At the time, I was mainly a user of a different
> programming language and found it psychologically convenient not to
> have to learn Common Lisp.  My colleague "helped me out" by affirming
> that CLOS was "not the answer".  When I finally decided to give it a
> try, I realized I should have given it a try a long time ago.

What was "the question"?  So, now we have /three/ languages to
stitch together: dusty Fortran decks, APL, and now CLOS.  Holy
impedance mismatch, Batman!

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

In article <6wd6brml99.fsf@serveur4.labri.fr>, Robert STRANDH 
<strandh@labri.fr> wrote:
>In this particular case, I do not know, but my experience is that
>people overestimate the importance of these issues.  In fact, it is
>rare that anyone even takes the time to make a rough risk analysis,
>i.e., the estimate of potential loss and potential gain.  Take a
>simple example: many of my students stick to a very small subset of
>very basic Emacs commands.  Observing some random student during a
>three hour session on the computer, I estimate conservatively that
>more than half an hour was wasted due to unnecessary typing.
>Estimating conservatively again that a random student spend 12h per
>week typing, this amounts to a waste of 2h per week, or around a full
>week of work per year.  I seriously doubt that it would take more than
>a total of a full-time week to learn enough Emacs to save a week per
>year.  Thus, the investment pays off in less than a year.  Yet, few
>people even bother making such an estimate.  

The estimate is dubious, because you assume that the student is not 
thinking about the problem while he types.  Typing speed is or should be 
almost irrelevant to programmer productivity.

(Why don't your students use a proper GUI development environment 
anyway?)

- Gerry Quinn

"Tak To" <takto@alum.mit.edu.-> wrote in message
news:-ZCdnUE9ZPRfhSqiRVn-hg@comcast.com...
> Robert STRANDH wrote:
> RS> As someone else already pointed out, there is no requirement
> RS> that eval in Lisp be implemented as an interpreter.
>
> ?? eval _is_ an interpreter.

No it's not. You may call it an evaluator, but it's clearly not
an interpreter. For example, the Corman Lisp system (an
implementation of Common Lisp) compiles every form before
evaluating it, so nothing is ever interpreted withing that
system.

> RS> Indeed, there is at least one implementation that does not
> RS> have an interpreter at all.
>
> Does that implementation has an integrated IDE with debugger
> etc?

Corman Lisp does, but I'm not sure it's the one Robert was talking
about.

--
Matthieu Villeneuve

"Gerry Quinn" <gerryq@indigo.ie> wrote in message
news:6Pkub.1008$nm6.3657@news.indigo.ie...
> In article <6wd6brml99.fsf@serveur4.labri.fr>, Robert STRANDH
> <strandh@labri.fr> wrote:
> >In this particular case, I do not know, but my experience is that
> >people overestimate the importance of these issues.  In fact, it is
> >rare that anyone even takes the time to make a rough risk analysis,
> >i.e., the estimate of potential loss and potential gain.  Take a
> >simple example: many of my students stick to a very small subset of
> >very basic Emacs commands.  Observing some random student during a
> >three hour session on the computer, I estimate conservatively that
> >more than half an hour was wasted due to unnecessary typing.
> >Estimating conservatively again that a random student spend 12h per
> >week typing, this amounts to a waste of 2h per week, or around a full
> >week of work per year.  I seriously doubt that it would take more than
> >a total of a full-time week to learn enough Emacs to save a week per
> >year.  Thus, the investment pays off in less than a year.  Yet, few
> >people even bother making such an estimate.
>
> The estimate is dubious, because you assume that the student is not
> thinking about the problem while he types.  Typing speed is or should be
> almost irrelevant to programmer productivity.

Programmers don't spend all their time typing of course, thinking
is what takes most of the time. Robert mentioned an estimate of
12 hours per week typing, it sounds reasonable to me...

> (Why don't your students use a proper GUI development environment
> anyway?)

It looks like they do use a proper environment (Emacs).

--
Matthieu Villeneuve

Gerry Quinn wrote:
> 
.... snip ...
> 
> (Why don't your students use a proper GUI development
> environment anyway?)

I can hardly think of anything less conducive to writing source
code.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

FM wrote:

>> ...IME, [compilers and interpreters are] about equally complex.
>> Both need to lex and parse; both need to emit *something*.  It
>> almost seems the interpreter could be harder, because you also
>> need to implement some form of RTE.
> 
> If the language in which the interpreter is written is of a
> higher level than the language to be interpreted, you can
> often get the RTE for almost free.  The same benefit applies
> for compilers when the target language is of a a higher
> level than the source language, but that rarely happens.

I can see that.  But does that make an interpreter easier to write
than a compiler (for a given language)?

My experience in writing compiler/interpreters is limited to fairly
simple languages that don't permit forward reference, so interpreting
occurs within the parse tree--as does code emission in the matching
compiler version.  Both seemed, to me, equally complex/simple.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude wrote:

> FM wrote:
<snip>
>>If the language in which the interpreter is written is of a
>>higher level than the language to be interpreted, you can
>>often get the RTE for almost free.  The same benefit applies
>>for compilers when the target language is of a a higher
>>level than the source language, but that rarely happens.
> 
> I can see that.  But does that make an interpreter easier to write
> than a compiler (for a given language)?

That really depends on the complexity of the code generator.  You can 
quite easily increase the complexity of the compiler by simply adding an 
optimizer :)

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

CBFalconer wrote:

> Gerry Quinn wrote:
> 
> ... snip ...
> 
>>(Why don't your students use a proper GUI development
>>environment anyway?)
> 
> I can hardly think of anything less conducive to writing source
> code.

Whereas I can't imagine anything less conducive to writing source than 
having to wrestle with emacs.

For some people a nice GUI IDE is the best environment.  For others, vi 
and a compiler.  Hell, I used to write quick-n-nasty DOS programs using 
edlin and masm.

To each their own.  What works for you isn't necessarily going to work 
for the next guy.

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

"Programmer Dude" <Chris@Sonnack.com> wrote:
> FM wrote:
> >> ...IME, [compilers and interpreters are] about equally complex.
> >> Both need to lex and parse; both need to emit *something*.  It
> >> almost seems the interpreter could be harder, because you also
> >> need to implement some form of RTE.
> >
> > If the language in which the interpreter is written is of a
> > higher level than the language to be interpreted, you can
> > often get the RTE for almost free.  The same benefit applies
> > for compilers when the target language is of a a higher
> > level than the source language, but that rarely happens.
>
> I can see that.  But does that make an interpreter easier to write
> than a compiler (for a given language)?

That depends on what the given languages are.  There are
two languages involved in writing an interpreter and three
in writing a compiler.

> My experience in writing compiler/interpreters is limited to fairly
> simple languages that don't permit forward reference, so interpreting
> occurs within the parse tree--as does code emission in the matching
> compiler version.  Both seemed, to me, equally complex/simple.

Still, code emission is harder, because you need to
translate the structure into another structure, whereas
interpretation can more easily occur within preexisting
context (parse tree).  Then again, it really depends on
the languages involved.

Dan.

In article <3fba296f$0$10424$626a54ce@news.free.fr>, "Matthieu Villeneuve" <matthieu@nospam.matthieu-villeneuve.net> wrote:
>"Gerry Quinn" <gerryq@indigo.ie> wrote in message
>news:6Pkub.1008$nm6.3657@news.indigo.ie...
>> In article <6wd6brml99.fsf@serveur4.labri.fr>, Robert STRANDH
>> <strandh@labri.fr> wrote:
>> >Estimating conservatively again that a random student spend 12h per
>> >week typing, this amounts to a waste of 2h per week, or around a full
>> >week of work per year.  I seriously doubt that it would take more than
>> >a total of a full-time week to learn enough Emacs to save a week per
>> >year.  Thus, the investment pays off in less than a year.  Yet, few
>> >people even bother making such an estimate.
>>
>> The estimate is dubious, because you assume that the student is not
>> thinking about the problem while he types.  Typing speed is or should be
>> almost irrelevant to programmer productivity.
>
>Programmers don't spend all their time typing of course, thinking
>is what takes most of the time. Robert mentioned an estimate of
>12 hours per week typing, it sounds reasonable to me...

Sure, but his assumption was that no useful work other than typing was 
taking place while the programmers were typing.  Programmers spend 168 
hours a week breathing, and yet they manage to cope with other tasks 
simultaneously.

My guess is that time spent typing is not lost to software production.  
You're still thinking about the job at hand with quite a large part of 
your brain.

- Gerry Quinn

"Corey Murtagh" <emonk@slingshot.co.nz.no.uce> wrote in message
news:1069192595.568391@radsrv1.tranzpeer.net...
> CBFalconer wrote:
>
> > Gerry Quinn wrote:
> >
> > ... snip ...
> >
> >>(Why don't your students use a proper GUI development
> >>environment anyway?)
> >
> > I can hardly think of anything less conducive to writing source
> > code.
>
> Whereas I can't imagine anything less conducive to writing source
> than having to wrestle with emacs.

I don't see any reason for "wrestling" with Emacs than simply
not knowing Emacs, so that's just a question of learning...

> For some people a nice GUI IDE is the best environment.  For
> others, vi and a compiler.  Hell, I used to write quick-n-nasty
> DOS programs using edlin and masm.

I did that too, but that's grossly inefficient compared with Emacs.
Some IDEs may be close to Emacs' performance, but some clearly
aren't (like those that require you to use the mouse or cursor keys
for some tasks).

> To each their own.  What works for you isn't necessarily going
> to work for the next guy.

I don't agree with that, IMO it's just a matter of curiosity
and learning.


--
Matthieu Villeneuve

"Gerry Quinn" <gerryq@indigo.ie> wrote in message
news:CiHub.1132$nm6.4335@news.indigo.ie...
> In article <3fba296f$0$10424$626a54ce@news.free.fr>, "Matthieu Villeneuve"
<matthieu@nospam.matthieu-villeneuve.net> wrote:
> >Programmers don't spend all their time typing of course, thinking
> >is what takes most of the time. Robert mentioned an estimate of
> >12 hours per week typing, it sounds reasonable to me...
>
> Sure, but his assumption was that no useful work other than typing was
> taking place while the programmers were typing.  Programmers spend 168
> hours a week breathing, and yet they manage to cope with other tasks
> simultaneously.

Well, even if I spend 8 hours a day on my keyboard, I won't be
typing non stop for 8 hours, there will be a succession of short
sequences of typing and thinking. It doesn't seem to me that both
are done at exactly the same time, I would rather think of it as
in single processor multitasking, with time slicing. So if the
typing "slices" are shorter, it has a direct effect on development
time overall.

It could be interesting to get the point of view of psychologists
(or coginitive scientists or whatever) on that subject...


--
Matthieu Villeneuve

Matthieu Villeneuve wrote:

> I don't see any reason for "wrestling" with Emacs than simply
> not knowing Emacs, so that's just a question of learning...

I've tried at least three times to learn to use emacs, and bounced
each time.

Emacs's model of text-on-the-screen and mine are so dissimilar that
I just couldn't get into it. Call it "just a question of learning"
if you will; it was (and is) a real barrier.

Of course, I already had ved; it wasn't as though I was trying to
transfer from vi and had no access to eg buffers-as-objects and
a programming language for editor extension.

This was (mumble) fifteen years ago or so. Maybe emacs has grown
more user-friendly since then.

>> To each their own.  What works for you isn't necessarily going
>> to work for the next guy.
> 
> I don't agree with that, IMO it's just a matter of curiosity
> and learning.

People have different, and strong, tastes and abilities in music, 
sport, and partners; I don't see why that shouldn't extend to software
development environments, and see no need to cast aspersions on
either the people or the environments.

-- 
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

"Chris Dollin" <kers@hpl.hp.com> wrote in message <news:bpflta$3cj$1@murdoch.hpl.hp.com>...

> Of course, I already had ved; it wasn't as though I was trying to
> transfer from vi and had no access to eg buffers-as-objects and
> a programming language for editor extension.

Actually, vi does have a programming language, and it's Turing-complete.
Haven't you heard of the set of vi macros which can simulate a Universal
Turing Machine?  (Of course, there are those who argue that real Turing-
completeness is impossible without access to infinite memory storage...)

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

On Wed, 19 Nov 2003 11:41:41 +0100, "Matthieu Villeneuve"
<matthieu@nospam.matthieu-villeneuve.net> wrote:

>Well, even if I spend 8 hours a day on my keyboard, I won't be
>typing non stop for 8 hours, there will be a succession of short
>sequences of typing and thinking. It doesn't seem to me that both
>are done at exactly the same time, I would rather think of it as
>in single processor multitasking, with time slicing. So if the
>typing "slices" are shorter, it has a direct effect on development
>time overall.

That's not true for me, and I rather doubt that it's true for you.
Haven't you ever noticed an error, or thought of a better way to code
something, while typing?

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

CBFalconer wrote:

>> (Why don't your students use a proper GUI development
>> environment anyway?)
> 
> I can hardly think of anything less conducive to writing source
> code.

Didn't you once say you use multiple windows open on various
helpful things, though?

For my money, the multiple window thing *alone* commends a GUI.
Multiple, virtual desktops even better!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Corey Murtagh wrote:

>> But does that make an interpreter easier to write than a compiler
>> (for a given language)?
> 
> That really depends on the complexity of the code generator.  You
> can quite easily increase the complexity of the compiler by simply
> adding an optimizer :)

Ah, yes, there is that.  (Although, what about an optimizing
interpreter?)

I'll leave THAT sort of thing to the Real Compiler Experts.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

FM wrote:

>> But does that make an interpreter easier to write than a compiler
>> (for a given language)?
> 
> That depends on what the given languages are.

I can see that.  Seems a compiler is not *necessarily* intrinsically
more difficult then?  Accounts for my (low N) perception, though.

Peas Out.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

On Wed, 19 Nov 2003 11:56:06 +0000, Chris Dollin wrote:

> Matthieu Villeneuve wrote:
> 
>> I don't see any reason for "wrestling" with Emacs than simply
>> not knowing Emacs, so that's just a question of learning...
> 
> I've tried at least three times to learn to use emacs, and bounced
> each time.
> 
> Emacs's model of text-on-the-screen and mine are so dissimilar that
> I just couldn't get into it. Call it "just a question of learning"
> if you will; it was (and is) a real barrier.

I hope you will continue to use whatever editor you are most
productive with.

However, I'm quite interested in knowing what parts of the Emacs
"model" caused you problems. The basic model of Emacs is to start
typing. If you want to go up a line, you can press the up-arrow
key or a control-key equivalent. If you want to go down a line you
can press the down-arrow key, and so on. I'm not sure what could
be difficult about that.

From there you go to various key-combinations that perform various
tasks. It certainly requires an effort at memorization to learn that
Control-H followed by i brings up the comprehensive help system,
and that Control-X followed by a 2 splits a window in 2 pieces, but
I can't see how things like that could be considered difficult.

Programmer Dude wrote:
> CBFalconer wrote:
> 
> >> (Why don't your students use a proper GUI development
> >> environment anyway?)
> >
> > I can hardly think of anything less conducive to writing source
> > code.
> 
> Didn't you once say you use multiple windows open on various
> helpful things, though?
> 
> For my money, the multiple window thing *alone* commends a GUI.
> Multiple, virtual desktops even better!

Multiple windows, yes.  But what has that got to do with being
GUI?  GUI means, to me, icons, rodentia, menus, pictures, a
plethora of garish fonts, etc.  No, or deprecated, keyboard.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!