bearophile wrote:
> 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

Doable, yes, simple, no. For example, it's clear it cannot be linked directly to C. The C code must be installed into a shared library first.

Leandro Lucarella wrote:
> 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.

To me C interoperability means being able to connect with any C function. That means handling pointers, structs, etc.


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

try/catch/finally is usually used for handling RAII in languages that don't have RAII, so I don't think it's really justifiable to argue that Python only gives one obvious way to do it.

D has three: RAII, scope guard, and try-catch-finally. As far as I'm concerned, the only reason t-c-f isn't taken out to the woodshed and shot is to make it easy to translate code from other languages to D.


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

The code complexity is suppose I create a mutex object. Every time I get the mutex, I want the mutex to be released on all paths. With RAII, I build this into the mutex object itself. Without RAII, I have to add in the exception handling code EVERY place I use the object. If I change the abstraction, I have to go and change every use of it. To me, that's code complexity, not flexibility.

A proper abstraction means that if I change the design, I only have to change it in one place. Not everywhere its used.


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

I agree that static analysis isn't needed. The better statement is is there a benefit to it that exceeds the cost?

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

On Tue, Dec 1, 2009 at 5:08 PM, Bill Baxter <wbaxter@gmail.com> wrote:
> 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

Seems like it does work, though.  Good news!
The web page should be updated.

I will definitely use it now that I know it works.

It does seem to hang at the end of output waiting for an Enter from the console.
And the á in the --help message doesn't show properly on the console
either. (but actually it does work if I chcp 65001 first).
And the --man browser thing doesn't work at all.  I think you need to
do some registry diving to find the browser under Windows.

You can open a url in the default browser with this magic code:

import std.c.windows.windows;
extern(Windows) {
   HINSTANCE ShellExecuteW(HWND,const LPWSTR, const LPWSTR, const
LPWSTR, const LPWSTR,INT);
}

void main()
{
    HINSTANCE hr = ShellExecuteW(null, "open"w.ptr,
"http://www.digitalmars.com/d"w.ptr, null, null, SW_SHOWNORMAL);

}

--bb

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> D has three: RAII, scope guard, and try-catch-finally. As far as I'm concerned, the only reason t-c-f isn't taken out to the woodshed and shot is to make it easy to translate code from other languages to D.

I've literally never written a finally block in my life in D because scope statements and RAII are just that good.  Does anyone, other than a few beginners who were unaware of scope guards, use finally?  I'm half-tempted to say we should just axe it.  It's an error prone legacy feature that's completely useless for any purpose except writing Java or C# code in D.  Since we're looking to lighten the spec, ditching finally would do so, and it would encourage converts from Java and C# to learn a better way of doing clean-up code.

Walter Bright, el  1 de diciembre a las 17:31 me escribiste:
> Leandro Lucarella wrote:
> >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.
> 
> To me C interoperability means being able to connect with any C function. That means handling pointers, structs, etc.

Well, you can. It's a *little* more verbose than D, but since you almost *never* need to interoperate with C in Python, it's not so bad.

> >>>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.
> 
> try/catch/finally is usually used for handling RAII in languages that don't have RAII, so I don't think it's really justifiable to argue that Python only gives one obvious way to do it.

It's obvious when you code in Python.

> D has three: RAII, scope guard, and try-catch-finally. As far as I'm concerned, the only reason t-c-f isn't taken out to the woodshed and shot is to make it easy to translate code from other languages to D.

I think code translation from other languages is not a good reason for adding complexity...

> >>>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.
> 
> The code complexity is suppose I create a mutex object. Every time I get the mutex, I want the mutex to be released on all paths. With RAII, I build this into the mutex object itself.

But you can do that with the 'with' statement!

> Without RAII, I have to add in the exception handling code EVERY place I use the object. If I change the abstraction, I have to go and change every use of it. To me, that's code complexity, not flexibility.
> 
> A proper abstraction means that if I change the design, I only have to change it in one place. Not everywhere its used.

We agree completely :)

> >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*.
> 
> I agree that static analysis isn't needed. The better statement is is there a benefit to it that exceeds the cost?

Maybe in very big projects with an heterogeneous team, I don't know.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si pensas que el alma no se ve
el alma sí se ve en los ojos

dsimcha wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> D has three: RAII, scope guard, and try-catch-finally. As far as I'm
>> concerned, the only reason t-c-f isn't taken out to the woodshed and
>> shot is to make it easy to translate code from other languages to D.
> 
> I've literally never written a finally block in my life in D because scope
> statements and RAII are just that good.  Does anyone, other than a few beginners
> who were unaware of scope guards, use finally?  I'm half-tempted to say we should
> just axe it.  It's an error prone legacy feature that's completely useless for any
> purpose except writing Java or C# code in D.  Since we're looking to lighten the
> spec, ditching finally would do so, and it would encourage converts from Java and
> C# to learn a better way of doing clean-up code.

I'm sympathetic to that point of view, but it is pure drudgery to unwind try-catch-finally into proper scope statements.

Leandro Lucarella wrote:
> I think code translation from other languages is not a good reason for
> adding complexity...

I think it is. We wouldn't have DWT otherwise, for example. Inner classes were added specifically in order to speed up the translation process.


>> The code complexity is suppose I create a mutex object. Every time I
>> get the mutex, I want the mutex to be released on all paths. With
>> RAII, I build this into the mutex object itself.
> 
> 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.

Bill Baxter wrote:
> 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

rdmd does work for Windows. What it does is to detect and cache dependencies such that you only need to specify your main file.

Andrei

Bill Baxter wrote:
> On Tue, Dec 1, 2009 at 5:08 PM, Bill Baxter <wbaxter@gmail.com> wrote:
>> 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
> 
> Seems like it does work, though.  Good news!
> The web page should be updated.
> 
> I will definitely use it now that I know it works.
> 
> It does seem to hang at the end of output waiting for an Enter from the console.
> And the á in the --help message doesn't show properly on the console
> either. (but actually it does work if I chcp 65001 first).
> And the --man browser thing doesn't work at all.  I think you need to
> do some registry diving to find the browser under Windows.
> 
> You can open a url in the default browser with this magic code:
> 
> import std.c.windows.windows;
> extern(Windows) {
>    HINSTANCE ShellExecuteW(HWND,const LPWSTR, const LPWSTR, const
> LPWSTR, const LPWSTR,INT);
> }
> 
> void main()
> {
>     HINSTANCE hr = ShellExecuteW(null, "open"w.ptr,
> "http://www.digitalmars.com/d"w.ptr, null, null, SW_SHOWNORMAL);
> 
> }
> 
> --bb

Thanks! Could you please submit that to bugzilla?

Andrei