Walter Bright:

> I meant it in the form of the simpler being better hypothesis.

I see, I have missed that purpose of the discussion... I am sorry.


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

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/


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

Python is simpler than D2, but it's not a simple language, it has many features, etc. A simple language is Scheme :-)


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

That's true, but in practice there's difference from practice and theory :-)
- Are the libs you need to do X and Y and Z actually present and are they working well? It's often possible to find every kind of binding for Python.
- Are those libs powerful? CorePy allows you to write the most efficient code that runs with the SSE extensions.
- Is using those handy, with a nice syntax, with a nice try-test-debug cycle? Python allows for this too, allows to write wrappers with a good syntax, etc. And the shell allows you to try code, etc.

Bye,
bearophile

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.

Yah, I was wondering about that! The hypothesis is there, but the conclusion was the negation of the correct conclusion.

Andrei

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.

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.

Both unit tests and static verification are needed.

Adam D. Ruppe wrote:
> You might say that I should have been more disciplined about [...]

That's the usual excuse for poor language design <g>. What I've been trying to do with D is enable more static verification, so that the project team can rely on enforced guarantees rather than discipline, education, convention, hope and prayer.

Walter Bright:

> Ok, does this work:
> 
>      p = libc.malloc(100);
>      *p = 3;
> 
> ? Or this:
> 
>      struct S { int a; char b; };
>      S s;
>      libc.fillInS(&s);

The purpose of ctypes is to interface Python with C libs, it's a quite well designed piece of software engineering. This is how you can do what you ask for:

from ctypes import POINTER, Structure, cdll, c_int, c_char

libc = cdll.msvcrt # on Windows
# libc = CDLL("libc.so.6") # on linux
malloc = libc.malloc

malloc.restype = POINTER(c_int)
p = malloc(100)
p[0] = 3

#-----------------

class S(Structure):
    _fields_ = [("a", c_int), ("b", c_char)]

s = S()
# AttributeError: function 'fillInS' not found
libc.fillInS(byref(s))

Bye,
bearophile

Walter Bright, el  1 de diciembre a las 13:43 me escribiste:
> 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!

Yes, I know you can use bare C strings, but when I use D, I want to code in D, not in C =)

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

It looks like you can (not as easily) according to bearophile example, but
this is besides the point, you only want to use malloc() for performance
reasons, and I already said that D is better than Python on that.
I mentioned ctypes just for the point of easy C-interoperability.

> >It's simpler, because you only have one obvious way to do things,
> 
> No, Python has try/catch/finally as well.

I said *obvious*. try/catch/finally is there for another reason (managing errors, not doing RAII). Of course you can find convoluted ways to do anything in Python as with any other language.

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

Where is the code complexity here, I can't see it.

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

The thing is, I never used them and never had the need to. Don't ask me why, I just have very few errors when coding in Python. So it's not really *needed*.

> >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 probably right, but I think Python simplicity really helps in reducing bug count. When the language doesn't get in the way it's much harder to introduce bugs because you can focus in what's important, there is no noise distracting you :)

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

Agreed.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I am so psychosomatic it makes me sick just thinking about it!
	-- George Constanza

Walter Bright, el  1 de diciembre a las 13:45 me escribiste:
> 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.

And because you have less noise (and much more and better libraries I guess :) in Python, less complexity to care about.

And don't get me wrong, I love D, because it's a very expressive language and when you need speed, you need static typing and all the low-level support. They are all necessary evil. All I'm saying is, when I don't need speed and I have to do something quickly, Python is still a far better language than D, because of they inherent differences.

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

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

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La terapia no sirve: es mucho mejor pagar para hacer las perversiones
que para contarlas.
	-- Alberto Giordano (filósofo estilista)

Leandro Lucarella wrote:
> Walter Bright, el  1 de diciembre a las 13:45 me escribiste:
>> 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.
> 
> And because you have less noise (and much more and better libraries
> I guess :) in Python, less complexity to care about.
> 
> And don't get me wrong, I love D, because it's a very expressive language
> and when you need speed, you need static typing and all the low-level
> support. They are all necessary evil. All I'm saying is, when I don't need
> speed and I have to do something quickly, Python is still a far better
> language than D, because of they inherent differences.
> 
>>> 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.
> 
> 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...
> 

I'm amazed that virtually nobody uses rdmd. I can hardly fathom how I managed to make-do without it.

Andrei

On Tue, Dec 1, 2009 at 4:37 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Leandro Lucarella wrote:
>>
>> Walter Bright, el  1 de diciembre a las 13:45 me escribiste:
>>>
>>> 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.
>>
>> And because you have less noise (and much more and better libraries I guess :) in Python, less complexity to care about.
>>
>> And don't get me wrong, I love D, because it's a very expressive language and when you need speed, you need static typing and all the low-level support. They are all necessary evil. All I'm saying is, when I don't need speed and I have to do something quickly, Python is still a far better language than D, because of they inherent differences.
>>
>>>> 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.
>>
>> 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...
>>
>
> I'm amazed that virtually nobody uses rdmd. I can hardly fathom how I managed to make-do without it.

The web page[1] says it doesn't work on Windows.  That'd be my excuse for not using it.


[1] http://www.digitalmars.com/d/2.0/rdmd.html

--bb