Jump to page: 1 2
Thread overview
Making D better than other programming languages (warning: rant, drivel)
Oct 28, 2006
LaggedOnUser
Oct 29, 2006
Knud Sørensen
Oct 29, 2006
Karen Lanrap
Oct 29, 2006
LaggedOnUser
Oct 29, 2006
LaggedOnUser
Oct 30, 2006
Walter Bright
Oct 30, 2006
Nils Hensel
Oct 30, 2006
Dave
Nov 01, 2006
renox
Nov 01, 2006
David Medlock
Oct 30, 2006
Dave
Oct 30, 2006
Walter Bright
Oct 31, 2006
Daniel Keep
Oct 31, 2006
Don Clugston
Oct 31, 2006
Sean Kelly
Nov 01, 2006
Walter Bright
October 28, 2006
Hello, D users.  I have been following the progress of the D programming language with some interest.  It has a nice, clean syntax and seems to be an
improvement in various ways over C, C++, and Java, and is a worthy successor to them.  I would like to offer some ideas based on my general experience
with programming and research into programming languages that might help improve D and make it better than its alternatives.  These are just ideas; I
am an ordinary work-a-day programmer and not an uber-leet hacker so I really couldn't implement these suggestions myself.  Nor could I hope to ever
match Walter Bright's decades of experience in quality compiler design and implementation.  Nonetheless, here are a few points for you all to consider.

It is claimed on the D site that DMD offers the same programming productivity benefits as Ruby.  Based on several typical research projects into
programming language productivity, I find that claim to be very likely false.  (Of course, the specific claim, "Is DMD as productive as Ruby?" has not
been tested, still I can offer some generalizations).  My opinion is derived from considering the following research:

* http://www.theadvisors.com/langcomparison.htm - This site is a nearly exhaustive comparison of programming languages that includes C, C++, Java, and
Perl, among others.  It rates their productivity level as follows:

C - 2.5
C++ - 6.0
Java - 6.0
Perl - 15.0

Notice that C++ and Java are rated exactly the same in terms of productivity, whereas Perl, a typical scripting language, seems to offer roughly twice
the productivity.  This is born out by actual tests, including the following sites.
* http://www.codinghorror.com/blog/archives/000365.html
* http://doi.ieeecomputersociety.org/10.1109/2.876288

The best metric for productivity across languages appears to be Lines of Code (LOC).  The productivity for a typical programmer is inversely
proportional to the number of lines of code he/she has to write.

A comparison of the four most popular script languages at the Programming Language Shootout site (PHP, Python, Perl and Ruby) shows that all of the
most popular web scripting languages are roughly equal in lines of code, and are thus likely to be about equally productive.
* http://dada.perl.it/shootout/

This too is borne out by the actual studies cited above, that showed no significant difference between Python and Perl.  This is rather surprising,
since Perl is somewhat out-of-favor nowadays due to is rather cryptic syntax but Python is considered to be tops in productivity (or Ruby if you
prefer).  The fact that there appears to be no significant difference seems to imply that the superficial syntactic differences between Python and Perl
are not really productivity drivers, but something else is raising them to the same level of productivity.  That "something else" is probably the fact
that both are essentially dynamically-typed, easy-to-use, scripting languages that are terse and expressive.

In that regard, DMD is far more similar to C/C++/Java, than it is to PHP/Python/Perl/Ruby.
- DMD is statically typed and compiled, not dynamically typed.  I know, it can be run as a script, but that doesn't change the syntax, so that probably
doesn't increase coding productivity.
- DMD is probably no more terse or expressive than Java enough to make a difference

After all, if moving from C++ to Java seems to provide no productivity gain, then how much could one really gain by moving from Java to DMD?  Perhaps
not enough to make a difference.

Another problem in general with programming languages and environments, in my opinion, is that they pay insufficient attention to usability
engineering.  They simply don't take an evidence-based, quantitative approach to language design, rather relying on "intuition" about what works, which
is often overhyped and fallible.  The claims about object-oriented software productivity are quite overhyped, for example, and studies don't bear that
out either.

