Tue, 01 Dec 2009 10:46:11 -0800, Walter Bright wrote:

> Leandro Lucarella wrote:

>> I really think the *only* *major* advantage of D over Python is speed. That's it.
> 
> I probably place a lot more importance on static verification rather than relying on convention and tons of unit tests.

In many places if you apply for a job, static verification is more or less bullshit talk to their ears. Unit testing with large frameworks is the way to go. You even have lots of new paradigms to learn, e.g. TDD, BDD, ...

grauzone wrote:
> Walter Bright wrote:
>> dsimcha wrote:
>>> In Java, by going overboard on making the core language simple,
>>> you end up pushing all the complexity into the APIs.
>>
>> Yup, and that's the underlying problem with "simple" languages. Complicated code.
> 
> I think users of scripting languages would disagree with you.

Looks like even simple Javascript is getting a major complexity upgrade:


http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars

Andrei Alexandrescu wrote:
> Yah, point taken :o). I probably haven't clarified enough that I'm talking about a mere belief. Arguments have been discussed here in the past (e.g. scalability of the language construct with multiple transactions). Time will tell, but one indicating factor is that programs don't deal well with exceptions and scope guards help that massively, whereas "with" seems to help much less. Besides, anyone may be a nut about something, and scope guard is something I'm a nut about.

I didn't read the Python with carefully, but where does it fall down?

Tue, 01 Dec 2009 17:11:26 -0300, Leandro Lucarella wrote:

> And again, judging from experience, I don't know why, but I really have a very small bug count when using Python. I don't work with huge teams of crappy programmers (which I think is the scenario that D tries to cover), that can be a reason ;)

The lack of type annotations at least removes all typing bugs. Your brain has more processing power for the task at hand since you don't need to concentrate on trivial type issues. Testing the code and writing prototypes in the repl basically eliminates all bugs. At least so they say.

== Quote from retard (re@tard.com.invalid)'s article
> Tue, 01 Dec 2009 10:46:11 -0800, Walter Bright wrote:
> > Leandro Lucarella wrote:
> >> I really think the *only* *major* advantage of D over Python is speed. That's it.
> >
> > I probably place a lot more importance on static verification rather than relying on convention and tons of unit tests.
> In many places if you apply for a job, static verification is more or less bullshit talk to their ears. Unit testing with large frameworks is the way to go. You even have lots of new paradigms to learn, e.g. TDD, BDD, ...

My biggest gripe about static verification is that it can't help you at all with high-level logic/algorithmic errors, only lower level coding errors.  Good unit tests (and good asserts), on the other hand, are invaluable for finding and debugging high-level logic and algorithmic errors.

bearophile wrote:
> I suggest Walter to don't try to say that D2 is "better" than Python,
> it's a waste of time and it means nothing.

I meant it in the form of the simpler being better hypothesis. I am arguing that a simpler language often leads to complex code.

CorePy, PyCuda, PyOpenCL, etc. are not part of Python. They are extensions, and are not written in Python. Heck, C++ Boost is listed as a prerequisite for PyCuda.

The very existence of those shows that Python itself is not powerful enough.

Secondly, use of them does not make Python a simple language.

And thirdly, any language can have extension libraries and processors.

dsimcha:
> Good unit
> tests (and good asserts), on the other hand, are invaluable for finding and
> debugging high-level logic and algorithmic errors.

Contract programming too can help. For example in a precondition of a binary search function you can test that the items are sorted. If you don't like that (because when such contract is present it changes the computational complexity class of the function) you can even do a random sampling test :-)
In some cases it can be useful to split unittests and contracts in two groups (using a version()), a group of fast ones to be run all the time, and group of slower ones to be run only once in a while to be safer.

What I'd like to know is why Andrei has asked for exceptions inside contracts too.

Bye,
bearophile

Leandro Lucarella wrote:
>>>>> 5. simple interfacing to C
>>>> In case you mean no unnecessary wrappers etc., this has more to
>>>> do with the execution model than language features. Most
>>>> scripting languages are interpreted, and require some sort of
>>>> assistance from the runtime system. If the language was compiled
>>>> instead, they wouldn't necessarily need those.
>>> In D you need interfacing code too, it can be a little simpler, that's
>>> true.
>> The interfacing in D is nothing more than providing a declaration.
>> There is no code executed.
> 
> Unless you want to pass D strings to C, then you have to execute
> toStringz(), which is a really thin "wrapper", but it's a wrapper. Using
> C from D is (generally) error prone and painful, so I usually end up
> writing more D'ish wrappers to make the D coding more pleasant.

