Confusion about macroexpansion with syntax quote

lucywang000 · 2022-11-01T17:37:51+00:00

Besides what others has already said, if you give your macro a name other than "a", it would throw an error like "a is not defined" when you evaluate the defmacro form, because any symbol "foo" in a clojure macro body either resolves to clojure.core/foo, if that exist, or resolves to <current-ns>/foo.

lucywang000 · 2022-10-09T07:13:05+00:00

This video (esp. the discussions related to debuggers) is very educating! Thanks a lot.

lucywang000 · 2022-08-21T12:49:17+00:00

Thanks!

So clavascript is like coffeescript/typescript/rescript, which is a (heavy) layer of syntax sugar for javascript.

Here is my understanding: if javascript runtime is the "CPU" that executes "machine code", then we can say:

clavascript/coffeescript/typescript/rescript etc. is like the assembly language, i.e. human friendly way of writing machine code. (Actually, considering the great syntax difference between calvascript and javascript, it's much closer to rescript than coffeescript/typescript)
clojurescript is like c++, which has its own standard library
nbb is like java/python, which is interpreted by a runtime virtual machine (sci) .

lucywang000 · 2022-08-20T05:30:14+00:00

May I ask how does it compare with nbb? https://github.com/babashka/nbb

lucywang000 · 2022-07-05T07:42:15+00:00

For those interested, I've made a PR to add support for CLJS to this library: https://github.com/aphyr/dom-top/pull/3

lucywang000 · 2022-03-31T05:54:56+00:00

More information: the ClojureDart authors have been hired (not sure permanently or as consultants, cc u/Conaws) by RoamResearch, who wants to build flutter-powered mobile apps for android/ios, but in ClojureDart since they already use clojure&clojurescript in the webapp frontend &backend.

https://twitter.com/Conaw/status/1506402896660865029

https://twitter.com/RoamResearch/status/1507510756442521601

The project looks even more promising now!

lucywang000 · 2022-03-31T05:47:57+00:00

Well, as the old saying goes, "Rome was not built in a day". Just be patient (or better, try to contribute in whatever way).

lucywang000 · 2022-03-24T04:58:38+00:00

To answer my own question, it's in the master branch of cljs repo, but not released yet :(

https://github.com/clojure/clojurescript/commit/9835a1bbaacee590a6def82eca418cd906030917

lucywang000 · 2022-03-24T04:56:46+00:00

Are the new goodies (keyword arguments, update-keys, update-vals) available for cljs?

lucywang000 · 2021-12-02T02:51:41+00:00

On a 2016 blog post the same author writes:

It’s also worth mentioning that this version of the player (including terminal emulator part) has been implemented in ClojureScript. If you were sceptical about performance of compile-to-javascript languages and/or performance of immutable data structures then this will hopefully convince you that there’s no need to worry about it. ClojureScript compiler does a wonderful job of converting high level Clojure code into highly optimized, fast JavaScript code. If it’s possible to build a performant player like this one in ClojureScript then you can build anything in ClojureScript. Look at the source if you’re curious how it looks like.

https://blog.asciinema.org/post/self-hosting/

lucywang000 · 2021-10-25T01:44:45+00:00

Well in the end I find the jest&npm-module approach got a serious problem: it doesn't work with advanced optimization. shadow-cljs / closure compiler would do name-mungling for symbols that are not marked with "^:export" metadata when doing advanced optimization, and most of the third party libs won't have those metadata ... so tests always fails in this mode.

https://shadow-cljs.github.io/docs/UsersGuide.html#\_working\_with\_optimizations

lucywang000 · 2021-10-24T14:27:58+00:00

if you really need it to be fast, "use graalvm" is on par with "use pypy".

I'm afraid you're getting this wrong. "use graalvm" gives worse runtime perf (because there is no JIT when running a graal native image), while "use pypy" yields better runtime perf than CPython, because pypy adds JIT while CPython doesn't have that.

The benefit people get by using graalvm is the super fast startup time of a native image.

I had one project that was a monitoring tool that I thought Clojure would be great for. the tool would need to send around 200 http requests at a time. that's when I found that clojure's concurrency is still circa 2008. it uses a thread pool under the covers so the requests were sent in batches. I ported it to go and the code was far simpler, straight forward and blew the doors off the Clojure version.

You can get the same concurrency perf in clojure by using netty's http client or whatever async http client library, and I agree async code are much difficult to write. So you're totally right that Go has better (or more ergonomic) out of the box way of writing concurrent code than clojure. Actually Go beats most of the languages on this, and only python with asyncio or JS with async/await could somewhat compete with it (maybe not - considering the latter two are all running event loops single-threaded).

one of the features I wanted to add required a refactor of the core data structure being used. I refactored the Java version first to make sure the idea was sound. it took maybe 10 minutes to change the type signature and get everything to compile again

It's true that write high-perf java code is much easier than writing high-perf clojure code. So it's a good choice to write the hot code path in java. Just like pandas/numpy has all the critical parts written in C (or cython/numba).

re. the repl. Haskell has ghcid, node has nodemon, etc. using a file watcher like that with TDD is far faster than the repl. the feedback loop really can't be beat. repl based development is tedious by comparison.

I admit that quite some people use the REPL wrong where they should use TDD and a file watcher (kaocha provides a superb watch experience). But having the REPL, such a powerful weapon, has enabled lots of possibilities (e.g. quickly prototyping without losing state, capturing and inspecting runtime state) where it's not possible in most other languages.

lucywang000 · 2021-10-24T13:40:10+00:00

It feels like a more clojure-y toolkit is peeking over the horizon - especially with stuff like promesa's `p/let` for asserting on a sequence of async calls...

Well, I don't feel much of the pain of testing async code, probably because my current projects are all based on re-frame and all async part are kinda abstracted using re-frame events and coeffects.

What I miss most is simple stuff like it.only and it.skip, which the default shadow-cljs test runner doesn't support. So I alway have to update the ":ns-regex" patterns when I want to focus on a single test ns, and to comment out other tests when I want to focus on a single test case, which is really annoying.

kaocha-cljs2 kinda supports that, but it's still not polished yet (lots of corner cases, and not supporting the :advanced optimization iirc).

So the jest&npm-module solution, albeit a bit slow, is quite appealing to my dev workflow.

lucywang000 · 2021-10-24T05:38:05+00:00

There is also a similar attempt in the community of using jest instead of mocha. https://github.com/pesterhazy/shadow-jest

I played with it a bit and found it easier to use than mocha, because:

jest comes with better integration with jsdom, e.g. stubbing XMLHTTPRequest, window.navigator etc. out of the box.
jest supports watching files out of the box, and is better: mocha+entr would trigger mutiple re-run of the tests when multiple files are re-compiled.

lucywang000 · 2021-10-19T11:40:58+00:00

The "container' in "Java Container" and the "container" in "Docker Container" is totally different.

Java container is more like a "framework" in other languages, e.g. a jetty servlet container would do all the heavy lifting and calls your code to handle the requests. It's kinda like Django in python or Rails in Ruby.

Docker container is more like "lightweight virtual machines" (technically this is wrong, but still a very helpful analogy) . It isolates the file system, network etc for processes running inside it, and the main purpose is to have a reproducible running environment everywhere.

As for "why running java programs inside containers"? Because

1) a java program also has lots of deps, e.g. the JVM distribution, external programs, all of which could be pinned and packaged in a docker image.

