Re: Implementing advanced scientific calculator.

[Sergei Steshenko]

---

From: Mike Miller <address@hidden>
To: address@hidden
Sent: Friday, March 16, 2018 9:55 PM
Subject: Re: Implementing advanced scientific calculator.

On Fri, Mar 16, 2018 at 10:45:26 -0700, Sebastian Schöps wrote:
> By the way, I do
> not see why it should be of interest for the Octave community to write a
> translator from Octave to Julia?

On Fri, Mar 16, 2018 at 19:03:36 +0000, Sergei Steshenko wrote:

> 1) Julia is a much better language from the point of view of consistency
> and human understanding, so ultimately one should better switch to Julia
> and not lose the ability to use already developed Matlab/Octave code;

I think the implication is that Sergei believes the Octave community
should be spending its time and energy encouraging people to use tools
other than Octave.

--
mike

---------------------------------------------------------------------------------------

"I think the implication is that Sergei believes the Octave community should be spending its time and energy encouraging people to use tools other than Octave" - Sergei believes that the Octave community should first and foremost acknowledge the resounding failures and change its ways.

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.

First of all, reject the "Bazar" part of the "The Cathedral and the Bazaar" infamy.  Octave packaging system of several year ago is a direct consequence of the Bazaar part. And fixing packaging without fixing 'mkoctfile' is impossible

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.

Julia Package Listing

The number is indicative of contributors' interest in the language.

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

Calling C and Fortran Code · The Julia Language

.

And since many languages have "C" interface, this means those languages can be used with Julia too.

So, in essence I suggest the Octave community to stop reinventing the wheels and to use Julia as LLVM (the first 'L' stand for "low", but Julia is not at all low) for Octave.

And it's quite ironic that JWE, the founding father of Octave, now develops SciLab.

Again, IMO in modern world Matlab/Octave language should be just a front tend for something more generic. You probably also know that thanks to LLVM a lot of "C" code can be run in _javascript_ - which, of course, makes it slower, but portable (and it can even be run in a web browser).

I do not know what (if any) money is involved in Octave development. If any money is involved, obviously the grants will be lower for just a front end than for the whole tool. Sergei is aware of It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It | Quote Investigator .

It Is Difficult to Get a Man to Understand Something When His Salary Depend...

, i.e. Sergei doesn't quite expect understanding of this Email from Octave developers. But hopefully young dudes and dudesses interested in Octave will understand it.

--Sergei.