www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An interesting observation

reply BCS <ao pathlink.com> writes:
http://www.sysprog.net/quotcob.html

Historically, languages designed for other people to use have been bad: Cobol, 
PL/I, Pascal, Ada, C++.
The good languages have been those that were designed for their own creators: 
C, Perl, Smalltalk, Lisp. (Paul Graham)

can we add D to this list?
Nov 08 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
BCS wrote:

 
 http://www.sysprog.net/quotcob.html
 
 Historically, languages designed for other people to use have been bad: 
 Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)
 
 can we add D to this list?
 
 


I flatly disregard any quote which qualifies Perl as a "good language."

  - Gregor Richards
Nov 08 2007
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Gregor Richards wrote:

 BCS wrote:

 http://www.sysprog.net/quotcob.html

 Historically, languages designed for other people to use have been 
 bad: Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)

 can we add D to this list?


 
 I flatly disregard any quote which qualifies Perl as a "good language."
 
  - Gregor Richards


Same here.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 08 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
Bruno Medeiros Wrote:


 Gregor Richards wrote:

 BCS wrote:

 http://www.sysprog.net/quotcob.html

 Historically, languages designed for other people to use have been 
 bad: Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)

 can we add D to this list?


 
 I flatly disregard any quote which qualifies Perl as a "good language."
 
  - Gregor Richards


 
 Same here.
 
 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


Perl is a brilliant language when it's used as it was designed. For hacking out
quick scripts, Perl has a far better syntax than shell scripts (for any shell I
know of) and is portable. I even write my "makefiles" in Perl, since the syntax
is cleaner than Ant and more portable and flexible than Make, and almost all my
projects have inline Perl somewhere in them (including Descent; yes I'm
polluting the D world with my evil Perl-y ways).

On the other hand, last summer at my internship I was working with a legacy
Perl system of 1.5 million lines of Perl. They had some strict coding
standards, so the code wasn't entirely unreadable, but it was still pretty
ugly. And how Perl became the de-facto language of web development for so many
years I can't see.
Nov 08 2007
prev sibling parent reply Bedros Hanounik <2bedros NOSPAMgmail.com> writes:
did you guys ever had to work with TCL.  it causes brain damage just by reading
the code.


Gregor Richards Wrote:


 BCS wrote:

 
 http://www.sysprog.net/quotcob.html
 
 Historically, languages designed for other people to use have been bad: 
 Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)
 
 can we add D to this list?
 
 


 
 I flatly disregard any quote which qualifies Perl as a "good language."
 
   - Gregor Richards
Nov 08 2007
parent Bruce Adams <tortoise_74 yeah.woo.co.uk> writes:
Bedros Hanounik Wrote:


 did you guys ever had to work with TCL.  it causes brain damage just by
reading the code.
 


TCL has been my main scripting language for a long time. I find its syntax
simple and consistent its easy to embed and easily embedded. That's TCL 8.0 and
higher though. The old 4.X, before the byte compiler, was a bit horrid. I never
went near that. But even that is much cleaner than the typically hacked out
perl ever was. If java hadn't come out when it did we could be looking at
TCLlets instead of java applets. Scriptics (the sun spin off developing it)
becoming Ajuba (some sort of web service company) really didn't help.

Regards,

Bruce.
Nov 09 2007
prev sibling next sibling parent reply 0ffh <spam frankhirsch.net> writes:
BCS wrote:

 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)


I consent with Gregor and Bruno concerning Perl.


 can we add D to this list?


Piece of cake. Everyone shut up and let Walter do as he pleases... <g>

Regards, Frank
Nov 08 2007
parent "dominik" <aha aha.com> writes:
"0ffh" <spam frankhirsch.net> wrote in message 
news:fh0hp0$2cp1$1 digitalmars.com...

 Piece of cake. Everyone shut up and let Walter do as he pleases... <g>


ofcourse, but what scares the hell out of me personally is that we should 
have a backup for Walter! :)
He is Genius and all, but it scares me all of that hard work is on one man 
(and a few selected - sorry!). What if Walter one day decides he wants to 
make ice-cream instead of programming? Or something like that

