October 31, 2006

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/
October 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
October 31, 2006
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).
October 31, 2006
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
November 01, 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.
November 01, 2006
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'.])
November 01, 2006
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  ensure that this and #1 would remain in the compiled binary.

In this way it would be fairly difficult to be sure of code you compile, even if you compiled your compiler...

-DavidM
1 2
Next ›   Last »