Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Carl Banks wrote:
> On Feb 22, 12:23 am, Jeff Schwab <j... at schwabcenter.com> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 7:17 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
>>>> Carl Banks wrote:
>>>>> On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... at gmail.com> wrote:
>>>>>> There are other downsides to garbage collection, as the fact that it
>>>>>> makes it harder to implement the Resource Acquisition Is
>>>>>> Initialization idiom, due to the lack of deterministic destruction.
>>>>> That's not a downside: it's at least a wash.
>>>>> In C++ you manage memory and the language manages resourcewithout bringing
>> anything of particular value to the table.s.  In
>>>>> Python you manage resources and the language manages memory.
>>>>> RAII is merely one way of minimizing complexity.  Garbage collection
>>>>> is another way.
>>>> If you've already got a generic, language-supported way to manage
>>>> resources (like RAII with deterministic destruction), then why bother
>>>> with garbage collection?
>>> Because now you have to manage memory?  Did you read my post?  You
>>> have to manage one thing or the other.
>> Yes, I read your post.  You seem to be saying there's some kind of
>> trade-off between automatic management of dynamically allocated memory,
>> and automated management of other kinds of resources.  I don't
>> understand why you believe that, so I asked.
>>
>> If you have proper RAII and deterministic destruction, the management is
>> of resources is consistent, and mostly automated.
> 
> If you have garbage collection, the management of memory is
> consistent, and mostly automated.
> 
>> Managing memory is
>> just not that difficult,
> 
> Managing resources is just not that difficult,
> 
>> especially if the vast majority of objects are
>> allocated on the stack or in static memory.
> 
> Especially if the there are fewer resources to manage than there would
> have been heap objects....
> 
>>  A special language feature
>> for managing dynamically allocated memory robs the programmer of a
>> reliable way to clean up resources automatically,
> 
> A special language feature more managing dynamically allocated robs
> the programmer of a reliable way to free memory automatically,
> 
>> without bringing
>> anything of particular value to the table.
> 
> without bringing
> anything of particular value to the table.
> 
> It cuts both ways, chief.
> 
> You like managing your own memory, be my guest.  But please don't
> imply that you're putting forth less effort because of it.  You're
> just putting forth different effort.

I disagree with you completely.  Your points don't make any sense to me 
at all.  I believe I am putting forth less effort by having a generic 
resource-management infrastructure, rather than a memory-specific 
language feature -- that's not just an implication, it's my honest belief.

But I guess we'll agree to disagree.