digitalmars.D - Making D better than other programming languages (warning: rant, drivel)
- LaggedOnUser (65/65) Oct 28 2006 Hello, D users. I have been following the progress of the D programming...
- =?iso-8859-1?q?Knud_S=F8rensen?= (59/78) Oct 28 2006 By noticing that the most productive languages seems to be domain and
- Karen Lanrap (4/5) Oct 29 2006 This seems much more useful than the LOC approach.
- LaggedOnUser (11/11) Oct 29 2006 I am not very familiar with the CLR, but I doubt if it will extinguish o...
- LaggedOnUser (30/30) Oct 29 2006 Thanks for your reply. I checked out the Google video and it was very i...
- Walter Bright (29/59) Oct 29 2006 I agree. My experiments with real D projects compared with their
- Nils Hensel (7/11) Oct 30 2006 I agree, this is a great feature. In this aspect D is nearly a
- Dave (16/30) Oct 30 2006 Where I work right now, they do a lot of Perl (the most productive langu...
- renox (7/53) Nov 01 2006 Uh? Security audit of the *compiler*??
- David Medlock (11/74) Nov 01 2006 Ken Thompson had a paper called 'Reflections on Trusting Trust' which
- Dave (10/26) Oct 30 2006 In the link for the OP, one thing that apparently wasn't considered or a...
- Walter Bright (7/13) Oct 30 2006 I've been using dynamic typing in the DMD front end in a few places, and...
- Daniel Keep (21/35) Oct 31 2006 I sometimes think that whilst dynamic typing can be *very* handy to
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (3/9) Oct 31 2006 In a portable assembler like C, the size of registers *is* important.
- Don Clugston (10/37) Oct 31 2006 I agree. There's an interesting issue with using LOC as a productivity
- Sean Kelly (14/22) Oct 31 2006 This is why I don't like Lua, and it was a huge source of bugs for me
- Walter Bright (10/12) Oct 31 2006 That particular problem was in FORTRAN, the first programming language,
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
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.0By 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
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
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
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
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 differenceThis 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
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
Nils Hensel wrote:Walter Bright schrieb: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'.])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
Dave wrote:Nils Hensel wrote: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. RenaudWalter Bright schrieb: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.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(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
renox wrote:Dave wrote: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... -DavidMNils Hensel wrote: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. RenaudWalter Bright schrieb: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.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(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
Walter Bright wrote:LaggedOnUser wrote: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, - DaveThe 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.
Oct 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.
Oct 30 2006
Walter Bright wrote:Dave 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!). 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/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 31 2006
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
Dave wrote:Walter Bright wrote: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.LaggedOnUser wrote: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.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.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
Don Clugston wrote:Dave wrote: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. SeanSo 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
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