hasen wrote:

> Walter Bright wrote:
>> grauzone wrote:
>>> I didn't mean going back to programming with locks. Instead you could use the new ideas without extending the type system. As far as I understand, the language extensions are only needed for verification (so far).
>> 
>> Without verification, it's programming by hopeful convention. If you want a reliable system, you need more than hope <g>.
> 
> Well .. if you think about OOP and private/public ..
> 
> Dynamic languages like python and smalltalk don't enforce private/public, and that never was a problem. And, smalltalk is *the* OO language (AFAIK)
> 
> (this is not really an argument against const per se, it's just an argument against an argument for const)

If you have a dynamic language you have a different way of programming. In D when I make a typo, the compiler catches it. When I do the same in Ruby, I have a unit test that spits out a method missing exception with a trace. Suppose D doesn't catch my typo and then my application crashes at runtime without such a trace, that will be a nightmare.

Lutger:
> If you have a dynamic language you have a different way of programming. In D when I make a typo, the compiler catches it. When I do the same in Ruby, I have a unit test that spits out a method missing exception with a trace. Suppose D doesn't catch my typo and then my application crashes at runtime without such a trace, that will be a nightmare.

This is a complex and long debated topic.
In my D programs I put almost as many unittests as I put in Python programs, because experience shows me the type system of D doesn't catch that many bugs. The result seems strong enough D programs.
While I debug I use the 'Phobos hack' to add something like those traces to D (I don't understand why such feature isn't built-in yet, it's essential when I debug D programs).

Bye,
bearophile

bearophile wrote:
> Lutger:
>> If you have a dynamic language you have a different way of programming. In D when I make a typo, the compiler catches it. When I do the same in Ruby, I have a unit test that spits out a method missing exception with a trace. Suppose D doesn't catch my typo and then my application crashes at runtime without such a trace, that will be a nightmare. 
> 
> This is a complex and long debated topic.
> In my D programs I put almost as many unittests as I put in Python programs, because experience shows me the type system of D doesn't catch that many bugs. The result seems strong enough D programs.
> While I debug I use the 'Phobos hack' to add something like those traces to D (I don't understand why such feature isn't built-in yet, it's essential when I debug D programs).

Agreed on testing, and agreed on stack traces.

However, how do you test the unit test system?

Christopher Wright:
>However, how do you test the unit test system?<

I don't understand the question.

Bye,
bearophile

bearophile wrote:

> Lutger:
>> If you have a dynamic language you have a different way of programming.
In D
>> when I make a typo, the compiler catches it. When I do the same in Ruby,
I
>> have a unit test that spits out a method missing exception with a trace. Suppose D doesn't catch my typo and then my application crashes at
runtime
>> without such a trace, that will be a nightmare.
> 
> This is a complex and long debated topic.
> In my D programs I put almost as many unittests as I put in Python
programs, because experience shows me the type system of D doesn't catch that many bugs. The result seems strong enough D programs.
> While I debug I use the 'Phobos hack' to add something like those traces
to D (I don't understand why such feature isn't built-in yet, it's essential when I debug D programs).
> 
> Bye,
> bearophile

I didn't mean to imply that with D the type system unit tests and stack traces are obsolete or that D is better / worse.

When you say 'not that many bugs', how often does you code compile with errors? Because every compile time error you encounter is a bug in a dynamic language, and within that perspective I think it's quite a lot. Now, that doesn't mean dynamic languages are more bug prone, just that the way you program with them is different. Different enough that you can't compare type systems of static and dynamic languages that easily.

Lutger:

>When you say 'not that many bugs', how often does you code compile with errors?<

I am not able to give you a good answer, I am sorry, so I can just chat a little.
What I can tell you is that I now know both Python and D (I know Python more, but my experience of D is getting sufficient), and I am usually able to write correct programs in quite less time in Python. "correct programs" includes unit tests, debugging, global testing, etc too. It's not easy to tell when a program is "debugged enough", it's an art.
To write a "correct" program in C I need even more time and sometimes at the end I am not sure yet the program is debugged enough (despite I know C for far more time than D). This is what I care of.


>Because every compile time error you encounter is a bug in a dynamic language, and within that perspective I think it's quite a lot.<

The situation isn't so linear. In Python I often don't put many bugs in the first place, because syntax and semantics is less bug prone or more flexible, etc.
In Python I have the shell, where I can try out single lines of code or whole functions, that helps both in writing correct code and in debugging it (and later you can even copy&paste such interactive sessions, with small changes, to use them as doctests).


>Now, that doesn't mean dynamic languages are more bug prone, just that the way you program with them is different. Different enough that you can't compare type systems of static and dynamic languages that easily.<

I agree. Yet, I have often written the same small programs in both D and Python so I can compare the whole programming time, how much long they are, how much reliable they are, etc. I have adopted in my D coding some of the good practices I have developed in Python (regarding unit testing, functional-style programming, using higher-level functions, using templates to make more flexible functions), and the results seems good enough :-)

Bye,
bearophile

bearophile wrote:
> What I can tell you is that I now know both Python and
> D (I know Python more, but my experience of D is getting sufficient),
> and I am usually able to write correct programs in quite less time in
> Python. "correct programs" includes unit tests, debugging, global
> testing, etc too. It's not easy to tell when a program is "debugged
> enough", it's an art. To write a "correct" program in C I need even
> more time and sometimes at the end I am not sure yet the program is
> debugged enough (despite I know C for far more time than D).

This is definitely strongly related to experience. I find that over time coding in any language, I gradually write fewer and fewer bugs. I essentially learn how to avoid the ones peculiar to that particular language.

A lot of influence on D comes from trying to design out of existence particular bugs in C/C++ that cost me a lot of time and effort to track down. I tend to not make those errors anymore in my C/C++ code, but the taste is still bitter and the learning curve is long. Others shouldn't have to follow the same path.

bearophile wrote:
> Christopher Wright:
>> However, how do you test the unit test system?<
> 
> I don't understand the question.
> 
> Bye,
> bearophile

If you have a system that runs unittests, how do you make sure that it is not buggy? You need to devise another test system.

It's not a question that most people should care about.

On 2009-03-07 18:19:50 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Later on I decided to save the filename for error message reporting and the such. Now I had two choices:
> 
> (1) Leave the signature unchanged and issue an idup:
> 
> this.filename = to!string(filename); // issues an idup
> 
> (2) Change the signature to
> 
> this(string filename);

Third choice: have two contructors.

	this(in char[] filename) { this(filename.idup); }
	this(string filename) { ... }

It's pretty easy to add a new version of a construcor or function when you change things and need to keep backward compatibility. The question is: should you?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/