Another limitation of languages is that they don't scale very well.  If you learn a web scripting language, it is not compiled or compilable, therefore
one cannot translate that application into a different environment such as desktop app programming.  This burdens the programmer with learning a number
of niche languages to do different jobs.

Based on these and other considerations, here are my recommendations for improving Digital Mars D and making it competitive/superior to other languages:

1. Pay attention to the evidence of research studies into programming language productivity and usability and apply them to Digital Mars D where
applicable, rather than mere intuition or hype.  It would be better if you were able to back up claims about the language with actual facts or
research.  To this end, Digital Mars could possibly offer itself as a subject for academic study/research.

2. Increase the "scalability" or "portability" of Digital Mars to the scripting world.  I know, there is DMDScript, but that is not what I'm talking
about.  The problem with DMDScript is that it is really ECMAScript, so the user of ECMAScript has to learn a brand new language.  It would be better if
there were one DMD language that scaled all the way from interactive programming (like Python/Ruby), to dynamically-typed web scripting (like
PHP/Perl/etc), to browser-scripting (like ECMAScript), to GUI programming, to in-browser GUI development (like Java), etc.  Having a compatible syntax
for all these different tasks would make D far more scalable and portable as the "one language I need for my programming department to learn".  Such a
language could go from easy-to-learn scripting for noobs up to professional statically-typed compiled language within the same exact syntactic
framework.  This is rather like the way Mercury builds on top of Prolog, if you've ever studied those languages.

3. Provide a richer library with a large vocabulary of built-ins so that programmers don't have to re-invent the wheel.

I would sum up the benefits of these proposals versus current languages as follows:
- C/C++/Java: not compiled, not scripted, hype-driven, bug-prone
- PHP/Perl/Python/Ruby: not compiled, not browser-scripting languages, they're constantly tweaking the syntax and making it backward-incompatible
without a thought for research or evidence into improving it
- Visual Basic/C#: Java wannabees and Microcruft clones
- Insert name of your favorite language here: <index to well-aimed put-down>

These proposals are intended to be practical and not too difficult to implement.  They do not involve radically changing the DMD syntax, but merely
offering different, more simplified versions that scale up to the original, about which I cannot think of any significant improvements since it is
already perfect.  :-)

LaggedOnUser
--
Power to D people.
October 29, 2006
On Sat, 28 Oct 2006 17:27:55 +0000, LaggedOnUser wrote:


> It is claimed on the D site that DMD offers the same programming productivity benefits as Ruby.  Based on several typical research projects into programming language productivity, I find that claim to be very likely false.  (Of course, the specific claim, "Is DMD as productive as Ruby?" has not been tested, still I can offer some generalizations).  My opinion is derived from considering the following research:
> 
> * http://www.theadvisors.com/langcomparison.htm - This site is a nearly exhaustive comparison of programming languages that includes C, C++, Java, and Perl, among others.  It rates their productivity level as follows:
> 
> C - 2.5
> C++ - 6.0
> Java - 6.0
> Perl - 15.0
> 
> 
By noticing that the most productive languages seems to be domain and application specific language. This made me think about the problem of productivity, and lead me to the following generalisation for productivity levels.

*1 - Platform level*
This is the leased productive level for solving a specific problem, but it
is also the most general level.
**Software** In software this would be equivalent to the OS.
**Language** As a programing language this equivalent to the assembler
language.
**D related ** productivity equivalent to D in line assembler.

*2 - Technical level*

**Software** This is equivalent to the libraries in the OS all the
technical functions as disk access , date time functions and e.t.c.

**Language** genneral perpose programing language like C, C++ and etc.

** D related** Normal D programing.

*3 - Domain level*

**Software** Domain specific libraries like cryptology, linear algebra and
etc.

**Language** Domain specific language as SQL which is very productive in its own domain.

**D related** The ability to define a domain specific language with in D.
This is this where Ruby is strong.
See http://video.google.com/videoplay?docid=-8103284744220333344


*4 - Application level*