Walter - institutionalize yourself! Please.
Nov 09 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 
 http://www.sysprog.net/quotcob.html
 
 Historically, languages designed for other people to use have been bad: 
 Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)
 
 can we add D to this list?


It's ironic that you mention that. My experience as a software engineer 
is that when I write a program that delivers what the marketing folks 
tell me people will buy, it fails. Whenever I wrote a program to please 
myself, it's been a big success. What's most interesting is that the 
latter is especially true when the marketing folks tell me that nobody 
would ever want the program I'm writing.

And yes, that applies to D, too. When I started on it, my friends and 
colleagues would all smile sadly and indulgently at my folly.

They said I should do a javascript compiler, because what the world 
needed was a fast javascript engine. So I built one, it ran twice as 
fast as jscript, and I couldn't give it away <g>.

Meanwhile, D took off.
Nov 08 2007
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 08 Nov 2007 19:36:30 -0800, Walter Bright wrote:

 They said I should do a javascript compiler, because what the world 
 needed was a fast javascript engine. So I built one, it ran twice as 
 fast as jscript, and I couldn't give it away <g>.
 
 Meanwhile, D took off.


I can add another anecdote to that. 

Recently I was asked by a major client to visit them so we could have a
face-to-face discussion about a project my company was developing for them.
So I went to interstate to the client's offices for a couple days, prepared
to get my behind figuratively beaten, because the project is nearing its
drop dead date but still with some apparently significant issues.

At the first meeting, which had the client's top technical people present,
they started describing the details of some changes to the specification.
They admitted that my company had delivered software which had accurately
implemented the previous specification, but after considerable testing they
decided that there was some omissions from the specification. 

I listened for a good ten minutes before I interrupted with the question
"what business decisions will this new specification affect?". After a
couple of stalled attempts, the technicians said that it wouldn't affect
any business process. In fact, it seems that quite a few aspects of the
existing specification (which had already been revised three times) were
also irrelevant to the people who would actually use the system.

It turned out that after some initial meetings with the business people,
the client's technicians formed the opinion that the system they had
proposed was too complex for the business people, so they stopped talking
to them. Instead, the technicians kept tweaking and adding to it (making it
even more complex) and resolved to go back and 'sell' the system to the
business people after it was implemented, and help retrain them how to do
their job.

At this point I called a halt to the meeting and demanded that we hear
directly from the business people themselves, who were the real domain
experts. In a few short hours, the managers could see that their
technicians had gotten it wrong and that their business people were not
happy. I spent the few days redrafting the client's specification along the
lines of what the business really wanted and could use. 

Fortunately, only a dozen or so of the three hundred plus programs needed
changing, but now we have a system that is easily understood and delivers
what the users wanted. It is not as sophisticated as the earlier
specification asked for, but that's why it better.

The moral of the story : the better programs are those that are truly
useful rather than those that deliver what engineers believe would be
useful, no matter how 'superior' those programs might be.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/11/2007 5:08:49 PM
Nov 08 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Derek Parnell wrote:

 [...]
 The moral of the story : the better programs are those that are truly
 useful rather than those that deliver what engineers believe would be
 useful, no matter how 'superior' those programs might be.


And I think the metamoral of the story is that programmers tend to 
overgeneralize because that makes problems more interesting and 
challenging and elegant, when most of the the time the generalizations 
aren't used.  Like the human brain, a good programming language is one 
that has a lot of specific tools that do their job well, rather than one 
big generic tool that looks like a hammer and expects everything to look 
like specializations of a nail.

The tendency to generalize is quite natural and is part of what makes a 
programmer a good thinker.  It's the ability to abstract away detail and 
find the commonality in a structure.  The problem is when it goes too 
far, and important details are sacrificed on the altar of elegance, 
which turns out to be an illusion anyway.

This is why academic languages tend to not be successful.  They are good 
at being elegant, but not so good at being useful.  You rarely use 
pieces of art to dig a ditch or frame a house, because most of it 
couldn't stand up to the work.

