181–190 of 280 posts
Earlier quoted context omitted.
Probably BeamVM, giving you better options for scaling, abstracting away machine borders and lightweight processes.
BeamVM is much worse than the JVM in the raw computing performances department.
Earlier quoted context omitted.
I've posted this quote before, but it might help explain why making Clojure easier to get into maybe hasn't been a priority for Hickey et al. So we need players. I would rant here, but I won't. But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters.…
I am full to my neckline with Clojure kool-aid: I love the language and programming experience. But the "getting started" your parent is referring to, IMO, is getting the tooling set up, getting the repls connected, figuring out what a full-stack app looks like with its 2 distinct repls and toolchains and lein config mashups, hooking up an editor... and then having it break the next day. After 5 years of Clojure I st…
Earlier quoted context omitted.
On the VM front, I love the JVM, but a vast majority of languages gaining popularity are generating static binaries. GraalVM may help close the gap here. OO is overrated but most apps have some state and I found the entity-component systems solid but not still unwieldy. Clojure has really great concurrency primitives; all the semantics I could want built right in. Except my concurrency often occurs in the persistence…
> Clojure's startup time is pretty brutal for a lot of things I'd like to use it for, and no amount of REPL-driven development can make Clojure appropriate for CLI tools. If you got the repl-driven development down, you wouldn't test your CLI by launching it, you would just evaluate the same functions as the CLI uses. Only time when you'd want to launch the CLI would be before releasing a build or for E2E tests. Once…
GraalVM simply is not production-ready, though I follow its progress with great interest. That said, it's hard to compare the process of integrating with GraalVM against a language that actually just has fast startup.
Babashka is pretty cool, but it's another example of something that isn't quite Clojure. Nice if you can tolerate various "almost the same" languages, but Clojure itself is still weak in these domains.
This looks so awesome! It's got the best parts of a lot of languages. This is what sticks out to me: - Really simple lisp like scheme, but reminds me of lua (and not bloated like CL) - Has resumable fibers, no callcc like scheme - Not missing the lack of lists tbh - A module system that doesn't feel awkward like CL - A built-in package manager (unlike CL) - Good lua and C support - Threads have a shared-nothing appro…
The stack traces have so far been really clean and helpful.
This looks so awesome! It's got the best parts of a lot of languages. This is what sticks out to me: - Really simple lisp like scheme, but reminds me of lua (and not bloated like CL) - Has resumable fibers, no callcc like scheme - Not missing the lack of lists tbh - A module system that doesn't feel awkward like CL - A built-in package manager (unlike CL) - Good lua and C support - Threads have a shared-nothing appro…
It looks like it does have a match macro, and it does destructuring and _: https://janet-lang.org/api/index.html#match
(defn greet [firstname lastname]
(def fullname (string firstname " " lastname))
(string "Hello, " fullname))
(defn greet [firstname lastname]
(let [fullname (string firstname " " lastname)]
(string "Hello, " fullname)))
This looks so awesome! It's got the best parts of a lot of languages. This is what sticks out to me: - Really simple lisp like scheme, but reminds me of lua (and not bloated like CL) - Has resumable fibers, no callcc like scheme - Not missing the lack of lists tbh - A module system that doesn't feel awkward like CL - A built-in package manager (unlike CL) - Good lua and C support - Threads have a shared-nothing appro…
Why was this downvoted? I don't get it :/
Earlier quoted context omitted.
I'm in no way associated with Janet, so I can't answer for them. But as someone who is implementing their own language which shares a lot of goals with Guile, the reason I didn't contribute to Guile is that Guile is an implementation of the Scheme Standard, and it bound at least loosely to that. Certain modern features just aren't compatible and might not be accepted if you go through the effort of implementing them.…
Guile is more than a Scheme implementation. You can implement a completely new language for it (somebody recently did Python) and reuse their embedding capabilities. Guile comes with an Ecmascript implementation, just to show that it can be done.
This goes back to another discussion here: just because you've implemented a language doesn't mean you've implemented it well. Sure, I can implement all the syntax of what I want. But is it fast? Does it report errors well? Am I enforcing my type system, or can I accidentally drop back into normal Scheme?
I think a lot of times new Lispers learn macros and, drunk with their newfound power, start writing 20% implementations that get them 80% to mature languages. And if you don't need or want the other 20% of a mature language, then that's fine. But if you do need or want the other 20% of a mature language, then you'll quickly discover that the Pareto Principle[1] applies. Lisp metaprogramming can be super powerful, but it's not a magic bullet: not only does it not kill werewolves but you can shoot yourself in the foot with it.
[1] https://en.wikipedia.org/wiki/Pareto_principle#In_computing
Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…
Mobile-readable version of your list of Clojure design decisions: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent programs - Leverage the strengths of LISP but give it a modern overhaul (most notably, throw in different…
...but then again, who reads on a mobile device anyway (j/k) ;-)