Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Is Not Enough

project-mage.org

Post reply on HN
Print view View original

91–100 of 163 posts

Re: Emacs Is Not Enough

#91

Post by some-mthfka »

woolion wrote: post #84
some-mthfka wrote: post #59

Earlier quoted context omitted.

Really, to me, this project is all about writing a few applications for myself. This may get lost throughout the pages of writing, but really, I am doing this for myself: flexible note-taking, a comfortable REPL, and, _at last_, a Lisp IDE (especially, with comfortable print-statement debugging). Structual editing is just the means to get these specific things right. Of the link provided (on a skim, so I may be wrong…

Well, I think they tend to focus on a particular language as a first step to reduce the scope. I had to refactor a python codebase, and the same function was used in context managers, decorators, and functions. Because of these disparate syntactical structures there was no way to refactor things easily or entirely de-duplicate some code. This is not an issue you would have with a Lisp. > Glamourous Toolkit Thank you,…

> Well, I think they tend to focus on a particular language as a first step to reduce the scope.

Yeah, that's a way to do this, but if you start small, you will then later find yourself walled within your initial assumptions about what you really want. Oh, well.

> By all means I wish you good luck and I'd like to check in on the project in one year or something.

Sure, and thank you!

Re: Emacs Is Not Enough

#92

Post by some-mthfka »

mmargerum wrote: post #79

All I can say is "Glamorous toolkit" https://gtoolkit.com/

Wrote a review on it on the website, copypasting:

Glamorous Toolkit[1] promotes the idea of moldable development[2].

There's a talk on it: Tudor Gîrba - Moldable development.[3]

The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook.

The site on moldable development states its difference with literate programming:

They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).

And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment.

The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool.

But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated.

It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself.

I can't say I can compare it to Project Mage in any meaningful way, except it's also a live environment.

[1] https://gtoolkit.com/ [2] https://moldabledevelopment.com/ [3] https://www.youtube.com/watch?v=Pot9GnHFOVU

Re: Emacs Is Not Enough

#93

Post by veltas »

> And then there are the floaters, the passers-by. They judge Emacs solely by its features. > But that's not how a power users judges it. Instead, the power user judges a piece of software by what power it provides and what he could do with that power to help himself.

In that case I'm not a power user. I tried using emacs for a good amount of time, probably about a year of wall time has been spent with me using emacs as my primary editor. I installed a few packages, and never tried to script anything myself. My issues with emacs were not easily scriptable.

Although all-in-all, I didn't find emacs particularly lacking in features compared to vim, which is my preferred editor.

In the end I stuck with vim because it's slightly less clunky in my very subjective experience, and I am faster with it. And it is visibly slow, even if you set up an emacs server ("what is a text editor 'server'?" I can hear vim and nano users muttering).

Rather than just s**ing on emacs I want to present the things that I did like about it, compared to vim:

- The ability to quickly cycle through recently yanked/cut things. It's possible to do this on vim, but nowhere near as easily as M-y. - Keyboard commands are universal and not modal, so I don't need to learn two totally different sets of commands for simple movement and editing. - Keyboard commands are also available in many prompt-based tools like bash, gdb, and many REPLs. Don't tell me about vi-mode in bash unless you actually use it and like it.

Re: Emacs Is Not Enough

#94

Post by lycopodiopsida »

some-mthfka wrote: post #86
lycopodiopsida wrote: post #78

I've found the emacs rant itself amusing, since it is a very old piece (slightly younger than me) and gargantuan piece of software, and it shows. On the other side, it is still the most extensible and moddable editor out there and its crown juwels (org, magit) are unmatched. As for the project itself, I remain sceptical. Partly because I do not see how it would be more amazing for general text-editing tasks than emac…

> text-editing tasks than emacs/vim + tree-sitter If you like mediocrity, sure. That's what so many have OK'd, and that's fine, not everybody has to care about tools. And you are right for being sceptical: it's only natural, I would be too if I saw what I wrote without knowing what it was. As an Emacs user, I could be dismissive of new efforts, because, you know, emacs is enough and all. And I have said this a few ti…

For a text editor mediocricity is fine. It has to solve many tasks for many people. It has to be shown that structural editing makes an editor simpler, faster and in suited for a broader range of tasks. Until then, text is the king.

> Yeah, but is it even good?

Yes, it is. Is the only solution which was able to replace several outlines + highly specialized solutions like OmniFocus for me. And that, being a simple text outliner. It has no point to compare it to some hypothetical solution which does not exist and may never exist at all. We need it here and now.

> and that's written in lisp.

It may be more of an artefact of the time when emacs was created than some intrinsic advantage of lisp in general. The way I see it, the advantage of emacs is that it is mostly written in the own script language. Would it be written in lua instead (a more common choice these days) not much would change as long as you can eval code on the fly.

> Or are you saying that Common Lisp itself is a problem?

I would not say that CL itself is a problem, but on the other side the lisp community likes to write essays about the perfect software in the sky but delivers mostly nothing. I cannot do otherwise than compare it rust, which is very young language compared to CL, but the community cranks out amazing and useful software on a weekly basis.