Dave
Nov 09 2007
prev sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 BCS wrote:
 

 http://www.sysprog.net/quotcob.html

 Historically, languages designed for other people to use have been 
 bad: Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)

 can we add D to this list?


 
 
 It's ironic that you mention that. My experience as a software engineer 
 is that when I write a program that delivers what the marketing folks 
 tell me people will buy, it fails. Whenever I wrote a program to please 
 myself, it's been a big success. What's most interesting is that the 
 latter is especially true when the marketing folks tell me that nobody 
 would ever want the program I'm writing.
 
 And yes, that applies to D, too. When I started on it, my friends and 
 colleagues would all smile sadly and indulgently at my folly.
 
 They said I should do a javascript compiler, because what the world 
 needed was a fast javascript engine. So I built one, it ran twice as 
 fast as jscript, and I couldn't give it away <g>.
 
 Meanwhile, D took off.



I think that one reasons that stuff crated by somebody for themselves 
work so well is that both the creator and the client are experts in the 
domain. The creator can get instant feedback from the client as if they 
had them sitting in the same room, because the client is in fact the 
creator.
Nov 09 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 I think that one reasons that stuff crated by somebody for themselves 
 work so well is that both the creator and the client are experts in the 
 domain. The creator can get instant feedback from the client as if they 
 had them sitting in the same room, because the client is in fact the 
 creator.


There's a lot to be said for eating your own dogfood!
Nov 09 2007
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 Historically, languages designed for other people to use have been bad: Cobol, 
 PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own creators: 
 C, Perl, Smalltalk, Lisp.


Pascal used to have lots of advantages over C, and not just to teach
programming (Pascal programs were more reliable. Its modern variants like
ObjectPascal have some advantages even over D still, like a better management
of division (with slash and div), better automatic type conversion (like the
upcasting management I have shown here some time ago), etc.).
Ada variants today too are not easy to beat for very high integrity programming
(the main purpose it was designed for).
And C++ despite its very large amount of flaws runs most of my (fast) desktop
apps.
Per is quite used still (but probably less, due to Python and Ruby that are
better for most purposes but the creation of little text processing scripts),
but it's as messy as C++ or worse...

Bye,
bearophile
Nov 09 2007
parent reply Jan Claeys <digitalmars janc.be> writes:
Op Fri, 09 Nov 2007 08:53:31 -0500, schreef bearophile:


 Pascal used to have lots of advantages over C, and not just to teach
 programming (Pascal programs were more reliable. Its modern variants
 like ObjectPascal have some advantages even over D still, like a better
 management of division (with slash and div), better automatic type
 conversion (like the upcasting management I have shown here some time
 ago), etc.).


Plus the RTTI- & component-based development that made Delphi the first 
really popular *and* professionally useful RAD IDE...


-- 
JanC
Nov 09 2007
parent reply Bruce Adams <tortiose_74 yeah.who.co.uk> writes:
Jan Claeys Wrote:


 Op Fri, 09 Nov 2007 08:53:31 -0500, schreef bearophile:
 

 Pascal used to have lots of advantages over C, and not just to teach
 programming (Pascal programs were more reliable. 




What was the source of this alleged better reliability? (I'm guessing harder to
write crap code due to syntactic sugar and salt)


 Its modern variants

 like ObjectPascal have some advantages even over D still, like a better
 management of division (with slash and div), better automatic type
 conversion (like the upcasting management I have shown here some time
 ago), etc.).




Presumably we can do almost anything with cast(auto) or 
cast(DuckType) where DuckType is a class with constructors and opImplicitCast
for a variety of normal unconvertible types. 
DuckType As opposed to Variant where you want stricter control over what is
converted when.

By the way, got a link to the upcasting thread?
 

 Plus the RTTI- & component-based development that made Delphi the first 
 really popular *and* professionally useful RAD IDE...
 
 
 -- 
 JanC


I've had a little surf around and I can find nothing which demonstrates any
especially clever features that object pascal has. So, leaving aside reflection
for which we already expect improvements what do you miss from object pascal
that D doesn't (yet) have? Is there anything it could never have?

I can kind of see where your coming from with the div / argument. D like C++
has inherited C's nasty expression casting.

float A, B, C;
C=B/A;                    vs. C = B DIV A;    use integer only division
int x,y;
C=cast(float)(x)/y;    vs.  C = x/y;   use floating division

