Spirit of Kirkby

[Ralf Stephan]

While Mr Kirkby seems willing to conjure the Spirit of Sage using a
slur, for which he probably can demand a good tipoff from some companies,
I haven't seen much work by Kirkby done on Sage, lately. Rather, one
of his latest fix points was Sparc support---which demands a bit of
spirit to be done; not by himself, mind you---, a pattern? If so, what
would be next in the dirt campaign?

On the other hand, it could be just a harmless Freudian. You know, too
much of some special spirits. But then, that pattern will repeat, too.

So, make sure to have some popcorn handy, as things unfold.

[rjf]

For those encountering this message here without first seeing the context,

you can find this on the   sage-devel google group of this approximate date.

I don't know how to copy a thread or link to it from here, but maybe someone

else would do so if it is possible.

It seems to involve an objection to the (non) GPL licensing of

 closed-source code for Sage Cloud. 

I suspect that none of us are lawyers here, and I really don't care

to read up on what has transpired.  If someone wants to summarize

for sage-flame, that might be useful. I suspect it would be

premature for me to say, "I told you so."  But in the interests of

fanning the flames, I might say so. :)

[Bill Hart]

Oh, you haven't read William's blog post yet in reply to this. Shame.

Time to fire up the barbeque. A bag of chips won't be enough for this round.

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-flame.
For more options, visit https://groups.google.com/d/optout.

[rjf]

On Tuesday, August 19, 2014 7:38:25 AM UTC-7, Bill Hart wrote:

Oh, you haven't read William's blog post yet in reply to this. Shame.

I just read it.

A quote from  William's blog.

Measured by the mission statement, Sage has overall failed.  

There's more context that could be read, of course.  Sage has had some

technical success.

 But maybe it is not premature to go

review my earlier statement of skepticism.  See link below.   

But to broaden the discussion, I find the blog post amusing in that it mentions

a substantial number of software tools that I have never heard of previously.

Many lines of code in this or that.  Does this represent a disinclination to

use Python, or a failure of python to satisfy some need?  I've not written

particularly hairy web-hosting back ends, and I haven't done any new

web-sites in at least 8 years.  But they were all done using Lisp.

True, someone else made interfaces from Lisp to (whatever.. Apache??)

but I didn't have to learn that.

Back to the main subject ... (not Kirby, but Sage/ failure??)

It is not that I disagree with a goal of making good software available

for the "arithmetization" of as much of mathematics as possible.

It is not that I disagree with the tactic of linking together the best

existing software  (though I think it Sage has demonstrated that this

is more difficult than it might seem at first).  It is hard enough to

build one advanced computer "algebra" system to be self-consistent,

much less several.

But it seems that at least some of the concerns voiced circa 2005 

