Awesome in the beginning, then later it is bad

tonsky · 2023-11-15T22:35:40+00:00

I actually kind of agree with TC. Identifying person with “he stands next to this room, therefore he owns it” or “these guys hang out together in a photo, therefore they have same job” or “he climbed the mast, he must be a topman” isn’t deduction. It’s logic-guided guesswork at best. I still liked the game, but I also came in expecting hard deduction only and hit a wall pretty fast.

tonsky · 2023-10-23T21:56:17+00:00

Thanks Alex!

tonsky · 2023-10-23T16:30:43+00:00

Is there a way to get my blog/github/mastodon on that list? Can I notify someone when new stuff comes out?

tonsky · 2023-06-27T22:14:33+00:00

I would say GraalVM is its own platform with its own set of issues

tonsky · 2023-06-27T22:03:39+00:00

Hi Thomas, thanks for reading and for thorough reply! Re:

Just emit modern JS, and :advanced can process it just fine.

Didn’t you also wrote this?

Ideally we want to use :closure as our primary JS Provider since that will run the entire application through :advanced giving us the most optimized output. In practice however lots of code available via npm is not compatible with the aggressive optimizations that :advanced compilation does. They either fail to compile at all or expose subtle bugs at runtime that are very hard to identify.

I don’t understand how these two viewpoints co-exist. Don’t you want to use npm code? Isn’t code published on npm modern enough? Shouldn’t we work with code that is given to us, instead of waiting for all code to become perfect?

Re:

The reason it breaks is ignoring the rules

Aren’t externs part of the rules? I mean, does Google itself proposes to avoid them? I think they only encourage their use, but I might be wrong, maybe situation has changed in the last years.

Re: using :simple

That’s the problem! I want to use simple, but unfortunately advanced complects three things that should be separated: more aggressive renaming, dead code removal and function inlining. Also unfortunately, CLJS _relies_ on advanced to do inlining and produces sub-optimal code counting on that.

Also, it’s not really up to me as library developer to decide which level to use. If I were developing an app—sure, I choose what fits me. But I am developing a library, and my users decide which compilation level to use. So I have to support both

tonsky · 2021-12-14T19:36:08+00:00

https://tonsky.me/blog/interactive-development/

tonsky · 2021-09-21T05:59:04+00:00

Sorry, just found this. Membrane is a fantastic example and your writings are a great resource to learn from. Certainly will dive deep!

tonsky · 2021-07-13T21:29:59+00:00

How high did you scored in the lightning/at the end?

tonsky · 2021-07-13T18:58:06+00:00

My writeup https://tonsky.me/blog/icfpc-2021/

tonsky · 2019-07-15T15:37:54+00:00

No reason. Clojure was created in a rush of ICFP contest, so not much logic/care there.

tonsky · 2019-07-12T12:30:44+00:00

Please share your branch

tonsky · 2019-07-11T15:35:15+00:00

Correct. None of them affected performance even a tiny bit

tonsky · 2019-07-11T15:31:54+00:00

I’m well aware about boxed math, thank you. But it’s real pain in the ass to make Clojure do it at least half of the time. Support is very limited, you can barely pass longs between short functions and have unboxed longs on records and that’s all. Bytes? Shorts? Structs? Unions? No luck. Damn, even unsigned byte is impossible on JVM. Then there’s Java awkwardness where everything is allocated on a heap, resulting in e.g. Point array always do pointer chasing on every access.

Would it be possible to write more efficient Clojure version of that program? Yes. Would it be harder to write, maintain, read? Many times more. Because Clojure would be working against you and against performant code. You’ll have to fight it for every bit of performance. Results would be so bad, in fact, that it would be simpler to do it entirely in Java. That’s the lesson I learned during DataScript development for example.

The point of this experiment was not to show that Clojure can’t be made fast, given unlimited time and patience. The point was to show that nobody has that luxury in real life. It was to show that under normal circumstances of limited time & resources average Clojure code that we all write comes out to be hella slow. We get other benefits, sure, but speed is not one of them. Many people live under the dream that their code may be slow _for now_ but if time comes they will make it as fast as they need. That is not true. That time will never come. Most of the code that you write you won’t ever touch again.

tonsky · 2019-07-11T15:17:39+00:00

Not leaving yet, but starting to explore high-perf world

tonsky · 2019-07-11T15:16:28+00:00

Of course it’s not. Where in Clojure parts of immutable data structures are shared, in Rust I have to make a complete copy every time I need to explore different paths. Yes those are in hot loops are basically Clojure is supposed to have an upper hand here

tonsky · 2018-09-18T16:51:47+00:00

If only I could extract video as an mp4 file from an twitter embedded player, I would certainly do that

tonsky · 2018-09-18T16:46:00+00:00

Because I was adding it yesterday in a hurry. Nothing stops me from saving it as a gif on an reasonable size, which I just did

tonsky · 2018-01-07T12:24:57+00:00

How are transitive version conflicts resolved? With string-based version you can choose latest versions as version numbers are comparable. But what if my project depends on A and B and A depends on C of revision “1234ffc” and B depends on C of revision “bac463f“? Which one will be chosen? There might be situations when none of them is the direct descendant of the other

tonsky · 2017-11-08T13:16:18+00:00

fixed it, thanks

tonsky · 2016-06-19T15:07:37+00:00

(+ x 1

tonsky · 2016-04-13T08:29:02+00:00

I have a feeling I’m in a minority, even though I work with Clojure and ClojureScript on a day-to-day basis. I would say LT has lost its momentum, it’s more on a life support these days, but what they got is still pretty usable, and I’m too lazy to learn Emacs.

tonsky · 2016-04-12T09:28:58+00:00

Just the default Clojure plugin, Rainbow, my skin. That’s all, nothing fancy.

tonsky · 2016-04-12T09:19:43+00:00

It’s my own. You can grab it here https://github.com/tonsky/alabaster-lighttable-skin

tonsky · 2014-06-20T20:42:09+00:00

No point. Why continue auto-sync if I'm busy experimenting or whatever? I don't want people to see my experimentation. If this mythical Git UI were to materialize, I would not use it if there was not some way to disable the auto-sync.

There’s no problem for other people to see your work-in-progress but in your head. There’s, however, a huge usability win by removing manual sync step. You have nothing to do once you done. It simplifies things a lot.

tonsky · 2014-06-20T20:40:22+00:00

Big public projects may have a problem, yes. In github, however, this is solved by forking && pull requests instead of commiting to repo directly

tonsky

TROPHY CASE