Sublime Clojure
tonsky.me
tonsky.me
[1] https://www.reddit.com/r/Clojure/comments/rflhxf/comment/hoi...
But I do not want them inline. I want to use the REPL as a _interactive_ REPL, where I can write my code and later copy that to the file. That's actually one of the reasons I still use Emacs: Common Lisp with Sly and Clojurescript with Cider.
A REPL with Paredit, autocompletion and 'normal' editing capabilities is what I want. That's why I often program other languages (that have a REPL, but no way to comfortably edit using it, like Haskell, PureScript, Elixir, OCaml und Rust) using Jupyter notebooks, which is the same as evaluating inline - that's better than the 'normal' way (only seeing errors/warnings/... inline) but it's not the same experience.
Just write in the normal editor, and evaluate interactively code from there. Emacs does that too
Yes because it's a very nice language, with lot of bells and whistles. Javascript and Java integration are nearly perfect, allowing you to have a access huge ecosystem. No because even though there's progress regarding the error reporting, it's not always simple to parse them. No because you'll have to understand way more Java than you may be willing to. No because it's not Lisp per se. It's nearly a different beast.
Would I recommend it? YES. But know that "Here be dragons"
It also has support for defining & running 'tasks', which makes it useful as a simple build system.
Aren't bad exceptions one of the top issues for new (and old) users? I think solving this is a much bigger deal than you're making it out to be.
Though I made the same point about inline real-time evaluation being better than a REPL recently, and my comment received no such fanfare =(
For instance, when people speak about "the REPL" in the Clojure community they are talking about a live application thats is integrated with the editor like 99% of the time, they don't mean a command-line prompt. All Lisps use REPLs for interactive development in this manner.
People who have not heard of the REBL, can check out this video:
https://www.youtube.com/watch?v=c52QhiXsmyI
> REBL is a graphical, interactive tool for browsing Clojure data.
Are your Clojure tools working, do you understand how deps.edn works?
If you have your clojure tool installed you just put:
:rebl ;; for JDK 11+ {:extra-deps {com.cognitect/rebl {:mvn/version "0.9.242"} org.openjfx/javafx-fxml {:mvn/version "15-ea+6"} org.openjfx/javafx-controls {:mvn/version "15-ea+6"} org.openjfx/javafx-swing {:mvn/version "15-ea+6"} org.openjfx/javafx-base {:mvn/version "15-ea+6"} org.openjfx/javafx-web {:mvn/version "15-ea+6"}} :main-opts ["-m" "cognitect.rebl"]} ;;:rebl-jdk8 ;; for JDK 8 ;;{:extra-deps {com.cognitect/rebl {:mvn/version "0.9.242"}} ;; :main-opts ["-m" "cognitect.rebl"]}
Into your '~/.clojure/deps.edn'.
From there I can just add 'rebl' as a profile to my Intellj when you start a REPL it starts automatically.
There are also alternative tools like Portal to do the same things: https://github.com/djblue/portal
I've been frustrated a bit with the general UX of using emacs, clojure, and REPL since a while now. I keep tweaking my emacs config to improve it one bit at a time, hopefully one day I'll be happy :)
Asking because I still flow somewhere between Emacs/Cider and IntelliJ/Cursive.
This is the only community were I keep seeing the word 'superpower' used repeatedly in most blog posts and forums.
I suspect accessability didn't factor that much into the thought process behind designing that website.
Yellow on black tends to make the writing “shrink” for me, lowering the readability.
Also the switching of the FG and BG colors was just an example I could think of in the moment to get something like "dark mode" with minimal effort. In practice I'd probably go with a somewhat "off-white"(?) FG on a medium-dark grey BG. IMO a less bright white text color in this scenario does well in eliminating the "shrinking" you speak of while the contrast with the muted grey BG isn't too harsh.
We seem to have slightly different access needs. This highlights the richness of working on accessibility problems. No one solution suits everyone, and there isn’t even a “accessible” and “not-accessible” pair that covers all bases either.
For me in general "thin dark fonts on bright BG" and "bright fonts on very dark BG" are both straining to the eyes although the former is worse almost every time. I find myself zooming in further and more often on websites with those sorts of color schemes although if I zoom too far in I then have to swivel my head back and forth for every line of text due to my glasses having "progressive lenses"[0] ie. a pretty narrow cone of vision with the right "power" to read at eye-screen distance.
> testing for these sorts of accessibility issues during development
- IMO a pretty good rule of thumb would be to not cover vast amounts of the website in bright colors
- offer a dark mode, maybe even make it the default with an optional light-mode
- respect the user's browser/system-colorscheme with the CSS property "color-scheme" [1] (although in Firefox the support for that feature is scheduled for the next version this coming January)
[0]: https://en.wikipedia.org/wiki/Progressive_lens
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/color-schem...