**Software** equivalent to applications programs.
**Language** The output from a application specific language is a product
not a program. Examples is Latex, asymptote and etc.
http://asymptote.sourceforge.net/

**D related** The ability to define a application specific language with
in D.
An Example for this is http://www-users.mat.uni.torun.pl/~h3r3tic/ctrace/
which make compiler time raytracing.

It would be nice if D make it easy to make this type functionality.
A D library with the same functionality of asymptote would be a nice thing
to have.


*5 - Interface level*
**Software** Standard interfaces for data exchange between applications.
When a standard data format within a domain is accepted it leads to
another level of productivity.

**Language** HTML, XHTML, pdf and etc.

** D related** If the D file format for a compiler time raytracing scene become the standard format for raytracing scenes than D would have raised to this level within this domain.

---------------

So, why is Perl's ranking 15 and Java,C++,C is only 6.

I think it is because Perl have domain specific part when the domain is
text processing.  Which make it easy to solve many real world problems.
So, it raise Perl's level partly in to level 3.
Ruby makes it possible to make domain specify languages and this make
it a level 3 language.

Knud








October 29, 2006
Knud Sørensen wrote:

> to the following generalisation for productivity levels.

This seems much more useful than the LOC approach.

It clearly puts M$'s CLR into level 5 and raises the question whether D can stand such a competition or has to adapt to CLR.
October 29, 2006
Thanks for your reply.  I checked out the Google video and it was very interesting.

In the video, David Pollack described a number of DSLs including:
* SQL
* PostScript
* PDF
* XML
* HTML
* Spreadsheet macro

It occurred to me also that any data file format could be considered a "domain specific language" as well, for example, the format of a GIF file or CSV
text file.  If that definition were accepted, then the number of DSLs could be said to be in the thousands, in addition to custom DSLs.

DSLs seem to fall into two basically different categories:
1. Data Definition (declarative) languages such as SQL, PostScript, PDF, XML, HTML...
2. Program Definition (procedural) languages such as Spreadsheet macro, other DSLs...

How does this affect the promotion of the DMD language?  It seemed to me in two ways:
1. DSLs require a good "glue language", for which purpose David recommended Ruby.  All of the glue languages I have ever seen recommended (Ruby, Perl,
Python, etc.) are all without exception high-level scripting languages.  Therefore, DMD is probably not a "glue language" as it currently stands.
2. DSLs, particularly of a Data Definition kind, require an interface.  Your programming language of choice should be able to read and write XML
fluently, for example.  Most programming languages can do that.

Point #1 seems to confirm my notion that for DMD to be useful as a DSL language there should be a D-compatible scripting language.  This could be
programmed from scratch or possibly implemented on top of the new Parrot shared-language infrastructure for maximum compatibility with existing
languages such as the Perl 6 (and whatever else they implement on top of Parrot).  This could extend D's reach into the DSL area.

Point #2 seems to imply that a large library of DSL reading and writing functions would be useful.  That is, if D could natively read audio, graphic,
and video file formats, as well as PDF, XML, HTML, etc, that would make the language very attractive as well.

As for the Program Specific languages, I am somewhat suspicious of their usefulness.  Even David in his video mentions that programmers were reluctant
to learn a new language, Click, just to program in some application domain.  The burden of learning a new syntax for web scripting, browser scripting,
programming, etc. is already great enough without creating any number of new incompatible syntaxes, and the benefits of syntax redefinition are
probably not that great.  That would fragment the development base even worse than it already is.  It would probably be better for programmers in my
opinion to simply adapt some general purpose, already-proven and debugged language to be the scripting language of their project than to invent a new,
incompatible scripting language for no great purpose.  The syntactic domain is already well-explored and probably holds few surprises.

LaggedOnUser
October 29, 2006
I am not very familiar with the CLR, but I doubt if it will extinguish other programming languages or environments.  There are other ways to integrate
scripting languages into a common framework (such as the now-developing Parrot, or the targeting of code towards the Java virtual machine, or the Mono
platform).

