ClojureDart VS language

> "ClojureDart is production-ready: you can ship applications right now.

Source: https://github.com/Tensegritics/ClojureDart

See a live demo here: https://www.youtube.com/watch?v=dqBeGpuedf0

ClojureDart is very similar to ClojureScript, which the GP is already comfortable with.

Ah, and there is also a new version of Clojure in active development - ClojureDart. It is a port of Clojure language to Dart with the primary goal of using Flutter framework and getting a native mobile and desktop UI.

There is a port of the Clojure language to Dart with Flutter support: https://github.com/Tensegritics/ClojureDart

Now https://github.com/Tensegritics/ClojureDart exist to build GUI with flutter.

There are ways, but it is generally a lot of work, for example there is ClojureDart https://github.com/Tensegritics/ClojureDart . Though unusually that sort of thing is normal for Clojure, because it is a hosted language (Clojure -> JVM, ClojureScript -> JS, etc).

Something to checkout for mobile and desktop is: https://github.com/Tensegritics/ClojureDart

Basically, you take a programming language and make it work on a platform that meant to be programmed using a different PL. Clojure is hosted by design - it's not Java, but can be used to program for JVM. It ain't Javascript, but can be used to target nodejs and browser; not an [official] CLR language, but you can write .Net programs. You can use Clojure to make Flutter apps with ClojureDart. You can integrate Python into Clojure with libpython-clj. Or write Clojure to target Erlang/OTP; or Rust; or R; There's even a clojure-like language for Lua - Fennel.

There's something about Clojure people like so much, they want it to work atop any platform.

https://github.com/Tensegritics/ClojureDart

https://github.com/clj-python/libpython-clj

https://github.com/clojerl/clojerl

https://github.com/clojure-rs/ClojureRS

https://github.com/scicloj/clojisr

https://fennel-lang.org

I noticed that I can enable inline-class as an experiment to play with Extension Types. You need to also add sdk: ^3.3.0-0 to your pubspec.yaml.

Current syntax is not all that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose.

[1]: https://github.com/dart-lang/language/issues/3021

Reference

A future version of Dart will probably support macros which should make this all a bit easier to use, similar to how Swift 5.9 works which makes already fantastic use of its new macro capabilities by integrating mobx (or solidjs) like reactivity into SwiftUI by a harmlessly looking @Obervable annotation.

Coming from a Dart context here where that team is also looking at adding Macros to the language. It was really interesting to compare and contrast some of the approaches https://github.com/dart-lang/language/blob/main/working/macr...

Yes, that needs a bit of boilerplate for the constructor declaration and the extra build method, but I personally don't mind and with implicit constructors this will become much easier. Also, you get a performant UI as Flutter knows to not redraw widgets that didn't change.

I know that it would be nice not to use the generator at all, but we have to wait until static metaprogramming is implemented in dart. https://github.com/dart-lang/language/issues/1482

I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.

I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.

Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):

https://github.com/dart-lang/language/blob/main/accepted/fut...

The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.