Hacker News Reader

gcatlinon macOS Monterey

For those who are wondering what the config setting is:

Finder -> Preferences -> Advanced -> When performing search: Search the current folder

gcatlinon Low Hanging Fruit of Programming Language Design

Premature abstraction is the root of all evil.

gcatlinon Is the x86 Architecture Sustainable?

Interesting proposal for a forward compatible instruction set architecture by Agner Fog:

http://www.forwardcom.info/

gcatlinon A Foray into Go Assembly Programming

Slides: https://talks.golang.org/2016/asm.slide

gcatlinon Why Don't We Have a General-Purpose Tree Editor? (2014)

I don't want a general purpose tree editor. I want a general purpose text editor that understands the semantics of the text I'm editing. One that understands all the various not-necessarily-sexp-based code I'm editing is a tree and supports (ParEdit style) operations on that tree. Especially with languages in the Algol/C family. I think this can be accomplished (eventually) via language servers and editors that speak the Language Server Protocol (LSP) [0].

But I don't need a UI oriented around visually displaying tree-like things. Expanding / collapsing nodes is very meh. Moving / splitting / joining nodes is much more interesting and useful.

As a simple concrete example: changing the order of the parameters (and their type) in a function definition. Wouldn't it be great to 'swap-with-prev-node' or 'swap-with-next-node' rather than copy/paste and dealing with commas? The same operations could swap the order of two fields in a struct or two functions or two classes or any pair of adjacent nodes in a tree.

Or how about moving an 'if' block inside the 'for' block that follows it? Just execute the 'move-node-inside-next-node' (or whatever) command.

This only requires editors that (indirectly) understand the semantics of the text you're editing. Thus far the biggest barrier is all wheel re-invention needed for the cartesian product of all editors and all languages. But that's the wrong approach. We need each language to provide a tool that each editor can use via a common protocol.

This is precisely the point of the LSP. The functionality only needs to be written once per language and per editor. This is totally tractable. I don't know if LSP currently supports the specific tree-manipulation functionality I mentioned, but I'm confident it could.

Does anyone knowledgeable about LSP know if this is already possible, feasible, and/or generally desirable? Are there deal breakers that make this hard / not worthwhile?

[0] http://langserver.org/

gcatlinon Getting Past C

I think that's why Stroustrup says "zero overhead" instead of "zero cost". There are costs to many of these abstractions; some at compile time and some at run time. For me, "zero overhead" conveys this a little better.

gcatlinon I've been writing ring buffers wrong all these years

Another one by ryg: https://fgiesen.wordpress.com/2012/07/21/the-magic-ring-buff...

gcatlinon Fallout 1.5: Resurrection

A funding campaign for Wasteland 3 recently completed successfully! https://www.fig.co/campaigns/wasteland-3

gcatlinon Writing C software without the standard library

Cached version http://webcache.googleusercontent.com/search?q=cache:OAPjMoZ...

gcatlinon “CPUs are optimized for video games”

https://cr.yp.to/snuffle/spec.pdf

https://cr.yp.to/snuffle/design.pdf

gcatlinon Why Do Islands Induce Dwarfism?