You can also simply use C strings in D, and pass them straight to C functions that take void*. No conversion necessary. It isn't any harder to ensure a 0 termination in D than it is in C, in fact, it's just the same. D string literals even helpfully already have a 0 at the end with this in mind!


> It's not safe, and of course, being a dynamic language, you can access
> C code at "compile time" (because there it no compile time), but you can
> interface with C very easily:
> 
>>>> import ctypes
>>>> libc = ctypes.cdll.LoadLibrary("libc.so.6")
>>>> libc.printf("hello world %i\n", 5)
> hello world 5
> 
> Wow, that was hard! =)

Ok, does this work:

    p = libc.malloc(100);
    *p = 3;

? Or this:

    struct S { int a; char b; };
    S s;
    libc.fillInS(&s);



> It's simpler, because you only have one obvious way to do things,

No, Python has try/catch/finally as well.

> in D you
> can use a struct, a scope class or a scope statement to achieve the same.
> Of course that gives you more flexibility, but adds complexity to the
> language. I'm not complaining or saying that D is wrong, I'm just saying
> that Python is a very expressive language without much complexity. I think
> the tradeoff is the speed.


>> Yes, you can emulate RAII with the with statement, but with RAII
>> (objects that destruct when they go out of scope) you can put this
>> behavior in the object rather than explicitly in the code every time
>> you use it. It's more complicated to have to remember to do it every
>> time on use.
> 
> Maybe you are right, but the with statement plays very well with the
> "explicit is better than implicit" of Python :)
> 
> Again, is flexibility vs complexity.

Another principle is abstractions should be in the right place. When the abstraction leaks out into the use of the abstraction, it's user code complexity. This is a case of that, I believe.


> There are static analyzers for Python:
> http://www.logilab.org/857
> http://divmod.org/trac/wiki/DivmodPyflakes
> http://pychecker.sourceforge.net/

What's happening here is the complexity needed in the language is pushed off to third party tools. It didn't go away.


> And again, judging from experience, I don't know why, but I really have
> a very small bug count when using Python. I don't work with huge teams of
> crappy programmers (which I think is the scenario that D tries to cover),
> that can be a reason ;)

Part of that may be experience. The languages I use a lot, I tend to generate far fewer bugs with because I've learned to avoid the common bugs. There have been very few coding errors in the C++ dialect I use in dmd, the errors have been logic ones.

You're right that D has a lot that is intended more for large scale projects with a diverse team than one man jobs. There is a lot to support enforced encapsulation, checking, and isolation, if that is desired. Purity, immutability, contracts, interfaces, etc., are not important for small programs.

Leandro Lucarella wrote:
> I develop twice as fast in Python than in D. Of course this is only me,
> but that's where I think Python is better than D :)

If that is not just because you know the Python system far better than the D one, then yes indeed it is a win.

> I think only not having a compile cycle (no matter how fast compiling is)
> is a *huge* win. Having an interactive console (with embedded
> documentation) is another big win.

That makes sense.

On Tue, Dec 01, 2009 at 09:17:44PM +0000, retard wrote:
> The lack of type annotations at least removes all typing bugs.

Quite the contrary, leaving off the type annotation spawns bugs. I had to write a web app in Ruby last year, and well remember the little things that slipped past tests, pissing off end users.

"Why can't I access this obscure page?"

Because a != b since for some reason, the database returned a as a string, and b was assigned by an integer literal.

In D, that would have been an instant compile time error. In Ruby, it was a runtime error on a page obscure enough that it slipped past testing into the real world.


You might say that I should have been more disciplined about my testing, or maybe the company should have hired a dedicated tester, but the fact remains that it simply wouldn't have happened in D at all. (Even if I left off the types and used 'auto' everywhere, the compiler would still see the mismatch.)



Until now :P I'm fairly certain that with std.variant and some opDispatch magic, we can recreate the dynamic system wholesale, so you could, if you really wanted to, just use var for all types.

The only thing left to make it happen in the language is probably either opImplicitCast or global assignment operator overloads, and even they aren't strictly necessary for a lot of programs.


-- 
Adam D. Ruppe
http://arsdnet.net