Live data from Hacker News

Emacs Is Not Enough

project-mage.org

21–30 of 163 posts

Re: Emacs Is Not Enough

#21
post #16
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…

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.

Re: Emacs Is Not Enough

#22

TLDR?

Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigati…

I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost.

I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.

Re: Emacs Is Not Enough

#23
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…

> print debugging

Curiously:

https://project-mage.org/overcoming-the-print-statement

Re: Emacs Is Not Enough

#24
post #20
post #6

The entire article comes down to this quote: WHY IS EVERYTHING SO JANKY AF?

And my reaction was, is it really so yanky? Maybe it's not yanky enough for me to notice. Except for the handling of long lines, that's really slow. I wish it is just yanky. However I don't understand one thing. Did the author switch to something else or he's still using emacs after this long and convoluted rant?

There is so-long.el which is part of Emacs since 27.1 http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long...

Re: Emacs Is Not Enough

#25
post #21
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.

It requires a way to get bytes out of the system. You can connect an external console to that.

Re: Emacs Is Not Enough

#26
post #21
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.

Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.

Re: Emacs Is Not Enough

#27
XEmacs was a great replacement back when UNIX environments were found lacking in IDE offerings.

I still have muscle memory for the stuff I used between 1995 and 2005, across various UNIX commercial workloads.

Nowadays thankfully all the environments I care about have quite good IDE support in some form, while Emacs experience at its core has hardly core, although it is much better than in the XEmacs vs Emacs days.

Re: Emacs Is Not Enough

#28
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…

That is why debuggers and OS support trace points and events for debugging at scale.

Re: Emacs Is Not Enough

#29
post #26
post #21

Earlier quoted context omitted.

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.

Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.

Which is why a GPU debugger with frame tracing is so much better option.

By the way, there are actually ways to expose a print function on shader code, provided there is driver support.

https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...

Re: Emacs Is Not Enough

#30

TLDR?

Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigati…

So this is another take on the whole "text as a structure"-idea, where there are so many failed projects already? Hasn't emacs even some packages around this?
Post reply on HN