13 ms·

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

• winter_blue 6y ago
  It’s hard to read the bullet points on mobile — can you remove the indentation so it is formatted normally. Other than that, good points.
• pjmlp 6y ago
  Yet Clojure supports a subset of CLOS, so not so much overrated after all.
  • dkersten 6y ago
    Clojure was never against any of the ideas in OO, just that they should be accessible individually if or when they make sense. Traditional OO is very “all in”, while Clojure is very a-la-carte use the bits that make sense for the problem you are trying to solve. Clojure also encourages a data-over-objects and a functional-first approach, but when you need the OO features, they’re there and you should use them.
    • junke 6y ago
      Just to clarify, CLOS is very a-la-carte too.
    • pjmlp 6y ago
      Even Smalltalk supports the other way around, although very few are aware of it, because they never bother to learn it. You can do LINQ style coding in Smalltalk-80, and modern Smalltalks like Pharo do support traits as well. So the point being that all major languages embrace both paradigms. "Traditional OOP" basically boils down to Java until version 8 or C# until version 3, and very little else, but unfortunately most teachers fail at giving overviews of programming languages thorough computing history, and many just learn what they can reach out for.
      • dkersten 6y ago
        Well, yes, I should have said “popular OO” instead of traditional. I did mean the Java’s and C#’s, Ruby’s and Python’s of the world, not the Smalltalks. > So the point being that all major languages embrace both paradigms. Sure, nowadays, most languages are very much multi-paradigm, but typically there is a dominant paradigm and the others are somewhat second-class. For example, in recent years, Java has gained a lot of functional programming feature too, but its not in the same ballpark as Haskell.
• notRobot 6y ago
  Please don't use code blocks for quotes. It makes it very hard to read text on mobile, narrow viewports or via screen readers.
  • kleiba 6y ago
    Sorry, I didn't even realize that it was a code block when I wrote the post.
• dan-robertson 6y ago
  I feel like a better description of how closure feels as a language would be something like “a functional language where everything is data and that data is flexible”. In particular the difference from a typical strongly typed functional language where basically everything is data you can dig into is that the data representation in closure is more extensible and uniform (because the types are implicit and not enforced)
• varjag 6y ago
  The first point clearly didn't pan out. In reality, applications ended up bundling their own OSes along, so Clojure is stuck with antiquated VM on its ankle for no good reason.
  • nisa 6y ago
    > antiquated VM I'm always flabbergasted about the ignorance against the JVM on this site. There is nothing out there that has seen similiar research and optimisations and has so good monitoring/debugging tools.
    • anonymoushn 6y ago
      My position on the matter might be summarized as "No TCO, no copyable stackful coroutines, no buy." Separately from that a lot of my experience with the JVM involves things like trusting the JVM's claim that it spent 0 microseconds GCing a certain thread that was running code specifically designed to produce no garbage, then running the code in production for one day and losing tens of thousands of dollars, then learning that even if the JVM pauses your thread for 1ms for heap compaction it will still tell you it spent 0 micros on GC.
      • HelloNurse 6y ago
        In other words, on the first day day of testing under realistic load conditions you learned how to measure GC pauses; then, presumably, you were able to improve performance. It shouldn't have happened in a production environment, but setting up a way to lose tens of thousands of dollars if performance is bad, trusting unreasonable numbers, trying to produce no garbage, and requiring no GC pauses because margins are too tight are all your faults, not a shortcoming of your JVM.
        • anonymoushn 6y ago
          Right, we improved the performance by moving the work out of the JVM. It's my fault that if you trade US equities based on old information you lose money? Edit: Actually, I'm still not sure how to correctly measure GC pauses, other than from inside the application.