And there is still a need for non-scripted, compiled languages such as C/C++/D.  On the one hand, the use of programming languages should be productive
for the programmer, but on the other hand, you have to balance the need of the user for a speedy application.  That's probably why compiled languages
such as C continued to be used despite their known flaws, because the app that is delivered to its potentially millions of users can be as speedy and
responsive as possible.  That tends to drive slower apps out of the market.

Ideally, a language should be able to move smoothly from scripted to compiled, that way you don't have to learn two languages.  Even in an integrated-
language environment, you will still have problems if you allow your code base to splinter into multiple languages, because your developers will have
to learn a new language to debug each portion of code.  On the plus side, though, it does make it possible to integrate your code with someone else's
library if you need to.
October 30, 2006
LaggedOnUser wrote:
> The best metric for productivity across languages appears to be Lines of Code (LOC).  The productivity for a typical programmer is inversely
> proportional to the number of lines of code he/she has to write.

I agree. My experiments with real D projects compared with their equivalent C++ ones is that the D ones about about 30% less source code.
If the proportionality rule applies, that makes it 30% more productive.

> That "something else" is probably the fact
> that both are essentially dynamically-typed, easy-to-use, scripting languages that are terse and expressive.

I think the dynamic typing thing along with gc are the big productivity drivers.

> In that regard, DMD is far more similar to C/C++/Java, than it is to PHP/Python/Perl/Ruby.
> - DMD is statically typed and compiled, not dynamically typed.  I know, it can be run as a script, but that doesn't change the syntax, so that probably
> doesn't increase coding productivity.

> - DMD is probably no more terse or expressive than Java enough to make a difference

This I strongly disagree with. Java requires a lot more code to get anything done. Its saving grace is its very extensive library.

> After all, if moving from C++ to Java seems to provide no productivity gain, then how much could one really gain by moving from Java to DMD?  Perhaps
> not enough to make a difference.

When moving from C++ to Java, you save lines of code in not having to deal with memory management, but you pay lines of code because Java isn't as expressive. The two effects may just cancel each other out, leaving the observed result.

> Another problem in general with programming languages and environments, in my opinion, is that they pay insufficient attention to usability
> engineering.  They simply don't take an evidence-based, quantitative approach to language design, rather relying on "intuition" about what works, which
> is often overhyped and fallible.

While true that D isn't based on scientific studies, it *is* based on a great deal of practical programming experience both of myself and others, and studies that I have read. One result of this is you don't see D features being all forced to fit one all-encompassing slogan like some other languages do.


> The claims about object-oriented software productivity are quite overhyped, for example, and studies don't bear that
> out either.

True, and D doesn't force an OOP approach to everything.

> Based on these and other considerations, here are my recommendations for improving Digital Mars D and making it competitive/superior to other languages:
> 
> 1. Pay attention to the evidence of research studies into programming language productivity and usability and apply them to Digital Mars D where
> applicable, rather than mere intuition or hype.

I believe D does.

> It would be better if you were able to back up claims about the language with actual facts or
> research.  To this end, Digital Mars could possibly offer itself as a subject for academic study/research.

The facts that do exist for D do support the claims, but such would be a  lot clearer if the language was heavily used in industry.

> 2. Increase the "scalability" or "portability" of Digital Mars to the scripting world.  I know, there is DMDScript, but that is not what I'm talking
> about.  The problem with DMDScript is that it is really ECMAScript, so the user of ECMAScript has to learn a brand new language.

DMDScript isn't a D scripting language, it's ECMAScript implemented using D.

> It would be better if
> there were one DMD language that scaled all the way from interactive programming (like Python/Ruby), to dynamically-typed web scripting (like
> PHP/Perl/etc), to browser-scripting (like ECMAScript), to GUI programming, to in-browser GUI development (like Java), etc.  Having a compatible syntax
> for all these different tasks would make D far more scalable and portable as the "one language I need for my programming department to learn".  Such a
> language could go from easy-to-learn scripting for noobs up to professional statically-typed compiled language within the same exact syntactic
> framework.  This is rather like the way Mercury builds on top of Prolog, if you've ever studied those languages.

