I've used Clojure for going on 10 years now and it has been one of the most enjoyable programming languages I've ever used. But I've gone back to Scheme for a few ridiculous reasons.
1. TCO. Using `recur` in Clojure just breaks my thought process.
2. Difficulty in getting down to the metal when needed. Using JNI is painful. In Scheme, when needed, the FFI usually handles plain old C. Much easier in my opinion.
3. Community. Rich is a really smart guy and has made great contributions, but he doesn't suffer fools lightly and I am a fool. Great for a scientist, not so much for a "benevelent dictator for life" of a programming language.
4. Pragmatism over correctness. There was a long running conflict about some set operations that did not return correct results. To my mind, there is no argument against correctness.
5. Slow startup. Not always a problem except when it is.
6. ClojureScript. Could be my unfamiliarity with ClojureScript/JavaScript, but I find I have to revert to JavaScript too often to get something done. And if I can't just use ClojureScript, why use ClojureScript?
Like any Lisp, Scheme is easier to read than Python, Java, JavaScript, Haskell, PHP, Perl, Fortran, Forth, APL, etc. Pascal is pretty good in this regard though. Clojure might actually be better in my opinion.
Why not Common Lisp? It's pretty good and at least as powerful. The warts annoy me though.
So I will continue using Scheme while looking into Janet https://github.com/janet-lang/janet. Janet has most of the things I like about Scheme _and_ Clojure. More experience will tell. I just miss the way maps are handled in Clojure.
Yes. Chez Scheme in particular is a remarkable implementation. Idris 2 for example (a leaner, dependently typed relative of Haskell) relies on Chez Scheme.
As a mathematician I don't need a large ecosystem of other people's work. What keeps drawing me back to Haskell is the experience of reasoning about code paradigms as if they are a branch of algebra (not everyone appreciates algebra, but those who do can never turn around), and a support for parallel code that is decades ahead of any other language I have tried.
I don't understand arguments of the kind: "Lisp A vs. Lisp B". A Lisp is a Lisp. I am honestly so grateful for my younger self for the decision I made years ago to learn Lisp. These days, pretty much any platform, any hardware, or a VM supports at least one dialect of Lisp. And that's awesome!
I switch between Lisps with relative ease: Scheme, Fennel, Clojure, Elisp, Common Lisp - they feel pretty much the same language. Yes, each has its own oddities and quirks, but I still feel like if I'd discovered some ancient secret - learn it and you start understanding every possible human language. That's how knowing and "breathing" Lisp feels sometimes.
Because Lisp is not a language. It's an idea. An incredibly awesome one. Arguably - the most influential idea in Computer Science. "Once in a millennia" idea.
That's why I never feel anxious about the popularity of programming languages. I don't care what's in the top of RedMonk or TIOBE or whatever else. I don't care if some new programming language gets promoted by the Queen of England, Supreme Pontiff, or Dalai Lama. If it's not a Lisp - it has an expiration date. Lisp, though, will never die.
I think of the "Lisp A vs. Lisp B" discussions like describing the nuances of you favorite color. My favorite color is yellow, but that covers a lot of ground. I prefer a nice bright lemon yellow, but don't care for mustard yellow or brown as much. But any Lisp is better than Fortran just as I prefer any yellow over purple, for example.
I prefer Scheme to most other Lisps because of guaranteed TCO, the way continuations are handled, regularity of function names, and define-syntax macros.
Within the Scheme family, I usually prefer Chez for its performance, its FFI and because I happen to prefer an R6RS compliant system at the moment.
> I don't understand arguments of the kind: "Lisp A vs. Lisp B". A Lisp is a Lisp. I am honestly so grateful for my younger self for the decision I made years ago to learn Lisp. These days, pretty much any platform, any hardware, or a VM supports at least one dialect of Lisp. And that's awesome!
“Lisp” is no more a language family than “curly braces" is. Individual Lisps are often further apart from each other than either from various other languages.
Curious, because I'm also doing Scheme now, and Clojure was my gateway drug, which Scheme are you using and for what sort of problem? I'm using s7, but that's because my use case is very much oriented to s7's non-typical feature set (it's computer music), but Janet looks really nice too. (Many similarities to both Clojure and s7 actually).
Mostly Chez. Racket is remarkable too -- I have never felt that I was stretching its capabilities. Enjoying Janet, trying to get over Clojure habits where the two differ.
Most of my career has been involved in medical diagnostic, data analysis, and desktop applications. Hobby projects include text processing, editors, outliners, wikis, and knowledge management.
Interesting, Clojure was my gateway drug to CL. I wonder how common it is for people who come to Clojure but get warned off by the JVM to migrate further down the lisp road?
If you would prefer something more "lispy", you can do just about anything on top of [Emacs](https://www.gnu.org/software/emacs/) (with the possible exception of making it pretty.)
Depending on your application and familiarity with the IDE, using the base under one of these (or other) IDEs could save you tons of time.
Clojure is a very pleasant language to develop in. I have found it easier to develop a JavaFX-UI program in Clojure than in Java.
If you want to go the route of running a server on the user's machine and serving it through the user's browser, ClojureScript and Reagent/Re-Frame are excellent choices. Re-Frame, https://github.com/Day8/re-frame, in particular has very nice documentation.
Clojure lets you use anything in the Java universe while ClojureScript gives you access to all the JavaScript stuff, including Node.
There is a lot of tutorial information for both languages.
Clojure is a fantastic language, as far as dynamically typed languages go. ClojureScript turned me off to both languages however. I routinely encountered scenarios where accidentally passing values of the wrong type to core standard lib functions produced wildly unexpected behavior that would take hours or even days to debug. Reporting these issues almost always resulted in “don’t do that WONTFIX”, and often very hostile responses if I pressed the issue or even offered to contribute a fix. Ultimately I decided I’d be more productive in a language that embraces correctness as a core feature. And ultimately that led me to take the great FP techniques and philosophy I learnt in clojure and apply them as idiomatically as I could in a statically types language. Now most of my work is in TypeScript, and while I miss a lot of what Clojure has to offer, I would never go back
>I routinely encountered scenarios where accidentally passing values of the wrong type to core standard lib functions produced wildly unexpected behavior that would take hours or even days to debug
Could you provide a concrete example?
Intuitively I do understand ClojureScript is not as seamless as some people say. First of all, Clojure is kind of a database-programming language with fundamental data types built around concurrency, while JavaScript was single-threaded until recently (and web workers used shared-nothing model). Second, Clojure is build around Java specifically, not any other language. Java has some strict type system with immutable complex objects being pretty much native way of doing things, thus Java is great for implementing dynamic types on top of it.
But I feel like not having undeniable proofs of fundamental flaw in ClojureScript. For example, JavaScript fundamentally lacks copy-on-write complex structures. Thus development of copy-on-write libraries is painful e.g. ProseMirror which can become completely broken until page reload which is bad for Single Page Application. However, could it be that ClojureScript... just works?
I wish I could, it's been years since I've actually written or even read any ClojureScript. But I can offer something more general. Many core functions expecting a collection type would blow up deep in the call stack, usually in helper functions not exposed or documented in the core API, when passed a value which provides no iteration. I would encounter these scenarios frequently when recursing over a nested structure (e.g. oops I passed a keyword or a function to `map`), or when I simply got argument order wrong.
Like I said, this eventually drove me to static typing, and I wouldn't ever consider a language without it again. Most dynamic languages have too large a core interface to commit it to memory, and even "small" languages reproduce that in the libraries we build.
ClojureScript has some oddities compared to Clojure but in my experience acts much nicer than plain JS
Clj-kondo is good to detect unintended passing, in terms of correctness there are sometimes minor fixes but not at the expense of backwards compatibility which is taken very seriously in core
In terms of doing idiomatic Clojure in Typescript, "good" Clojure is data driven Typescript is type driven
Universal data primitives Vs label everything with types aren't terribly compatible
> ClojureScript has some oddities compared to Clojure but in my experience acts much nicer than plain JS
For the most part I agree with this, but... it's not saying much.
> In terms of doing idiomatic Clojure in Typescript, "good" Clojure is data driven Typescript is type driven
>
> Universal data primitives Vs label everything with types aren't terribly compatible
Huh? What I said is that I try to apply the principles I learnt in Clojure—yes, including writing code that is data-driven, and more importantly value driven—in the most idiomatic way I can within TypeScript. Yes, the whole point of TypeScript is types (it's in the dang name), but:
1. Types describe data. The only major difference between the kind of data described in TypeScript and the kind of data implicitly defined in Clojure is that TypeScript inherited a runtime where mutability is the default and immutability is more a choice of convention than an actual feature of the language.
2. The TypeScript type system is extremely good at describing and statically validating the kind of dynamic polymorphism common in Clojure.
3. Even if it isn't, small and specific interfaces could be used as contracts to achieve roughly the same thing, just with more keyboarding.
Recently I've been working with cljfx for developing a JavaFX app with clojure. cljfx does a great job of creating a re-frame like development experience for JavaFX.
I'm surprised by how often questions like this come up, but I always find the responses interesting and educational.
* What I Want *
Non-negotiable items include:
- Low Friction: A little initial setup is ok, but just taking a note should require no more than a click or two (whether clicking a mouse or a pen).
- Open source.
- Aesthetically Pleasing: I'm tired of looking at ugly stuff.
- Has to handle LaTex.
- Has to handle syntax highlighted code listings.
- Notes are in an easily portable format.
- Organization Tools: Some sort of organizational ability. I have thousands of notes that I use and need to refer back to all the time.
- Privacy: No sending my personal information to someone else's server.
Negotiable:
- Mobile Friendly: My eyesight isn't good enough to use a phone for note-taking or reading. Tablets are Ok. Desktop is best for me.
- Implementation Language: Since I'm looking for an open source solution, I'd like it to be in a language that I like. In my case, Clojure/ClojureScript, Lisp, Scheme (Racket) would be optimal. JavaScript is least desired.
- Minimal dependencies: I'd prefer that it not be based on Node, NPM, Electron, Atom, or any other huge ecosystem that would have to be installed on my system. (Java is Ok with me, obviously.)
Scriptability: It would be nice if it could help automate my workflow.
* What I Have Tried *
- Long ago (2005) I started a job at which the company provided me with a stylus-based, Windows tablet PC. Included was a copy of [OneNote](https://products.office.com/en-us/onenote/digital-note-takin...) that could do very good, real-time handwriting recognition.
During work meetings, I typically created the notes as the meeting progressed and projected them on a screen in the meeting room, letting everyone make sure that what they said was understood and that they could see what they had agreed to (tasks, dates, etc.)
When I left that job, I would have bought one of those tablets if I could have afforded it. Since then, OneNote has morphed into something unusable for me, and I haven't gone back.
* I was a very early adopter of [Evernote](https://evernote.com/) and had a premium membership for a long time. I really missed the ability to do handwriting recognition, but being able to search within images was almost as useful. We would put meeting minutes up on the whiteboard, photograph them at the end and stuff them into Evernote so they could be searched.
I sadly stopped using it after Evernote also morphed into some unusable mess (Pay more! Get less!) that I couldn't remember how to use on different platforms.
* I used [TiddlyWiki](https://tiddlywiki.com/) for a while. It was quite powerful and easy to use, but it just bogged down unacceptably with a lot of notes.
* [Zim](http://zim-wiki.org/) wiki works well, but it doesn't have all of the features I want these days. And it is so ugly that I just can't bear to use it.
* [WikidPad](http://wikidpad.sourceforge.net/) is nice but also ugly and missing features that I need these days. And I don't use Windows anymore.
* What I Do Now *
I have tried to consciously move away from Google and Microsoft tools and closed-source programs (not always successfully.)
It exports to Markdown files that can be included directly in my blog.
It has almost all of the features I want, and it is relatively easy for me to add new things as needed.
Scanning or transcribing notes into my wiki was a PITA, but...
* I have recently started using a [Rocketbook](https://getrocketbook.com/). I use it for detailed drawings at my desk. But for things that are in my sketchbook, I can place the smaller pages from the sketchbook onto a page in the Rocketbook and scan them. They are then sent off to my email account. There are settings to cause the handwritten notes to be transcribed and placed in the email, allowing easy transfer into the wiki.
* For extremely long-form writing (beyond a blog post or note), I usually start with my wiki, splitting the significant parts into different documents. While collecting research, I use DEVONthink and [Scrivener](https://www.literatureandlatte.com/scrivener/overview). Finally, I put it all together in Scrivener.
* The Future *
* I enjoy expanding my wiki, both in content and in function. I want to add sophisticated tagging, something like in [Trilium](https://github.com/zadam/trilium).
Very interesting, thanks for commenting! You touched on the dependencies point:
> Minimal dependencies: I'd prefer that it not be based on Node, NPM, Electron, Atom, or any other huge ecosystem that would have to be installed on my system.
You don't want "bloated" frameworks to be used or you don't want to install NPM/Node/etc. on your system?
I'm asking because my app is based on Electron, but it doesn't require you to install anything in particular in your system to use it.
Yeah, I commented before looking at your app so I wouldn't be influenced by it.
My dislike isn't so much with the final app, but more related to the ability to rebuild an open source project. If I want to make modifications, there is a lot of additional stuff I would have to install. I just don't use node, npm, code mirror, electron, etc. The argument could be made that installing Java and the libraries I need would produce the same kind of clutter, but that hasn't been my experience.
I think it's a matter of differing tastes and I have the luxury to indulge myself.
I do want to thank you for putting your work out there though. It is always interesting to me to see how people approach these projects.
Thanks for the clarification. It makes sense that if you want to perhaps contribute to the project or even just self-building it you'd pick a stack of your preference.
Changing jobs in 2005 caused me to switch from taking notes on paper to doing it electronically.
My new employer provided a tablet PC with a stylus running Windows and [OneNote](https://products.office.com/en-US/onenote). Taking notes on that system with excellent handwriting recognition was a revelation. The tablet was pretty clunky by today's standards, but it worked well. It was particularly useful for generating meeting notes in real time and projecting them during meetings.
After moving to another employer, I no longer had access to such a tablet but used [TiddlyWiki](https://tiddlywiki.com) to keep my notes. It was great until the number of notes became large (in the thousands).
After that, I became an early adopter of [Evernote](https://evernote.com). It was an adequate note-taking app, but the killer feature for me was searching for text in images. At that time, we put meeting notes up on a whiteboard. After the meeting, I could take a picture of the whiteboard, insert it in Evernote, and search it any time after that. I maintained a subscription to Evernote until the end of 2016 until they got squirrely about their subscriptions and some privacy issues.
After several years absence, I went back to TiddlyWiki. It was very much improved. But after importing thousands of notes, it became too slow at editing. The search was on for another system.
I looked at several open-source tools under active development:
* [TreeSheets](http://strlen.com/treesheets/) has been around a long time and has some unique features for organizing your information.
* [CherryTree](https://www.giuspen.com/cherrytree/) it has been around for quite some time. Very long feature list. Very long wishlist too.
* [BoostNote](https://github.com/BoostIO/Boostnote) bills itself as a note-taking app for programmers. It has clients for lots of platforms and can keep them all in sync.
* [iA Writer](https://ia.net/writer) is very focused on writing.
I committed to [Collate](https://collatenotes.com) for awhile, even bought a license, but development seemed to stop shortly after I paid for it. And it keeps asking me to re-enter my license key. So, slowly moving off of it. And no more closed-source apps.
These days, my notes usually start short and then get longer and more detailed over time. Often they include mathematics, so typesetting math is crucial to me. Joplin fills the bill very well. It's almost perfect for me. But linking to other notes is a bit clumsy.
I set up a self-hosted [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki). It did everything I wanted (and way more) but was more cumbersome to administer than I wanted to deal with.
What I finally ended up doing was writing my own wiki.
* It uses a version of Markdown that can typeset math (_via_ [MathJax](https://www.mathjax.org)) and accepts wikilink syntax as well.
* Syntax highlighting for program snippets.
* It seems to be cross-platform. (I started development on Windows, now do it on macOS, and can (but shouldn't) self-host it on a Linux server.
* It runs on a desktop. (I can't read long notes with math on a phone and tablets are pushing it a bit with my poor vision.)
* It's written in Clojure and ClojureScript, languages I enjoy working with.
* The editor I wrote has a real-time preview (but the scroll bars don't' sync yet.)
* The editor is compatible with Grammarly, so I get some help with my atrocious spelling and grammar.
* All data is stored locally in a SQL database but can be exported to Markdown files with one keystroke.
* Pages can be exported with YAML so that they can be imported directly to my blog.
* and on and on.
Another option that might be useful is a [Jupyter](http://jupyter.org) notebook. It looks interesting, but I don't really have much experience with it. There's even a [kernel for Clojure](https://github.com/clojupyter/clojupyter) that I want to check out.
If you have the interest and the desire, I encourage you to look into writing your own tool. It isn't as hard as you might imagine just to get something working. It is incredibly hard to polish things to just the shininess you might want, but that's part of the fun.