• galfarragem 6y ago
  What I like in Janet (I'm just a noob so take this comment with a grain of salt as it will sound superficial): - Easy to get started: one click install, great website and concise docs. No matter what some people say, getting started in Clojure is a nightmare. - Lightweight and fresh. No JVM, no Node. - Freedom and expressivity. Mutable or immutable data structures, ultimately is up to me. It might bite me down the road but for now it feels great.
  • flaie 6y ago
    > No matter what some people say, getting started in Clojure is a nightmare. You just need Java installed on your system, then you install clojure (via brew, or sh install) and that's it, you're good to go. I've written a guide to starting with Clojure covering installation to REPL & IDE configuration: https://grison.me/2020/04/04/starting-with-clojure/ https://grison.me/2020/04/04/starting-with-clojure/
    • xiaodai 6y ago
      tried to install Clojure on Windows. Just flat out gave up.
      • pjmlp 6y ago
        1 - Download a JVM and make it available on the PATH 2 - Dowload clojure.jar 3 - Start command.com or PowerShell 4 - cd into clojure installation directory 5 - java -jar clojure.jar
        • pjc50 6y ago
          Of course, that's not the official instructions. These are the official instructions: https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind... - they've managed to work out what the powershell is for "run untrusted shell script directly from HTTPs". What there should be is an exe or MSI installer like every other Windows program.
• blandflakes 6y ago
  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 layer, and unless I'm also writing that layer, Clojure can't help me. Persistent/immutable data structures are amazing. The delimiters IMO are a vast improvement over most other lisps (especially for creating specific data types). 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.
  • capableweb 6y ago
    > 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 you got the code down for your repl and the startup time becomes a hassle, you compile down your Clojure program to a binary with GraalVM and now it starts up fast. Otherwise, give babashka a try. Basically single-binary Clojure environment. https://github.com/borkdude/babashka https://github.com/borkdude/babashka
    • blandflakes 6y ago
      It's not about testing, it's about using it. I know how to use a REPL :) 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.
      • 6y ago
• aasasd 6y ago
  ‘Starts up faster than Clojure’ and ‘doesn't need the setup+compilation voodoo of ClojureScript’ are pretty good value propositions for lightweight runtimes.
• jonstaab 6y ago
  Janet's purported focus is that it's easy to embed in a larger C program. I haven't really seen that in practice, but I have used the C api to write some language extensions, and it is a joy. In comparison with Clojure, I much prefer using either C or janet to using Java and lisp side by side; with Clojure running on multiple hosts now the differences in language semantics between clj and cljs are just annoying. As far as language features, I miss a lot from clojure: immutable/persistent data structures, protocols, not to mention concurrency primitives. But Janet's approach to performance and design is "do less". With the C api you can easily add bindings to some C library that provides a desired feature. But even without that stuff, Janet is for me a python-killer, if not a clojure killer. Edit: at any rate, I think it's not meant to be a competitor to Clojure, its similar syntax just often invites the comparison. It's much more fair to compare it to Lua.
  • playing_colours 6y ago
    > Janet's purported focus is that it's easy to embed in a larger C program. There is Guile https://www.gnu.org/software/guile/ https://www.gnu.org/software/guile/ that is an implementation of Schema with the focus on being an extension language that integrates with C and C++. Wouldn't it more practical to adopt and contribute to it, rather than invent an own wheel?
    • kerkeslager 6y ago
      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. There are real benefits to implementing a standard, and I'm not criticizing Guile for doing that--I use Guile. But if your goals aren't compatible with the standard you have no choice but to go a different way.
      • desiderantes 6y ago
• Stratoscope 6y ago
  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 parenthesis)
  • kleiba 6y ago
    My apologies, it was too late to correct my post when the complaints started coming in. ...but then again, who reads on a mobile device anyway (j/k) ;-)
• didibus 6y ago
  In that respect, Janet doesn't really bring anything very new. Its just an alternative to Lua. Truth is, Lua had pretty few alternative as it stands. When you need something small, fast, to embedd. So Janet is a competitor there.
• jshevek 6y ago
  It looks like you may have inadvertently used the "block quote" ML in your whitespace. It renders terribly on mobile.