D with the -run switch can actually be used much like a scripting language. Several people here use it that way.

> 3. Provide a richer library with a large vocabulary of built-ins so that programmers don't have to re-invent the wheel.

Yes.

One thing you mentioned as a proven productivity booster is dynamic typing. D isn't going to do dynamic typing, but its type inference support is getting much better, to the point where one does not need to explicitly say nearly so many types.
October 30, 2006
Walter Bright schrieb:
> One thing you mentioned as a proven productivity booster is dynamic typing. D isn't going to do dynamic typing, but its type inference support is getting much better, to the point where one does not need to explicitly say nearly so many types.

I agree, this is a great feature. In this aspect D is nearly a compilable Python. I found myself using D in cases I normally would have used Python for.

Way to go! ;-)

Cheers,
Nils
October 30, 2006
Nils Hensel wrote:
> Walter Bright schrieb:
>> One thing you mentioned as a proven productivity booster is dynamic
>> typing. D isn't going to do dynamic typing, but its type inference
>> support is getting much better, to the point where one does not need to
>> explicitly say nearly so many types.
> 
> I agree, this is a great feature. In this aspect D is nearly a
> compilable Python. I found myself using D in cases I normally would have
> used Python for.
> 
> Way to go! ;-)
> 
> Cheers,
> Nils

Where I work right now, they do a lot of Perl (the most productive language mentioned in the OP).

Because of the built-in strings, AA's, good/easy I/O and regexp lib., D could be great for a lot of what Perl is used for. And perhaps just as productive for many text processing tasks for the average Perl hacker who doesn't have all of the arcane Perl syntax imprinted in their temporal lobe yet.

Anyhow, there are two reasons why D isn't in this shop:

1) No (current) 'port' for HPUX
2) For security and system stability reasons, anything new and relatively unproven is pretty unlikely to make it onto the machines in this shop (pretty prudent actually).

With that in mind.. Once v1.0 of D is released, it may actually be a good idea for Walter to call in some chips and get a 'code security audit' done on the compiler and phobos if possible. Some assurance to prospective commercial users that it's safe to install on their 'big-iron' may go a long way towards at least getting organizations to try it, but I really don't know.

(It may be impressive to headline something like "The D v1.0 compiler and runtime library have passed a 3rd-party code security audit". [if a statement like that wouldn't void some portion of the 'suitability warranty'.])
October 30, 2006
Walter Bright wrote:
> LaggedOnUser wrote:
>> The best metric for productivity across languages appears to be Lines of Code (LOC).  The productivity for a typical programmer is inversely
>> proportional to the number of lines of code he/she has to write.
> 
> I agree. My experiments with real D projects compared with their equivalent C++ ones is that the D ones about about 30% less source code.
> If the proportionality rule applies, that makes it 30% more productive.
> 
>> That "something else" is probably the fact
>> that both are essentially dynamically-typed, easy-to-use, scripting languages that are terse and expressive.
> 
> I think the dynamic typing thing along with gc are the big productivity drivers.
> 

In the link for the OP, one thing that apparently wasn't considered or adjusted for is how many errors during development, and how long it took to find those errors.

Often I see that dynamic typing will mask errors, and make them a lot more time consuming to both debug and (sometimes) workaround once they are found. And often they make it through to production code as well.

So I'm wondering if, in the grand scheme of things, dynamic typing really accounts for a 2.5x difference in productivity anyhow?

Thanks,

- Dave
October 30, 2006
Dave wrote:
> Often I see that dynamic typing will mask errors, and make them a lot more time consuming to both debug and (sometimes) workaround once they are found. And often they make it through to production code as well.
> 
> So I'm wondering if, in the grand scheme of things, dynamic typing really accounts for a 2.5x difference in productivity anyhow?

I've been using dynamic typing in the DMD front end in a few places, and it's been a source of a couple bugs. I've been using type inference more and more in D, and it's been eliminating bugs rather than causing them. It's especially useful in foreach where I don't have to worry about getting the element value or index type right, especially when the type of the aggregate changes.
« First   ‹ Prev
1 2