[Scilab-users] Matlab vs Scilab perf

[Pierre Vuillemin]

Concerning my assertion that Python outshines Scilab & co in many other 
areas,

  * being a general purpose language, I feel that Python has a broader
    range of application. For instance, for creating a web-app, Scilab
    would certainly not be my first choice, while Python is commonly
    used for that purpose.
  * Python enables to write object-oriented code and has some features
    from functional programming that are quite nice. While Matlab and
    Octave have some "solid" OO features (at least, its enough for what
    I'm doing with it), Scilab is lacking with respect to this point.
    For functional programming, all other environment are far behind
    what Python has to offer. For instance I find that expressions as

        stripped_list  =  [line.strip()  for  line  in  line_list  if  line  !=  ""]

    are really elegant and readable. More generally, manipulating lists
    in python is made really easy.
    I really enjoy lists in Scilab. They feel more coherent to me than
    cells in Matlab, but I wish they had more python-like features.

  * I feel that interfacing with other languages is easier with Python
    than with Scilab/Matlab/Octave.
  * Packages, modules and namespaces enable to create very clear structures.

Besides, I could not agree more with you concerning bad 
syntaxes/redundancy. Having a coherent environment is important.

A step towards this goal may be to update and complete the code 
convention for Scilab 
<https://wiki.scilab.org/Code%20Conventions%20for%20the%20Scilab%20Programming%20Language?action=info> 
in a similar fashion to Python PEP 
<https://www.python.org/dev/peps/pep-0008/>?

Regards,

Pierre

Le 02/03/2017 à 23:23, Samuel Gougeon a écrit :
> Hello Ricardo,
>
> Le 02/03/2017 à 19:33, Ricardo Fabbri a écrit :
>> Speaking from experience:
>>
>> It is worth mentioning that in many ways performance is not critical
>> for a "lab" language like Scilab or Matlab. It is just an extremely
>> simple language to test concepts and algorithms at a very small scale
>> of granularity. The real crucial factor for Scilab or Matlab is the
>> GUI for exploring data and developing algorithms interactively. Once
>> you have a working solution, you'll fit it inside a bigger and more
>> relevant
>> system by porting promptly to a language like C++ for scalability and 
>> speed.
>>
>> Just use Scilab for what its worth, don't obsess with speed, even
>> though it is important.
>
> I agree: Matlab, Scilab, Octave, IDL, GDL.. Yorick etc were and are 
> still first made for prototyping, not for speed. This is why they were 
> back to interpreted -- and so slower -- languages.
> But they should not have any handicapping snail instructions for 
> common frequently used ones like scf(). Loosing time gained with an 
> easy language avoiding to declare each object type and to compile and 
> link the whole thing each time that we change a semicolon in the 
> code... would be meaningless.
>
> So yes, i definitely agree: it is a matter or ergonomic for GUIs but 
> also and first for the language (regular namings, rational order of 
> arguments, etc) that make it easy to learn and use. This is somewhat 
> why i never really got inside python (and sciPy). I felt its syntax 
> not straightforward to learn, even for simple things. Same thing for 
> R. And it's always the same feeling when i try to compare results from 
> these various languages -- including javascript --, for instance to 
> extend Scilab or debug it, seeing usages or conventions the most used 
> elsewhere. Each time, it is quite harder for me to find and understand 
> the relevant syntax with Python and R, while for instance i find 
> javascript more intuitive.
> This is why i don't know much about Python. When Pierre writes "Python 
> outshines Scilab/Octave/Matlab in many other areas.", i would be 
> interested to know more about that.
>
> I agree with you, Pierre, about the whole environment. This is why, on 
> this aspect, we could have a specific discussion about which modules 
> -- with which components -- should rather compose "Scilab core", and 
> which features could be distributed rather on ATOMS. I am not 
> convinced that the current "Scilab core" composition is optimal. IMO, 
> it is quite unbalanced by historical or particular influences.
>
> As a conclusion, i think that introducing non-optimal syntaxes or 
> duplicates etc in the language hurts much more than introducing a 
> quite slow algorithm. Simply because the algorithm can be changed 
> later without breaking anything, while introducing badly designed 
> syntaxes or usages is much harder to manage afterwards, and impedes 
> much more learning, using and maintaining the language.
>
> Best regards
> Samuel
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20170304/9bc432ef/attachment.htm>