Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> having your markup language tied to an editor

Org-mode isn't just a markup though, and Emacs ain't just an editor - it's rather one cohesive system. I use Org-mode to manage all my dotfiles - it simpler than nix or ansible, allows me to do things both - declaratively and with linear instructions; My note-taking is all done in Org-mode; I don't have to present much these days - I did that with Org in the past. My spaced-repetition cards are in Org-mode. Whenever I need performing etymology look-up or check the thesaurus - results displayed in Org-mode. I'm reading this page in Org-mode and typing this comment in Emacs.

It only sounds insane, but the basic outline format of Org is absolute pinnacle of simplicity. So many things you can do in it, sure it may feel absurd. What? Reading HN and Reddit in Org-mode? Well, why not? If all the different things like imenu, search features of all kinds, sorting, conversion, etc. - all that available at your fingertips, not to mention the extreme extensibility; it does get only practical over time.



yeah, that's exactly where I didn't want to end up. I want my constellation of tools to be as interoperable as possible. I don't want to be locked in to the Emacs universe - hoping some greybeard makes a package for whatever I want to do.

Just as a simple example:

> My spaced-repetition cards are in Org-mode

Okay, so for instance Anki now has an improved algorithm called FSRS. It's greatly improved my flashcard experience. Maybe at some point this will be available in an orgmode flashcard package.. but I'll have to wait. Or maybe it'll never get implemented

I rather use the best tools for the job and find ways to make them interoperate

But I respect your commitment to the Emacs microcosm. I think it make s a lot of sense.

A big part of it, is I simply don't want to write ELisp to fix my problems. It's not a language I want to get very proficient with. I hope some day there is a JVM equivalent, b/c I honestly could see myself working in a Clojure Editor and making JVM based extensions - (the JVM has a library for everything)


> I want my constellation of tools to be as interoperable as possible.

Unironically, that's exactly what knowing some Lisp and Emacs gets me, and it seems to me you simply have very little idea what I'm talking about. You're focusing on so much explicit knowledge of things, that you're missing an entire universe of tacit wisdom - the things that can open up ways for cerebral satisfaction - not through some theoretical argy-bargy, but through down-to-earth, unadulterated pragmatics.

I never said that I'm using Emacs for practicing spaced-repetition - I don't use it to flash the cards to me. Why would anyone use a desktop computer for something like that, when the mobile devices are clearly more suitable for that task? I do however manage my cards in Emacs - because most of the time they are made of plain text, sometimes LaTeX embeddings and attached images. I do that in Emacs, because my spaced-repetition cards are not in some other medium - they literally are my notes, part of my exocortex system. I can easily find them, review them, modify them and send back to Anki app for syncing, so they are ready for my next time two-minute practice. These days I can even feed any content to LLM to generate dozens of cards, and it takes seconds, not even minutes.

> I simply don't want to write ELisp to fix my problems

Your choice, but honestly? You're missing out. Elisp is relatively straightforward and unambiguous PL - far less complicated than even JS or Python, it really doesn't take too long to get to know it.

I can give you numerous practical, working, real-life examples of how using Lisp in Emacs can bring enormous joy and the sense of liberation from the status-quo. It is indisputably true "hacker's playground".

I understand your fascination with Clojure - I use it daily myself, and similarly, just like you're not getting my talking points right now - majority of programmers don't get my enthusiasm for it. What they often be missing is that Clojure sometimes can feel like a godsend for achieving certain results. Just the other day - we were dealing with a Python-built service that sends huge nested maps around, and we needed to manipulate them, splitting into smaller sub-structures and dealing with them in Python wasn't particularly easy. Well, I quickly concocted a tiny elisp function that calls python and converts the data to EDN. It's only ten lines of elisp and it does it right there - in the same buffer. Then I spun-up a Clojure REPL, where I explored the map, filtered out the keys, introspected it in ways that wouldn't be so satisfactory using plain python tooling alone. Some pythonistas with no exposure to Clojure would call that "a skill issue", without even realizing that the skills and intuition I developed over the years are precisely the instruments that allow me to deal with everyday tasks in ways that never materialized for them.

I don't know for how long you've been doing this craft, and please, feel free to ignore whatever I'm saying - after all, I'm nobody - just some rando on the internet, yet, if you just allow me some non-condescending, honest mentoring here...

The tools we gravitate toward often say more about our past experiences than about the problems we're trying to solve. I've been there - I once avoided entire ecosystems because they weren't in "my" language. But here's what I've learned: every tool, every language, every paradigm is just another human attempt at managing complexity. None are sacred.

Elisp might feel alien compared to other things you know well, but that alienness is worth examining. What if the friction you're feeling isn't a flaw but a feature? What if Elisp's simplicity and directness - its lack of certain abstractions you're used to - is actually freeing you from complexity you didn't need?