So, yeah, while in theory nothing speaks against amazing software being written in CL (as in any other language apart from brainfuck, really) in praxis it raises a lot of red flags for me.

Re: Emacs Is Not Enough

#95

Post by veltas »

some-mthfka wrote: post #40

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the Project's Philosophy/Homogeneity section in [1] The Power of Structure. I am proposing we need to really start considering a different para…

> First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity.

This is a huge problem with GNU. Lisp is an extremely elitist language, and extremely divisive. It's not taught that well in GNU documentation either, in my opinion.

The least elitist language today is probably JavaScript. We already had Atom, and then things like VS Code, that make heavy use of JavaScript.

But does using JavaScript as the scripting language imply that the editor must be Electron-based? Surely you can have a thinner JavaScript-based app for desktop? And who cares whether it runs in a browser.

Re: Emacs Is Not Enough

#96

Post by ilyt »

worik wrote: post #21
jb1991 wrote: post #16

Earlier quoted context omitted.

Print debugging is a technique that will never go out of style. It works on any system, is used by programmers of any level of experience, is very quick to use and requires no tooling to understand. And sometimes, even if you do have other great tools at your disposal, it’s still the easiest way to track down a problem.

Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.

You'd be hard pressed to find any. You can even get console over JTAG/SWD and near every microcontroller has it.

Only when you get into realm of few cents per microcontroller then you don't have it

Re: Emacs Is Not Enough

#98

Post by jrm4 »

I merely skimmed this article because I personally don't care or much about the details, but also because I completely and fully understand his pain.

I've done quite a bit of the "searching for the perfect system," including doing Emacs + Org Mode for a few years.

I ditched it because I do like a lot of modern tools, and today I use a ton of little scripts and hacks, mostly around zim-wiki, but what I think the author is getting at is more-or-less the "hypercard" thing.

Namely, it could and should be far easier to cobble together systems of programs as individuals that work together and that don't strongly separate "user" and "developer."

(aka screw GNOME? :) )

Re: Emacs Is Not Enough

#99

Post by some-mthfka »

lycopodiopsida wrote: post #94
some-mthfka wrote: post #86

Earlier quoted context omitted.

> text-editing tasks than emacs/vim + tree-sitter If you like mediocrity, sure. That's what so many have OK'd, and that's fine, not everybody has to care about tools. And you are right for being sceptical: it's only natural, I would be too if I saw what I wrote without knowing what it was. As an Emacs user, I could be dismissive of new efforts, because, you know, emacs is enough and all. And I have said this a few ti…

For a text editor mediocricity is fine. It has to solve many tasks for many people. It has to be shown that structural editing makes an editor simpler, faster and in suited for a broader range of tasks. Until then, text is the king. > Yeah, but is it even good? Yes, it is. Is the only solution which was able to replace several outlines + highly specialized solutions like OmniFocus for me. And that, being a simple tex…

> For a text editor mediocricity is fine.

No, not for the text editor, but may be for some users. If a tree falls, does it make a sound?

After all, maybe you are just not a power user and don't have the same frame of reference that power users have.

> It has to be shown that structural editing makes an editor simpler, faster and in suited for a broader range of tasks. Until then, text is the king.

Text might be the king until then, yes, but so is C++ and the children running with AKs in Africa. Doesn't mean it's right or acceptable.

To me, I have argued extensively, that yes, structural can be absolutely simpler and faster and more versatile. Without a question.

> I would not say that CL itself is a problem, but on the other side the lisp community likes to write essays about the perfect software in the sky but delivers mostly nothing.

I am sorry, but I am not a part of that generation, if there's one. Yes, I can see how strange it is to not see what's claimed to be a very powerful language overtake the world. I agree on that, it's a bit mysterious.

But some things just take time, I think. For the people to get accustomed to it; to go through some pain first, perhaps.

Look, the only reason I am using CL is because it's an image-based language. That's simply crucial for interactivity. What are my other options? Smalltalk isn't bad at all, but I like macros too much, and the stability too.

> in praxis it raises a lot of red flags for me.

You have to account that the community hasn't been as nearly as large as for any other mainstream programming language. So, aren't your expectation, perhaps, a bit too high for the output of that community? It only has something like 3k packages online. Python has 420000+. Where is all the amazing python userland software that has lived for >5 years?

And, you know, as small as it is, people have published some pretty cool libraries. Stable libraries. Sublanguages. Macro libraries. FWIW it's pretty cool as it is. A game was published two days ago: https://store.steampowered.com/app/1261430/Kandria/

Is it amazing? Haven't played it, don't know. Maybe? But what exactly is all that software you are expecting to begin with?

I don't know the name for it, but there ought to be some cognitive bias that says: "things that don't happen, can't, and won't".

Of course, I get it. I would be sceptical too. Maybe even very sceptical. But there's no other way to deal with sceptisism other than to analyze what's actually proposed, and whether it's doable.

https://project-mage.org/why-common-lisp

Re: Emacs Is Not Enough

#100

Post by msravi »

kqr wrote: post #32
taeric wrote: post #11

I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my…

I think you're onto something general here. At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility. Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.

cat, grep, awk, sed, cut, paste, column
Post reply on HN