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@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