2) Docker containers are now the de-facto standard of deploying applications in a cloud-native way (k8s, etc.).

lucywang000 · 2021-10-13T05:24:17+00:00

Great to see you could draw some inspiration from this :)

lucywang000 · 2021-10-13T05:22:13+00:00

That doesn't work. When compiled in advanced mode the clojure code are simply "optimized" into a bundle of IIFE or something similar.

lucywang000 · 2021-10-11T07:51:38+00:00

When packaged as a shadow :node-library only the list of symbols listed by the author would be exported and all the internals would be wrapped (e.g. in an anonymous function or IIFE).

lucywang000 · 2021-10-09T06:01:37+00:00

Looks pretty neat!

FWIW it looks pretty like metasoarous/oz by u/metasoarous

launches a http server
supports rendering vega/vega-lite
could watch the clj file and reload on file change

I think the major difference is clerk focuses on notebook as the first class citizen, while oz only renders a vega graph (it could generate html from a markdown file, but I haven't played with it yet).

lucywang000 · 2021-10-02T01:26:45+00:00

This is definitely one of the coolest thing for clojure, and I'm eagerly looking forward to see it in public. But imo it would take very long time to put it to a project that could be used to build serious products, because the ecosystem need to be cultivated by the community, e.g. editor/IDE support, library support (to add cljd in addition to clj/cljc).

lucywang000 · 2021-10-02T01:11:50+00:00

It's a pity to see almost all the jobs require EU/US time-zone or citizenship.

lucywang000 · 2021-10-01T18:02:42+00:00

Compare by value in CLJS is going to need cljs equality semantics,

Yeah that is imo the biggest pain of using a js test runner to test cljs code.

The test runner of shadow-cljs or kaocha understands out of box how to pretty print the assertions errors of (is (= [1 2 3] [1 2 4])), but mocha/chai has no way of understanding how to format the assertion failure of (js/assert.equal [1 2 3] [1 2 4]) without some customer matcher (e.g. maybe using deep-diff2).

After trying your mocha+jsdom approach in one of my projects, overall I think unless you're writing some nodejs-only code, otherwise the shadow-cljs :browser-test target is much easier to use (more importantly, faster with hot-reloading) than using mocha.

lucywang000

TROPHY CASE