Software is storytelling, and different languages tell different kinds of stories. The JVM tells stories about enterprise scalability and library ecosystems. Elisp tells stories about text manipulation and user empowerment. Neither is wrong, but using the JVM to deal with plain text is like using a symphony orchestra to play a lullaby - you can do it, but you might be missing the point.

Maybe try suspending your language preferences for just a month. Write some Elisp. Maybe not a lot - just enough to solve one real problem you have. You might find that the language you "don't want to get proficient with" has been whispering solutions you couldn't hear over the noise of your preferences.

If you really, genuinely curious what knowing just a bit of Emacs can buy you, feel free to ping me, I may even agree to arrange a video-call session to show you things I do every day and compare them with your habitual workflows - who knows, maybe tis not I, but rather you, will be teaching me something new.


> Elisp is relatively straightforward and unambiguous PL - far less complicated than even JS or Python, it really doesn't take too long to get to know it.

> Maybe try suspending your language preferences for just a month. Write some Elisp. Maybe not a lot - just enough to solve one real problem you have. You might find that the language you "don't want to get proficient with" has been whispering solutions you couldn't hear over the noise of your preferences.

I've written a good amount of ELisp. I wrote a small linear algebra library in it. I feel I gave it a very good honest try. I read all the manuals and what not. Actually thinking back on how much time i spent trying to grok it.. I'm a bit horrified. Fortunately it lead me to Clojure, so it's not all lost time. I'm definitely not a pro by any stretch. I know this might come as a shock to you, but I always found it an absolute chore to work with. Constantly finicky. The worst is dealing with other people's Elisp code. It's is hard to read, hard to understand how to configure and modify packages. There is so much global state that you have zero insight into what's actually going on.

I still use Emacs b/c of CIDER. The thing leak memory like crazy and I have to reboot it every couple of days. I used to use Ergomacs, but that would also lag the whole editor a ton. There are tons of broken things.. error buffers popping up where I don't want them to, keybindings that work everywhere but Magit etc etc. It's all probably fixeable but it's so difficult to understand what the hell it going on. Each EMacs version bump is like a day or two of lost time of me trying to fix the damn thing. The JVM/Clojure world is so so much easier and straightforward and easy to deal with. There are so many great tools for debugging and profiling. It's night and day. "like using a symphony orchestra to play a lullaby" I just never ever feel that way...

I only program a few hours a week now a days. It's not my full time job these days. But deal with Emacs' warts is a full time job. Even after all my ELisping, I still have very little understanding or insight in to EMacs actual internal design and modularity (if it even has any). This is in stark contrast to Clojure - which is modular and extensible by design

> But here's what I've learned: every tool, every language, every paradigm is just another human attempt at managing complexity

Some languages are better than others. I learned a ton from C++. But some languages.. there are no paradigms in ELisp that I miss in Clojure. I've written a lot of R. I don't miss anything from that poorly designed monster. It didn't teach me anything - other than that some ecosystems live on for too long by inertia. Some languages are just old and bad b/c they're from a period of time where people hadn't figured things out a bit more. I'm sure there are nuggets o ELisp that I just never dug down deep enough for, but to me it just feels dated. ELisps and Schemes are fun and cute, but they're just not a good way to express abstractions and complex ideas. A lot of ideas just hadn't congealed when it was designed. Baking in datastructures in Clojure is just genius. Making Protocols central to the language just rams home all the lessons we've had over the decades about composability and OO design over the year. I don't want to go back to writing cons cells


I think your arguments are fair, well, for the most part of your sentiment anyway. I do use CIDER almost daily and have not experienced critical memory leaks and I don't feel like I'm fighting Emacs warts all the time, although of course, it would be silly of me to deny the fact that Emacs indeed has many. Of course, Clojure is far more nicer language than elisp, I personally like it perhaps even more than CL, but that might be only because I lack extensive practice of CL. I really wish core Emacs developers had more exposure to Clojure, maybe then we would've gotten some niceties borrowed from it. Imagine if we could have clojure-like maps in elisp?

I am hoping for the day when a practical alternative for Emacs comes around, yet the occasional bleeps that appear on the event horizon are too far from dethroning Emacs anytime soon. Lem seems to have good foundations, but I'm not sure if it will ever succeed to the point of being a possible complete replacement. The Easel project looks interesting, but it's still too early to say if it will ever grow out of its incubation https://github.com/phronmophobic/easel. Light Table also looked great in theory, in practice - it never became a thing. Sadly (or not) Emacs remains ultrapractical. The only and the main reason why I still use it - it works, yes, it's not ideal yet it does get the job done. That's perhaps the same argument an average VSCode user would make, however without a clue what it is like to be able to manipulate virtually any aspect of your editing environment via Lisp REPL.


Oh very cool. Easel looks very interesting :))

I also over the years.. I've sort of come to terms with .. maybe I'm not super great at programming?

I've been programming Clojure for ~6 years for my personal project. And I still feel I'm picking up new insights into code design and I still don't feel I've mastered it




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: