Re: Octave and cargo cult programmingHello

[Sergei Steshenko]

>________________________________
> From: Judd Storrs <address@hidden>
>To: Judd Storrs <address@hidden>; Sergei Steshenko <address@hidden>; 
>"address@hidden" <address@hidden> 
>Sent: 
>Subject: Re: Octave and cargo cult programmingHello
> 
>
>
>
>
>On Wed, Sep 19, 2012 at 3:04 PM, Thomas Weber <address@hidden> wrote:
>
>On Wed, Sep 19, 2012 at 12:48:42PM -0400, Judd Storrs wrote:
>>> In my code, using bsxfun allowed me achieve massive performance gains in my
>>> workload at the price of readability. But now with broadcasting I get the
>>> performance gains without losing readability--in fact it's even more
>>> readable than the loop form! Further, this decision wasn't made lightly and
>>> it was discussed to death. Ultimately, even with broadcasting enabled,
>>> Octave is fully capable of running valid Matlab code. We've been waiting
>>> for someone to show *actual* harm from the change.
>>
>>The example is in the documentation, under "Broadcasting and Legacy
>>Code". If you have code that relies on catching the mentioned error, you
>>can either change Octave's default behaviour or you can change your code -
>>but you cannot run previously working, _unchanged_ code with the
>>_default_ Octave behaviour.
>>
>>And actually I don't think Sergei was wading through Octave's source
>>code to find something to criticise - I bet he has previously working
>>code that doesn't work anymore.
>>
>
>
>Well, I will just put this out there, I've floated IDL features before and 
>they're usually ignored or frowned on in the past. But IDL solves this problem 
>very well.
>
>
>IDL started with some legacy design decisions that were getting in the way. 
>For example, IDL started with () indexing and () function calls. They decided 
>they would prefer the language to migrate to [] for indexing and () for 
>function calls because it would help the VM compiler/optimizer if it could 
>distinguish between function calls from indexing (IDL compiles to an 
>intermediate VM code). There were also additional huge change related to 
>changing the default indexing type from 16bit to 32bit--IDL is more strict on 
>datatypes than Matlab/octave). This of course would break piles of legacy code 
>so it was disabled by default. The way IDL handled this is they introduced a 
>"compile_opt" statement that toggles language features but only within the 
>immediate scope. You could then continue to run unmodified legacy code and 
>enable/disable specific features:
>
>
>COMPILE_OPT STRICTARR  <-- require [] indexing
>COMPILE_OPT DEFINT32 <-- use 32bit indexing
>COMPILE_OPT HIDDEN <-- "hide" the function from the help command
>COMPILE_OPT OBSOLETE <-- calling this function generates a warning
>COMPILE_OPT IDL2  <-- recommended, alias for COMPILE_OPT DEFINT32, STRICTARR 
>
>
>Setting a COMPILE_OPT only affects the current scope--it doesn't affect the 
>scope that called or any of the scopes that it calls, etc. The brilliance of 
>this is that you can easily mix and mash code that conforms to old or new and 
>not worry about new language features breaking legacy libraries.
>
>
>It does actually make me quite uneasy to have to disable the octave:broadcast 
>warning *globally* affecting code that I have not examined (and that I doubt 
>anyone has examined--on the other hand that's what the unit tests are for... 
>at least in the core). If I could just mark octave:broadcast as a default to 
>error but then allow it in individual functions (or even for all functions in 
>a directory), I would be extremely happy. For a lot people, it could make life 
>easier if Octave defaulted to strict Matlab compatibility with an easy way to 
>toggle on octave enhancements on a file-by-file basis.
>
>
>
>
>--judd


Indeed, IDL resolves the problem very decently. COMPILE_OPT is also called 
compiler pragmas in othee languages - I mentioned them.

I don't know IDL, so I don't know what scope is exactly in IDL.

Many other languages have lexical scoping, pragmas often act per lexical scope.



Lack of pragmas/COMPILE_OPT*/whatever you call them just proves my point that 
_strategically_ Octave development is going in a wrong direction.

Normally first the _infrastructure_ is built, and then using it features are 
added. Pragmas are part of infrastructure.

Instead of first building infrastructure Octave developers pile up features.



Regards,
  Sergei.






>
>