appear relevant.  (here's a link...)

http://sci.tech-archive.net/Archive/sci.math.symbolic/2005-12/msg00096.html

[Robert Bradshaw]

On Tue, Aug 19, 2014 at 8:12 AM, rjf <fat...@gmail.com> wrote:
>
>
> On Tuesday, August 19, 2014 7:38:25 AM UTC-7, Bill Hart wrote:
>>
>> Oh, you haven't read William's blog post yet in reply to this. Shame.
>>
>
> I just read it.
>
> A quote from William's blog.
>
> Measured by the mission statement, Sage has overall failed.
>
> There's more context that could be read, of course. Sage has had some
> technical success.

Yeah, that's a bit of a hyperbole, but not entirely false as Sage
certainly has not lived up to it's potential and looks like it's
exited its exponential growth phase.

> But maybe it is not premature to go
> review my earlier statement of skepticism. See link below.
>
> But to broaden the discussion, I find the blog post amusing in that it
> mentions
> a substantial number of software tools that I have never heard of
> previously.
> Many lines of code in this or that. Does this represent a disinclination to
> use Python, or a failure of python to satisfy some need? I've not written
> particularly hairy web-hosting back ends, and I haven't done any new
> web-sites in at least 8 years. But they were all done using Lisp.
> True, someone else made interfaces from Lisp to (whatever.. Apache??)
> but I didn't have to learn that.

I seriously doubt the choice of language is the primary (or even a
significant) cause of failure here.

> Back to the main subject ... (not Kirby, but Sage/ failure??)
>
> It is not that I disagree with a goal of making good software available
> for the "arithmetization" of as much of mathematics as possible.
>
> It is not that I disagree with the tactic of linking together the best
> existing software (though I think it Sage has demonstrated that this
> is more difficult than it might seem at first). It is hard enough to
> build one advanced computer "algebra" system to be self-consistent,
> much less several.
>
> But it seems that at least some of the concerns voiced circa 2005
> appear relevant. (here's a link...)
>
> http://sci.tech-archive.net/Archive/sci.math.symbolic/2005-12/msg00096.html
>

[Bill Hart]

He's talking about the languages SMC is written in, not Sage. Unless you think SMC is already failing!

Python may not have anything to do with "failure" as defined by William, and may have been the right language to write Sage in. But it is a weak choice of language for a CAS because you spend a good percentage of your time writing code to do what a type checker with a proper dependent/parametric type system would do for you, such as implementing a dependent type system and coercion system. 

Python also performs poorly and doesn't interface with C efficiently, so you can only implement parts of the project in Python and need to use other languages for the rest.

I have been writing an interpreter for flint in Julia, recently. It has a proper dependent type system (though is still dynamic like Python). It has a Jit and C-like performance. It also interfaces more or less efficiently with C. 

With just Julia and flint, multivariate polynomial multiplication is already 3x faster at the Fateman benchmark than Sage. And that's nothing to do with flint, since we are both using flint. It's also nothing to do with the algorithm. The speed I'm getting with Julia + flint matches an implementation of generic rings in flint itself, written in C.  

One can do much better. I've been writing my own language for that. In one microbenchmark  I do15x better than I can do with Julia + flint.

The technology to beat the big MA's doesn't exist yet. But it is coming. I predict it will be here by 2018-2024.

SMC is a great idea. To take on the big MA's you need to be able to throw money at problems that aren't going to go away by ignoring them.

Bill.

[Bill Hart]

Oh, I should also mention, just for the funzies, given the audience and all:

* The original Julia interpreter was written in a variant of Lisp called Femtolisp (it is self-hosting nowadays of course)

* Julia was inspired by Lisp

* Like Lisp, Julia has metaprogramming features, such as macros, symbols, quotes, a REPL, and many other lispy things

* Like many Lisps, Julia uses incremental compilation

* Unlike Lisp, Julia does not have Lots of Irritating Superfluous Parentheses

Just sayin'

Bill.

[Richard Fateman]

On 8/19/2014 9:58 AM, Bill Hart wrote:
> Oh, I should also mention, just for the funzies, given the audience
> and all:
>
> * The original Julia interpreter was written in a variant of Lisp
> called Femtolisp (it is self-hosting nowadays of course)
> * Julia was inspired by Lisp
> * Like Lisp, Julia has metaprogramming features, such as macros,
> symbols, quotes, a REPL, and many other lispy things
> * Like many Lisps, Julia uses incremental compilation
> * Unlike Lisp, Julia does not have Lots of Irritating Superfluous
> Parentheses
>
> Just sayin'
>
> Bill.
>

So what prevents a Lisp system from compiling into something as fast as
Julia?
I've seen Lisps that run really fast until you overrun a stack or
require a garbage collection.
RJF

[Bill Hart]

On 20 August 2014 04:04, Richard Fateman <fat...@berkeley.edu> wrote:

On 8/19/2014 9:58 AM, Bill Hart wrote:

Oh, I should also mention, just for the funzies, given the audience and all:

* The original Julia interpreter was written in a variant of Lisp called Femtolisp (it is self-hosting nowadays of course)
* Julia was inspired by Lisp
* Like Lisp, Julia has metaprogramming features, such as macros, symbols, quotes, a REPL, and many other lispy things
* Like many Lisps, Julia uses incremental compilation
* Unlike Lisp, Julia does not have Lots of Irritating Superfluous Parentheses

Just sayin'

Bill.

So what prevents a Lisp system from compiling into something as fast as Julia?

I don't understand the question. Why would you want to compile from a language without a syntax into one that has one? I'm sure I'm misunderstanding. But the answer is probably "nothing, bar a couple hundred man hours".

 

I've seen Lisps that run really fast until you overrun a stack or require a garbage collection.

Julia has some gc issues. I've explained how to make them go away in cases I'm interested in. We'll see what comes of it.

Julia also overruns the stack if you are stupid. But it's much safer than C on the whole.

 

RJF

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+unsubscribe@googlegroups.com.

[Richard Fateman]

On 8/19/2014 8:19 PM, Bill Hart wrote:

On 20 August 2014 04:04, Richard Fateman <fat...@berkeley.edu> wrote:

On 8/19/2014 9:58 AM, Bill Hart wrote:

Oh, I should also mention, just for the funzies, given the audience and all:

* The original Julia interpreter was written in a variant of Lisp called Femtolisp (it is self-hosting nowadays of course)
* Julia was inspired by Lisp
* Like Lisp, Julia has metaprogramming features, such as macros, symbols, quotes, a REPL, and many other lispy things
* Like many Lisps, Julia uses incremental compilation
* Unlike Lisp, Julia does not have Lots of Irritating Superfluous Parentheses

Just sayin'

Bill.

So what prevents a Lisp system from compiling into something as fast as Julia?

I don't understand the question. Why would you want to compile from a language without a syntax into one that has one? I'm sure I'm misunderstanding. But the answer is probably "nothing, bar a couple hundred man hours".

No, I wasn't suggesting that one take lisp and translate it into Julia.


Let me rephrase:
  Someone has written a compiler for a language J which seems to be like lisp.  J compiles into very efficient assembly code (I guess).
In the past 55 years, why is it that no one has written a compiler for lisp that compiles into similarly efficient assembly code?

 

I've seen Lisps that run really fast until you overrun a stack or require a garbage collection.

Julia has some gc issues. I've explained how to make them go away in cases I'm interested in. We'll see what comes of it.

Julia also overruns the stack if you are stupid. But it's much safer than C on the whole.

I suppose that if you remove checking from Lisp systems then they might be faster. Remove all argument checking. Twice as fast? maybe.

There was a super-fast lisp written for the VAX 780 computer at Bell Labs Holmdel that did no checking for anything.
It was, as far as I know, not used for anything except talking points.

 

RJF

--
Y

[Bill Hart]

On 20 August 2014 06:25, Richard Fateman <fat...@berkeley.edu> wrote:

On 8/19/2014 8:19 PM, Bill Hart wrote:

On 20 August 2014 04:04, Richard Fateman <fat...@berkeley.edu> wrote:

On 8/19/2014 9:58 AM, Bill Hart wrote:

Oh, I should also mention, just for the funzies, given the audience and all:

* The original Julia interpreter was written in a variant of Lisp called Femtolisp (it is self-hosting nowadays of course)
* Julia was inspired by Lisp
* Like Lisp, Julia has metaprogramming features, such as macros, symbols, quotes, a REPL, and many other lispy things
* Like many Lisps, Julia uses incremental compilation
* Unlike Lisp, Julia does not have Lots of Irritating Superfluous Parentheses

Just sayin'

Bill.

So what prevents a Lisp system from compiling into something as fast as Julia?

I don't understand the question. Why would you want to compile from a language without a syntax into one that has one? I'm sure I'm misunderstanding. But the answer is probably "nothing, bar a couple hundred man hours".

No, I wasn't suggesting that one take lisp and translate it into Julia.


Let me rephrase:
  Someone has written a compiler for a language J which seems to be like lisp.  J compiles into very efficient assembly code (I guess).
In the past 55 years, why is it that no one has written a compiler for lisp that compiles into similarly efficient assembly code?

 

I would say that SBCL is relatively good in this regard. It didn't quite cut it for me, for various reasons. But it's ok.

 

I've seen Lisps that run really fast until you overrun a stack or require a garbage collection.

Julia has some gc issues. I've explained how to make them go away in cases I'm interested in. We'll see what comes of it.

Julia also overruns the stack if you are stupid. But it's much safer than C on the whole.

I suppose that if you remove checking from Lisp systems then they might be faster. Remove all argument checking. Twice as fast? maybe.

Easily. I tried this and more using SBCL.

 

There was a super-fast lisp written for the VAX 780 computer at Bell Labs Holmdel that did no checking for anything.
It was, as far as I know, not used for anything except talking points.

Of course.

Julia does checking by the way. I would turn it off, but they hid the switch so deep inside it that I can't find it, after I last switched it off.

 

 

RJF

--
Y

--
You received this message because you are subscribed to the Google Groups "sage-flame" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-flame+...@googlegroups.com.