www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Making D better than other programming languages (warning: rant, drivel)

reply LaggedOnUser <laggedOnUser gmail.com> writes:
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

- 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.
Oct 28 2006
next sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
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
Oct 28 2006
next sibling parent reply Karen Lanrap <karen digitaldaemon.com> writes:
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.
Oct 29 2006
parent LaggedOnUser <laggedonuser gmail.com> writes:
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.
Oct 29 2006
prev sibling parent LaggedOnUser <laggedonuser gmail.com> writes:
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.


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.


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
Oct 29 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Oct 29 2006
next sibling parent reply Nils Hensel <nils.hensel web.de> writes:
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
Oct 30 2006
parent reply Dave <Dave_member pathlink.com> writes:
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'.])
Oct 30 2006
parent reply renox <renosky free.fr> writes:
Dave wrote:
 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.
Uh? Security audit of the *compiler*?? I agree that having secure generated code and secure library is a must but of the compiler itself, frankly.. Note that given widespread current usage of C, I find it hard to believe that this kind of security requirement is really serious. Renaud
 (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'.])
Nov 01 2006
parent David Medlock <noone nowhere.com> writes:
renox wrote:
 Dave wrote:
 
 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.
Uh? Security audit of the *compiler*?? I agree that having secure generated code and secure library is a must but of the compiler itself, frankly.. Note that given widespread current usage of C, I find it hard to believe that this kind of security requirement is really serious. Renaud
 (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'.])
Ken Thompson had a paper called 'Reflections on Trusting Trust' which used a hacked compiler which would: http://www.acm.org/classics/sep95/ 1. Detect when the unix login C code was being compiled and put a hardcoded backdoor name and password which would give root access. 2. Detect when the unix C compiler was being compiled and insert code to In this way it would be fairly difficult to be sure of code you compile, even if you compiled your compiler... -DavidM
Nov 01 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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
Oct 30 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Oct 30 2006
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 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.
I sometimes think that whilst dynamic typing can be *very* handy to have, it's ultimately just a panacea for a "proper" type system. Type systems like C's are really annoying because you spend so much time telling the compiler the same thing over and over again, even when it's not even really important (float, double? I don't care; I just want a number, damnit!). But given something like, say, Nemerle's type system where you have full inference and things like disjunction types (can't remember the proper name: where you can say a variable is Type1 OR Type2 OR ...), you get most of the benefits, with a lot of the safety static typing gives you. I also find it interesting that a lot of the dynamically typed languages I've seen seem to be slowly growing static typing abilities because people get so sick of continually having to test the type of something :P Same problem, different place, I suppose. -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Oct 31 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Daniel Keep wrote:

 I sometimes think that whilst dynamic typing can be *very* handy to
 have, it's ultimately just a panacea for a "proper" type system.  Type
 systems like C's are really annoying because you spend so much time
 telling the compiler the same thing over and over again, even when it's
 not even really important (float, double?  I don't care; I just want a
 number, damnit!).
In a portable assembler like C, the size of registers *is* important. --anders
Oct 31 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Dave wrote:
 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.
I agree. There's an interesting issue with using LOC as a productivity metric -- in my experience, unit tests are one of the ways that D gives a massive productivity boost, yet they result in an *increase* in the lines of code! It's rare that you see productivity data that includes refactoring. Yet maintainability is surely one of the most important aspects of coding.
 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 suspect it doesn't scale very well. (Like not requiring you declare variables -- looks great on a 10 or 20 line program, a complete disaster on anything bigger).
Oct 31 2006
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 Dave wrote:
 So I'm wondering if, in the grand scheme of things, dynamic typing 
 really accounts for a 2.5x difference in productivity anyhow?
I suspect it doesn't scale very well. (Like not requiring you declare variables -- looks great on a 10 or 20 line program, a complete disaster on anything bigger).
This is why I don't like Lua, and it was a huge source of bugs for me there. Any typo resulted in a new variable being created instead of an existing one being modified. But I do think that dynamic typing is useful in the general case. Ruby, for example. If the object has the methods being called then it doesn't matter what the underlying type is, and if there is a mismatch (say, for expressions) then coercion is an option. But even though Smalltalk works the same way (as far as I know), I'm not sure how the concept scales or how it affects provability. I'll admit I still like having the compiler catch as many errors as possible, and in the extreme case, this form of type checking seems like it could allow bizarre mistakes to be made and for them to be extremely difficult to debug. Sean
Oct 31 2006
parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 Any typo resulted in a new variable being created instead of an 
 existing one being modified.
That particular problem was in FORTRAN, the first programming language, and was identified as a rich source of bugs at least by the early 70's. Nevertheless, the bug gets reinvented in endless new programming languages, and the designer then belatedly realizes the mistake. Note the change in Perl where you can force the compiler to complain about undeclared variables. I think the reason it keeps being reincarnated is that it *does* look good in 20 line programs. You don't invent million line examples for nonexistent languages.
Oct 31 2006