Using a cast here to express your intent is ugly and wrong. Different function
names are a more correct way to express intent. You could roll your own of
course (bonus points for conciseness). I wonder if there is any compiler bonus
to be had by the distinction though (the hidden rounding in x = A/B for example
could catch a noob unawares)? 

One thing I miss from the pascal family is better terminology.
cardinal and integer make much more sense than unsigned int and signed int, not
to mention saving typing. I feel a global typedef coming on...

Regards,

Bruce.
Nov 09 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bruce Adams wrote:

 ...
 
 I can kind of see where your coming from with the div / argument. D like C++
has inherited C's nasty expression casting.
 
 float A, B, C;
 C=B/A;                    vs. C = B DIV A;    use integer only division
 int x,y;
 C=cast(float)(x)/y;    vs.  C = x/y;   use floating division
 
 Using a cast here to express your intent is ugly and wrong. Different function
names are a more correct way to express intent. You could roll your own of
course (bonus points for conciseness). I wonder if there is any compiler bonus
to be had by the distinction though (the hidden rounding in x = A/B for example
could catch a noob unawares)? 
 
 ...
 
 Bruce.


We could use downs' trick to define a new infix operator!

C = x /fdiv/ y;

Shorter, and more obvious!  Probably.  To some people :P

	-- Daniel
Nov 09 2007
prev sibling next sibling parent 0ffh <spam frankhirsch.net> writes:
Bruce Adams wrote:

 Jan Claeys Wrote:
 

 Op Fri, 09 Nov 2007 08:53:31 -0500, schreef bearophile:
 

 Pascal used to have lots of advantages over C, and not just to teach
  programming (Pascal programs were more reliable.




 
 What was the source of this alleged better reliability? (I'm guessing 
 harder to write crap code due to syntactic sugar and salt)


Harder to write crap code due to discipline & bondage. =)

Regards, Frank
Nov 10 2007
prev sibling parent Jan Claeys <digitalmars janc.be> writes:
Op Fri, 09 Nov 2007 20:18:28 -0500, schreef Bruce Adams:


 Jan Claeys Wrote:
 

 Op Fri, 09 Nov 2007 08:53:31 -0500, schreef bearophile:
 

 Pascal used to have lots of advantages over C, and not just to teach
 programming (Pascal programs were more reliable.




 
 What was the source of this alleged better reliability? (I'm guessing
 harder to write crap code due to syntactic sugar and salt)


Also run-time buffer overflow checking for strings and stuff like that...



 Plus the RTTI- & component-based development that made Delphi the first
 really popular *and* professionally useful RAD IDE...





 I've had a little surf around and I can find nothing which demonstrates
 any especially clever features that object pascal has. So, leaving aside
 reflection for which we already expect improvements what do you miss
 from object pascal that D doesn't (yet) have? Is there anything it could
 never have?


I think D has most of the Delphi Object Pascal features now (and lots of 
additional features), but Delphi was innovative almost 20 years ago.

Also, de RTTI/reflection is almost a requirement to build an IDE like 
Delphi AFAIK (or it makes it a lot easier at least).

(And IMHO object pascal is still more readable than D's C-style syntax, 
but that might be a personal preference.)


-- 
JanC
Nov 13 2007
prev sibling next sibling parent renoX <renosky free.fr> writes:
BCS a écrit :

 
 http://www.sysprog.net/quotcob.html
 
 Historically, languages designed for other people to use have been bad: 
 Cobol, PL/I, Pascal, Ada, C++.
 The good languages have been those that were designed for their own 
 creators: C, Perl, Smalltalk, Lisp. (Paul Graham)
 
 can we add D to this list?



I like Ada.
I don't like Perl at all.
Plus Pascal wasn't really designed for other people to use, but for 
teaching purpose, which explain that the 'true Pascal' was quite limited 
in scope and that dozen incompatible variants were created to fill the 
void, which would eventually kill Pascal.

So I don't find this quote very accurate..

renoX
Nov 10 2007
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
My may purpose here isn't to discuss that language X is better than Y, but to
show (like renoX) that that quote isn't very accurate.

Jan Claeys:


By the way, got a link to the upcasting thread?<


I hope this is in-topic:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=57087

Bye,
bearophile
Nov 11 2007