okaleniuk

Sure but Grace addresses both writing problems and git problems. That's what makes it interesting.

I am also hopeful for Pijul. But yes, the "if you work alone" backfires for it too. If I work alone, I can adopt Pijul in my work easily, but I don't really want it. If I work within a group then I do want a better VCS, but I should convince the majority of people I work with to switch to the new thing, so essentially I can't switch to Pijul unless there is an undoubtfully good reason to do so. And incremental gains are not a good reason. A "saner" and "better" isn't enough.

On the other hand, we all work alone in between commits (in a broad sense of the term), so having a second tier of a version control, a personal tier, may be a gamechanger.

Oh, that's easy. It is functions, and I didn't get rid of parents around scalars :-)

I also played with the same idea some time ago: https://github.com/akalenuk/fakelisp

I ended up using tuples instead of lists for cosmetic purposes :-) My Fakelisp then looks like this:

    from fakelisp import *
    
    # And now you can start mixing Python and LISP
    X = (BEGIN
        (SET (F) (LAMBDA (X)
            (IF (EQ (X) (1))
                (1)
                (MUL (X) (F (SUB (X) (1)))))))

        (LIST (F (4)) (42)))

    # Back to Python any time
    print "x: ", str(X)

I think, this is a step forward.

I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day.

But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie.

I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.

Sure! https://github.com/akalenuk/mesh-experiments/blob/master/eq/...

It's not even a particularly large system. Only 6 linear equations.

There is a missing variable declaration in the Colab playground.

    y = Expression.var('y')
    e = 1/(x*y+1)
    e = e.derivative(x)
    md(e.to_latex())

I suppose, the first line should be:

    x, y = Expression.var('x', 'y')

There is also a linear solver in the Matrix.

The most obvious use case is to see that the expression does not simplify well and is inherently huge :-)

Can confirm, it is fast. I've been struggling with a plane equation for a plane based on isotropic segments. 3 segments, 3 complex points - only 6 equations. Almost every CAS can solve the system per se fast, it's the simplification process that costs time.

On my machine, I managed to get a ~300KB long solution from SymPy in under a minute, and a comparable solution from Maxima in a few seconds. Symbolica found a ~84K long solution in about a second... in Colab. That's impressive.

Good point. Why not? I'll add them.

Yep, there is a square in the source:

    // interpolation/extrapolation with no basis functions
    var weight2d1 = 2;
    const wf2d1 = function(x) {return 1./Math.pow(x, weight2d1);}

Oh, it seems that a square fell off. It should have been 1/x^2. 1/x works fine for bitmaps, but in 1-dimensional case 1/x indeed turns the whole thing into linear interpolation, you're right.

I like writing HTML + vanilla JavaScript with zero dependencies in any simple text editor. Notepad++ on Windows, gedit or vim elsewhere.

Ah, yes! Fakelisp page references Hylang too, although with a broken link.

Or you can just

    from fakelisp import *

And turn your Python into a Lisp.

https://github.com/akalenuk/fakelisp

Meanwhile, all the pages on https://wordsandbuttons.online/ with all the animation and interactivity are still below 64 KB.

This one, for example, https://wordsandbuttons.online/trippy_polynomials_in_arctang... is 51 KB.

And the code is not at all economical. It's 80% copy-paste with little deviations. There is no attempt to save by being clever either, it's all just good old vanilla JS. And no zipping, no space reduction. The code is perfectly readable when opened with the "View page source" button.

The trick is - zero dependency policy. No third party, no internal. All the code you need, you get along with the HTML file. Paradoxically, in the long run, copy-paste is a bloat preventor, not a bloat cause.

Nice! Didn't know of that. Thanks!

I'm definitely getting one after the war. Have been looking for something RISC-V to play with just recently. Not sure if it's really the first RISC-V Laptop ever since there is also Lichee Console 4a, and it's technically a laptop too. But this one is much better.

Interestingly, I've never heard about cosine interpolation until now. I wonder why? Could it be that in a practical computation, cosine is in fact a polynomial itself and cosine interpolation is a kind of polynomial interpolation with extra steps? Does this also mean that we can "tame" approximating polynomials of high degree by introducing even more degrees?

Fascinating.

An alarming portion of people in software industry can't code. Leetcode or otherwise. This was shocking for me when I started interviewing but it is what it is. Most people just can't code.

I don't like brainteasers and never propose anything remotely intimidating. After all, interview is a stressful affair as it is there is no need to make it any more so. But I'll never hire a person who can't write a few lines of code on demand either.

Academic publishing has a lot of problems, it is an aging institution after all, and it shows. However, reputation-via-affiliation is the only thing that keeps it running.

I thought, this looks like something the company I work for put a hand to. And then I saw a familiar picture in the LinkedIn feed. Yep, that's us: https://www.materialise.com/en/news/press-releases/3d-techno...

I don't challenge the author's use of the word "abstraction", I challenge the validity of the very word "abstraction" in the context of computer science. What we're dealing here is not abstraction, it is something else. But thinking of is as of abstraction brings us to the state of affairs the author criticises.

If you remember that there is very specific very concrete automation behind every abstraction, you don't stack them up until the pile becomes impossible to either control or understand.

Don't get me started on compilers. Compilers don't compile. Linkers compile. Compilers should have been called translators from the start.

I claim that what we call "an abstraction" in software is something else. E. g. while you state that "an abstraction may remain the same abstraction even if you alter its implementation", I insist that the right verb here is "must" and not "may". There is no such thing as "leaky abstraction", "good abstraction", or "an abstraction that only works on x86_64" anywhere else other than in software engineering.

And I'm being nitpicky because the word "abstraction" brings in false connotations. It implies that you can reason about things on different levels as if they were equivalent. But in software, they never are. And I agree with the author in that this pretence of equivalency just doesn't hold and adding more and more abstractions on top of each other is not the way to go if you want to understand how things work and how to make them work predictably and efficiently.

I don't see how my claim diminishes the importance of naming.

Yes. I agree with you wholeheartedly, and that's exactly why I have to insist that the phenomena we're talking about is not an abstraction but something else.

You see, there is no such thing as a "good abstraction" or a "bad abstraction". In math, algebraic systems are either isomorphic or not. There is no qualitative quality to a fact. It is only in software, abstraction acquires this immeasurable quality of goodness, or leakyness, or even fashionability.

"Automation in disguise" is not a good term either. But I find it slightly less misleading and such as it brings less false promises in the connotations.

"Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction.

And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or interpreted? Not really. Should you realize that every automation takes resources, creates accidental knowledge, and introduces its own probability of failure? Yes.

Brick-and-mortar is not a guarantee either. I've got my account frozen by a Hungarian bank in 2015 due to "suspicious activity". I consulted my lawyer, apparently that had no legal grounds, with this information I came to the nearest branch, they unfroze the assets immediately, and I withdrew everything.

In 2022 the bank was proclaimed an international sponsor of war.

20 years ago I'd look for an InstallHook call in a Windows program. There are legitimate reasons to use hooks, but a game should have none.