mishoo

I can see what happens there in JSCL.. I took a look at

    (disassemble (lambda () (loop for i below (expt 10 8) count t)))

Seems TAGBODY is compiled into a while(true) which sets an exception handler on each iteration. (and then, LOOP macroexpands into a TAGBODY). I don't think there's a better way to do it, BTW — JS is simply not a friendly compilation target. But `try` on each iteration is quite costly, that's most probably the bottleneck here.

Hey, nice to see Ymacs is still used somewhere else than on my website :)

I don't know if you've been tracking it lately, but there was a big overhaul last year [1]. The version in your second link doesn't seem to work in current Firefox. If you'd like to update and need any help, please feel free to get in touch. (also, there's still some of your code in Ymacs :) although I kinda broke filename completion...)

[1] https://lisperator.net/blog/ymacs-reloaded/

Hm, you're right, JSCL seems abnormally slow on this loop (27.5 sec here). SLip consistently takes 19.3 sec. My CPU is rather beefy (Ryzen 9 HX 370). What's your hardware and browser?

But JSCL is much faster on the fib example, that's why I thought it should be generally faster. After all, it compiles to JS.

In SLip: https://lisperator.net/s/slip/

    SL-USER> (time (loop for i below (expt 10 8) count t))
    Evaluation time: 19376ms
    100000000

    SL-USER> (time (loop for i below 1000000 count t))
    Evaluation time: 272ms
    1000000

    SL-USER> (defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
    #'FIB
    SL-USER> (time (fib 32))
    Evaluation time: 1601ms
    2178309

These timings are in Firefox; Chromium is almost 2x faster. Also, it doesn't completely freeze the browser in the mean time (we have green threads).

I used to think it's quite slow, but somehow it's much faster than any other posted here. The only Lisp in browser I know to beat SLip (by a large margin) is JSCL, which compiles to JS.

This isn't an Arch problem, it's a Gnome problem. Extensions break all the time because in order to do anything non-trivial they must use "undocumented" APIs (well, there's no documentation anyway, just a hello world tutorial and then may the source be with you). I know it because I wrote my own extension [1] in order to make this desktop bearable.

After a while, though, I switched to KDE and life's good again.

[1] https://github.com/mishoo/boring-gnome-mishoo.github.com

Now add a Common Lisp compiler to it and you reinvented technology from the 80'es. :-)

You'd be surprised to find out that Common Lisp has actually quite a strong type system (not Haskell-level but much better than C++/Java); just that it's optional. You get the best of both worlds — fast prototyping, and then when you decide upon the types, you can add type declarations, which usually result in (much!) faster code and robustness.

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to fix it, but reloading the page means you start from scratch and need to open again those menus/dialogs, and reconnect the sockets, in order to test your fix.

Common Lisp had true liveness for decades; it's almost mandated by the standard, it's designed in such a way that you can actually recompile a function, or even redefine objects, adding or removing properties or methods, at fucking runtime without restarting the application. Objects already instantiated will remain so and will be updated to reflect the change. You don't restart. That's the true "liveness", but seriously you don't get it until you try it, and once you get it you become depressed because you realize it doesn't really exist in any mainstream language.

JavaScript is some decades behind this dream, even with stuff like Webpack.

Nicely done, but Courier is the ugliest font on Earth (I don't have Monaco). For the sake of humanity, never write "Courier" in a CSS file. ;-)

Emacs, the One True Program.

I do, when I know the types match. Also, I always use == to test if something is either null or undefined; cases where the distinction matters are extremely rare, and this looks too silly: typeof foo === "undefined" || foo === null.

It's not always 10:1, but it seems to be a good average. This happened to me numerous times — I sometimes start with a quick and dirty solution for my problem, then refine and refine until I'm happy with the result, the performance, the code looks beautiful and then I'm like “heck, it's only 100 lines and it took me a week”. In more pathologic cases, I've spent a week just thinking about it, and then I started writing code.

I'm programming for 20 years and I still can't provide good ETA-s for non-trivial problems.

What's wrong with:

    return {
        labels: data.items.map(function(value){
            return {
                type: "label",
                value: value > 10 ? value : value * 100
            };
        })
    };

I hope your project does not get too popular.

Magit must be why Git was invented.

+1, but I tried patiently to move the mouse over the X (close tab button) and clicked a few times... one minute later it closed and I got away without a hard reset.

Agree with Aloha. I wouldn't be too hard on the programmer (also, if I understand correctly it's not a database issue, but only with the 32-bit iOS client). I'd pat him on his back and say “you didn't think we'd get this big, eh?” ;-)

Take a look at Kendo Spreadsheet too: http://demos.telerik.com/kendo-ui/spreadsheet/index

(bias alert: I'm part of the team)

It's not free, but IMO it's the most Excel-like Web-based spreadsheet money can buy. You get support for Excel syntax and formulas, hundreds of Excel functions, XLSX import/export, print-to-PDF, virtual scrolling, OS clipboard integration, etc. — and it all runs in the browser.

I wrote some time back a tutorial on this: http://lisperator.net/pltut/ — but the implementation language is JS, and the language we implement is quite trivial (no objects, inheritance etc.; but does have lexical scope, first-class functions and continuations).

I think Java is ugly, but putting this knowledge in an accessible book is great. Typography is also very nice.

I wrote some similar thoughts here: http://lisperator.net/blog/why-lisp/ (in the "organic growth" section). Sadly I don't get to do much Lisp these days, but it remains my favorite programming language (CL, more exactly).

And yeah, it's sad that "programming-as-teaching" fades out of fashion. Now that I know what it's like, working in an environment that doesn't support it always leaves a bitter taste. Let's just hope more people try it, because it's addictive.

... and then it gets continuations, and that's where it becomes interesting.

Any case, the intent was purely didactic, but I did implement a Scheme dialect based on half of that code. To be released some day...

This is a good point. While I have my doubts that it will be an entirely new browser, by simply renaming it they might be able to offer a version for non-Windows OS-es without making earlier statements seem ridiculous. And they should.

“Microsoft stated that the merging of Microsoft Windows and Internet Explorer was the result of innovation and competition, that the two were now the same product and were inextricably linked together and that consumers were now getting all the benefits of IE for free. Those who opposed Microsoft's position countered that the browser was still a distinct and separate product which did not need to be tied to the operating system, since a separate version of Internet Explorer was available for Mac OS.”

— from http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.

They can't. They said in a court of law that IE can't be separated from Windows.

I wrote a tutorial some time back — http://lisperator.net/pltut/ — also targeted at JS. It walks you through parsing, evaluating, continuations and CPS compiling.

I think both have valid points, but in such a way that Marijn is right.

I did start cool open source projects without crowd-funding. It happened at certain points in my life when I didn't really need extra-money (or when I had sufficient free time — essentially the same thing). It is possible.

Today? I'm not sure I could start anything substantial today without funding. My life is not the same as it was 3 years ago. Things change, and somehow paying the bills gradually becomes harder each day than it was the day before—I don't know why life has to suck this way, but so it happens.

There's quite a narrow frame in everyone's life when one can start major free projects without any income — and I'm probably approaching the end of it. Kudos to Marijn for he manages to do so well, and still provide free tools of outstanding quality! (and in case you didn't notice, the demo is quite impressive — the thing is alive, not vaporware).

On the Antirez side now, it's true that a project without a community is as good as dead (he also mentions evolution and bugfixes, but a community is a prerequisite for that). I certainly have projects that could benefit enormously from having a community — but it just didn't happen, for some reason. (OK, I know why: Emacs and Lisp are Just Not Popular).

Tern is not likely to suffer from lacking a community, because it happens that JS is the most popular language on the planet and Tern solves a Hard Problem. You could think of Tern as the smarter big brother of JSLint. JSLint employs brute-force to find potential mistakes, while Tern employs smartness to help you find real semantic errors, or to improve the way you write code. It's unique. I don't think it'll suffer from lacking community—au contraire, I hope the community won't be as invasive as to murder this project by bringing into it tons of "I'd like my code to look that way" features — but then again, I trust Marijn for being able to trim down feature requests and leave in only what's meaningful, rather than particular use cases; and for particular use cases he will totally be able to make a living by providing custom support and development and this will eventually raise the quality of the project on the whole.

That "added cleverness" is a big story in itself. Linking it with an editor is trivial. If you never tried to do static analysis on a dynamic language like JS you can't really appreciate just how smart Tern is (or wants to be).

See http://lisperator.net/slip/ ;-)

Well, I didn't benchmark specific parts of it, but here's a quick test (that's actually one of my favorite benchmarks now):

The program: (you can run it in the REPL; use C-S-y to paste from OS clipboard):

SS-USER> (defun sum (n) (let rec ((n n) (r 0)) (if (zerop n) r (rec (1- n) (+ r n)))))

SS-USER> (time (sum 100000))

The time spent will be displayed in the ss-output buffer.

Firefox: 6516ms Chrome: 138ms

Parsecs away... :-(

However:

(time (without-interrupts (sum 100000)))

Firefox: 376ms Chrome: 135ms

Still a lot worse than Chrome, but quite a big difference.

without-interrupts ensures that its body runs continuously. Normally we run 200 instructions of each thread, until we get to 50ms, then reschedule for later with setTimeout(0). So that's probably the reason why Chrome seems to do much better—maybe setTimeout is very expensive on FF.

Speed is acceptable in Chrome, but the gap between V8 and other JS engines is stellar. :-\ So I'm afraid it won't be too useful for production use.

There's no debugger yet. It would be fairly easy to step through VM instructions, but to step through source code expressions looks quite complicated. First thing I'd like to do is to have a stack frame inspector.

What's unfortunate is that even the smallest new feature can have a quite dramatic impact on speed...

It's a bit worse than an assembly language, because it doesn't have JMP.