View mode: basic / threaded / horizontal-split · Log in · Help
October 31, 2006
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Re: Making D better than other programming languages (warning: rant, drivel)
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home