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.
 

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 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.).


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 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 next sibling parent 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
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 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