help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementing advanced scientific calculator.


From: Sebastian Schöps
Subject: Re: Implementing advanced scientific calculator.
Date: Sun, 18 Mar 2018 04:49:18 -0700 (MST)

Dear Sergei, 

you are derailing the discussion and you are giving a student bad advice on
the matter which GSoC project to choose. Furthermore you are stating
questionable facts. I will take the effort to publicly disagree with you. If
you want to continue this debate, then please open a new thread.


Sergei Steshenko wrote
> For example, several years ago I've created a heavily patched 'pkg.m' file
> and Jordy refused to accept it. I also proposed to architecture the
> packaging system - the community did not take the offer. Not only the
> packaging system was broken, but also 'mkoctfile'. I am not saying the
> latter didn't work, I'm saying it was conceptually broken, and this
> created problems in the packaging system.

pkg.m is used by many people every day, so it's obviously not broken.
However, the Octave community knows very well that the package system is not
perfect. There is a GSoC project proposal dedicated to that topic.
Furthermore, there are ongoing discussions, e.g. recently at OctConf 2018,
see the wiki page. In conclusion: your information is outdated.


Sergei Steshenko wrote
> Second, acknowledge that SW evolves, and programming languages evolve.
> Look at number of packages at Julia Package Listing and compare it to the
> number of Octave packages. The number is indicative of contributors'
> interest in the language.

Just counting the number of packages and contributors is not a reasonable
measure, for example this disregards the effort and quality of each
contribution as well as its perspective stability, i.e., how long will Julia
and its packages be maintained? Obviously, finding a good measure how
languages evolve is difficult, but let's have a look to the most recent IEEE
ranking of the top programming Languages: Matlab/Octave is 14th and Julia on
31st position
(https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017).
Python is on 1st rank such that it would be a much more interesting
comparison. However, I guess most Octave developers do not care much about
these statistics and we all use other languages as well (in particular Julia
and Python which is evident if following this mailing list). In conclusion:
your argument is not well established and it's a straw man argument: nobody
dislikes Julia here and we are well aware that it features some interesting
ideas.
 

Sergei Steshenko wrote
> Julia uses LLVM, and IMO LLVM is a reasonable approach.
> Julia can directly call functions written in "C" and "Fortran": Calling C
> and Fortran Code · The Julia Language

Actually, Octave had embraced LLVM before Julia became popular, see
https://wiki.octave.org/JIT (<2012). Recently Julien was looking on this
mailing list for help to improve it. 
  

Sergei Steshenko wrote
> And since many languages have "C" interface

Octave can be interfaced from C and Fortran and vice versa.


Sergei Steshenko wrote
> I do not know what (if any) money is involved in Octave development...

I will not comment on these unfriendly allegations but I ensure everybody
that this is not about money. 

Coming back to the main point of this thread related to the funding
question: if GNU Octave gets GSoC funding then it's our duty to spend that
money on projects that improve Octave itself. Writing a translator to
another language is not in Octave's best interest and such a project has
almost no chance to be accepted. However, improving the LLVM backend would
be. However, this is a very difficult job and I am not sure if there is a
mentor available. If a student is interested, then you may contact Julien.

@Dildar Sk: I do not recommend to base you proposal on a Julia interface.

Regards,
Sebastian



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]