Tue, 01 Dec 2009 13:15:53 -0800, Walter Bright wrote:

> 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

All languages seem to add more features during their lifetime. I've never heard of language in which feature count somehow decreases with later versions. If you're happy with the previous version, why upgrade? E.g. the existence of Java 5+ or D 2.0 doesn't mean developing code with Java 1.4 or D 1.x is illegal.

Tue, 01 Dec 2009 14:22:10 -0800, Walter Bright wrote:

> bearophile wrote:
>> Right. But what people care in the end is programs that get the work done. If a mix of Python plus C/C++ libs are good enough and handy enough then they get used. For example I am able to use the PIL Python lib with Python to load, save and process jpeg images at high-speed with few lines of handy code. So I don't care if PIL is written in C++: http://www.pythonware.com/products/pil/
> 
> Sure, but that's not about the language. It's about the richness of the ecosystem that supports the language, and Python certainly has a rich one.

I thought D was supposed to be a practical language for real world problems. This 'D is good because everything can and must be written in D' is beginning to sound like a religion. To me it seems the Python way is more practical in all ways. Even novice programmers can produce efficient programs with it by using a mixture of low level C/C++ libs and high level python scripts.

I agree that Python isn't as fast as D and it lacks type safety things and so on, but in the end of day the Python coder gets the job done while the D coder still fights with inline assembler, compiler bugs, porting the app, fighting the type system (mostly purity/constness issues). Python has more libs available, you need to write less code to implement the same functionality and it's all less troublesome because the lack of type annotations. So it's really understandable why a greater amount people favor Python.

Tue, 01 Dec 2009 16:58:32 -0500, Adam D. Ruppe wrote:

> 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.

It spawns new bugs, for sure, but it removes all static typing bugs cause those aren't checked anymore and cannot exist under that category!

> 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.

The thing is, nowadays when all development should follow the principles of clean code (book), agile, and tdd/bdd, this cannot happen. You write tests first, then the production code. They say that writing tests and code takes less time than writing only the more or less buggy production code. Not writing tests is a sign of a novice programmer and they wouldn't hire you if you didn't advertise your TDD skills.

In this particular case you use a dummy test db fixture system, write tests for 'a is int' and 'b is int'. With these tests in place, the functionality provided by D's type system is only a subset of the coverage the tests provide. So D cannot offer any advantage anymore over e.g. Python.

Tue, 01 Dec 2009 14:24:01 -0800, Walter Bright wrote:

> dsimcha wrote:
>> 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.
> 
> Unit tests have their limitations as well. Unit tests cannot prove a function is pure, for example.

Sure, unit tests can't prove that.

> Both unit tests and static verification are needed.

But it doesn't lead to this conclusion. Static verification is sometimes very expensive and real world business applications don't need those guarantees that often. It's ok if a web site or game crashes every now and then. If I need serious static verification, I would use tools like Coq, not D..

retard wrote:
> Tue, 01 Dec 2009 14:22:10 -0800, Walter Bright wrote:
> 
>> bearophile wrote:
>>> Right. But what people care in the end is programs that get the work
>>> done. If a mix of Python plus C/C++ libs are good enough and handy
>>> enough then they get used. For example I am able to use the PIL Python
>>> lib with Python to load, save and process jpeg images at high-speed
>>> with few lines of handy code. So I don't care if PIL is written in C++:
>>> http://www.pythonware.com/products/pil/
>> Sure, but that's not about the language. It's about the richness of the
>> ecosystem that supports the language, and Python certainly has a rich
>> one.
> 
> I thought D was supposed to be a practical language for real world problems. This 'D is good because everything can and must be written in D' is beginning to sound like a religion. To me it seems the Python way is more practical in all ways. Even novice programmers can produce efficient programs with it by using a mixture of low level C/C++ libs and high level python scripts.
> 
> I agree that Python isn't as fast as D and it lacks type safety things and so on, but in the end of day the Python coder gets the job done while the D coder still fights with inline assembler, compiler bugs, porting the app, fighting the type system (mostly purity/constness issues). Python has more libs available, you need to write less code to implement the same functionality and it's all less troublesome because the lack of type annotations. So it's really understandable why a greater amount people favor Python.
You don't actually have to use pure, const, inline assembler, etc. D is a wonderful language to just do string-and-hashtable code in. All the other features are there to help bigger projects (contracts, yay!) or projects with special needs (I for one have never needed inline ASM).

Walter Bright wrote:
>> But you can do that with the 'with' statement!
> 
> The with goes at the use end, not the object declaration end. Or I read the spec wrong.
So does the scope guard. I think scope guard solves the same problem as the with-statement, only it does it in a more flexible and arguably sexier way.

Walter Bright wrote:
> Leandro Lucarella wrote:
>> I guess D can greatly benefit from a compiler that can compile and run
>> a multiple-files program with one command
> 
> dmd a b c -run args...

Can we have

dmd -resolve-deps-and-run main.d

I use rdmd when I can, but it doesn't manage to link C-libs in properly.

Pelle Månsson wrote:
> Walter Bright wrote:
>> Leandro Lucarella wrote:
>>> I guess D can greatly benefit from a compiler that can compile and run
>>> a multiple-files program with one command
>>
>> dmd a b c -run args...
> 
> Can we have
> 
> dmd -resolve-deps-and-run main.d
> 
> I use rdmd when I can, but it doesn't manage to link C-libs in properly.

Could you please submit a sample to bugzilla?

Andrei

Andrei Alexandrescu wrote:
> Pelle Månsson wrote:
>> Walter Bright wrote:
>>> Leandro Lucarella wrote:
>>>> I guess D can greatly benefit from a compiler that can compile and run
>>>> a multiple-files program with one command
>>>
>>> dmd a b c -run args...
>>
>> Can we have
>>
>> dmd -resolve-deps-and-run main.d
>>
>> I use rdmd when I can, but it doesn't manage to link C-libs in properly.
> 
> Could you please submit a sample to bugzilla?
> 
> Andrei

http://d.puremagic.com/issues/show_bug.cgi?id=3564

Thank you.

Leandro Lucarella wrote:

> 
> I guess D can greatly benefit from a compiler that can compile and run a multiple-files program with one command (AFAIK rdmd only support one file programs, right?) and an interactive console that can get the ddoc documentation on the fly. But that's not very related to the language itself, I guess it's doable, the trickiest part is the interactive console, I guess...
>

rdmd does copmile in dependencies, or is that not what you mean?

For the module you are working in, assuming you program with unit tests: rdmd -unittest --main foo.d

When you don't have tons of dependencies, it is practically as fast a scripting language.