1. 1

Though I don’t use a web RSS reader (I made my own tool, feef and pipe it into FZF), I like the minimalism in the interface and the lack of nagging you about unread stories. And good job for letting people make clients!

Any possibility the web UI could be extended with a view of all feeds?

1. 13

I often find myself reading the source code of Fe, a tiny Lisp. It’s implemented in 800 LoC of ANSI C. Despite not being a C programmer (the pointer-munging scares me a little), it’s amazing being able to glance at a full programming language in 1 file.

In terms of what it teaches you, it’s a good example of a very small (regex-less) parser and mark-and-sweep GC.

I guess the downsides are the slightly C-ey data structures - objects have a car and cdr with GC and type info just shoved in, plus a bunch of bit-twiddling which makes it a bit less clear.

As with many things, rxi has written a very good implementation overview for it, which is a good starting point.

If it had a language-agnostic implementation tutorial, I’d follow it. It seems like the perfect educational language. And since it’s very small, I’m sure extending it with TCO and a bytecode VM would not be hard.

1. 5

Similarly, I learned a lot as a teen by reading a hard copy of FIG FORTH for the Z-80. FORTH source code tends to have a “plot” in a way, I.e. it’s quite linear. First a small assembly core, sufficient to establish the interpreter, then a series of FORTH words defined in assembly, which then bootstraps the all important “:” word that lets it start defining words in FORTH itself.

Also, FORTH is simple enough that it makes LISP look like C++ ;-) The syntax is basically purely linear, and there’s no GC nor even a memory heap.

Jones FORTH is a superlative example to read — it’s one source file, lavishly commented in “literate” style. Highly recommended. https://github.com/nornagon/jonesforth/blob/master/jonesforth.S

1. 3

This makes me want to port Fe to Zig for fun and for learning

1. 1

If there’s a test suite why don’t you port it to your desired language?

1. 1

I’m increasingly thinking of doing that. There’s no test suite but there are examples and rxi has made real stuff with it. I reckon it would be quite different in the target language though, to be idiomatic.

1. 56

IMHO it’s hard to get much out of reading a codebase without necessity. Without a reason why, you won’t do it, or you won’t get much out of it without knowing what to look for.

1. 5

Yeah, this seems a bit like asking “What’s your favorite math problem?”

I dunno. Always liked 7+7=14 since I was a kid.

Codebases exist to do things. You read a codebase because you want to modify what that is or fix it because it’s not doing the thing its supposed to. Ideally, my favorite codebase is the one I get value out of constantly but never have to look at. CPU microcode, maybe?

1. 4

I often find myself reading codebases when looking for examples for using a library I am working with, or to understand how you are supposed to interact with some protocol. Open source codebases can help a lot there. It’s not so much 7 + 7 = 14, but rather 7 + x + y = 23, and I don’t know how to do x or y to get 23, but there are a few common components between the math problems. Maybe one solution can help me understand another?

1. 2

I completely agree. I do the same thing.

when I am solving a similar problem or I’m interested in a class of problems, sometimes I find reviewing a codebase very informative. In my mind, what I’m doing is walking through the various things I might want to do and then reviewing the code structure to see how they’re doing it. It’s also bidirectional: A lot of times I see things in the structure and then wonder what sorts of behavior I might be missing.

I’m not saying don’t review any codebases at all. I’m simply pointing out that without context, there’s no qualifiers for one way of coding to be viewed as better or worse than any other. You take the context to your codebase review, whether explicitly or completely inside your mind.

There’s a place for context-free codebase reviews, of course. It’s usually in an academic setting. Everybody should walk through the GoF and functional data structures. You should have experience in a generic fashion working through a message loop or queuing system and writing a compiler. I did and still do, but in the same way I read up on what’s going on in mRNA vaccinations: familiarity. There exists these sorts of things that might help when I need them. I do not necessarily have to learn or remember them, but I have to be able to get them when I want. I know these coding details at a much lower level than I do biology, after all, I’m the guy who’s going to use and code them if I need them. But the real work is matching the problem context up (gradually, of course) with the various implementation systems you might want to use.

There are folks who are great problem-solvers that can’t code. That sucks. There are other folks who can code like the wind but are always putting some obscure yet clever chunk of stuff out and plugging it in somewhere. That also sucks. Good coders should be able to work on both sides of that technical line and move back and forth freely. I review codebases to review how that problem-solving line changed over the years of development, thinking to myself “Where did these guys do too much coding? Too little? Why are these classes or modules set up the way they are (in relation to the problem and maintaining code)?”

That’s the huge value you bring from reviewing codebases: more information on the story of developing inside of that domain. The rest of the coding stuff should be rote: I have a queue, I have a stack, etc. If I want to dive down to that level, start reviewing object interface strategy, perhaps, I’m still doing it inside of some context: I’m solving this problem and decided I need X, here’s a great example of X. Now, start reading and go back to reviewing what they’ve done against the problem you’re solving. Don’t be the guy who brings 4,000 lines of code to a 1 line problem. They might be great lines of code, but you’re working backwards.

1. 1

Yeah, I end up doing this a lot for i.e obscure system-specific APIs. Look at projects that’d use it/GH code search, chase the ifdefs.

2. 2

Great Picard’s Theorem, obvs. I always imagined approaching an essential singularity and seeing all infinity unfold, like a fractal flower, endlessly repeated in every step.

1. 1

I’d disagree. While sure, one could argue you just feed a computer what to do, you could make a similar statement about for example architecture, where (very simplified) you draw what workers should do and they do it.

Does that mean that architects don’t learn from the work of other architect? I really don’t think so.

But I also don’t think that “just reading” code or copying some “pattern” or “style” from others is what makes you like it. It’s more that if you write some code only on your own or with a somewhat static, like-minded team your mental constructs don’t really change, while different code bases can challenge your mental model or give you insights in a different mental/architectural model that someone else came up with.

For me that’s not so different from learning different programming languages - like really learning them, not just being able to figure out what it means or doing the same thing you did before with different syntax.

I am sure it’s not the same for everyone, and it surely depends on different learning styles, but I assume that most people commenting here don’t read code like the read a calculation and I’d never recommend people to just “read some code”. It doesn’t work, just like you won’t be a programmer after just reading a book on programming.

It can be a helpful way of reflecting on own programming, but very differently from most code-reviews (real ones, not some theoretical optimal code review).

Another thing, more psychological maybe is that I think everyone has seen bad code, and be it some old self-written code from some years ago. Sometimes it helps for motivation to come across the opposite by reading a nice code base to be able to visualize a goal. The closer it is to practical the better in my opinion. I am not so much a fan of examples or example apps, because they might not work in real world code bases, but that’s another topic.

I hope though that nobody feels like they need to read code, when they don’t feel like it and it gives them nothing. Minds work differently and forcing yourself to do something seems to often counter-act how much is actually learned.

2. 4

Well, it varies. Many contributions end up being a grep away and only make you look at a tiny bit of the codebase. Small codebases can be easier to grasp, as can those with implementation overviews (e.g. ARCHITECTURE.md)

1. 3

“Mathematics is not a spectator sport” - I think the same applies to coding.

1. 1

I have to agree with this; I’ve found the most improvement comes from contribution, and having my code critiqued by others. Maybe we can s/codebases to study/codebases to contribute to/?

1. 2

Even if you don’t have to modify something, reading something out of a necessity to understand it makes it stick better (and more interesting) than just reading it for the sake of reading. That’s how I know more about PHP than most people want to know.

1. 1

Years ago working on my MSc thesis I was working on a web app profiler. “How can I get the PHP interpreter to tell me every time it enters or exits a function in user code” led to likely a similar level of “I know more about the internals of PHP than I would like” :D

1. 7

1. 29

Weird, I definitely disagree on expanding this. It just wastes horizontal space and keystrokes for no benefit.

Maybe I32 and Str instead of i32 and str, but abbreviations for commonly used things are good. You’re not even getting rid of the abbreviation, Int is after all short for Integer.

1. 8

I agree with this (I think lowercase would be fine, too, though).

I think that Rust overdoes it a little bit on the terseness.

I understand that Rust is a systems language and that Unix greybeards love only typing two or three characters per thing, but there’s something to be said for being descriptive.

Examples of very terse things that might be confusing to a non-expert programmer:

• Vec
• fn
• i32, u32, etc
• str
• foo.len() for length/size
• mod for module
• mut - this keyword is wrong anyway
• impl

None of the above bothered me when I learned Rust, but I already had lots of experience with C++ and other languages, so I knew that Vec was short for “vector” immediately. But what if I had come from a language with “lists” rather than “vectors”? It might be a bit confusing.

And I’m not saying I would change all/most of the above, either. But maybe we could tolerate a few of them being a little more descriptive. I’d say i32 -> int32, Vec -> Vector, len() -> count() or length() or size(), and mut -> uniq or something.

1. 11

For an example, check out some Swift code. Swift more or less took Rust’s syntax and made it a little more verbose. fn became func, the main integer type is Int, sequence length is .count, function arguments idiomatically have labels most of the time, and so on. The emphasis is on clarity, particularly clarity at the point of use of a symbol — a function should make sense where you find a call to it, not just at its own declaration. Conciseness is desirable, but after clarity.

1. 2

Yep. I also work with Swift and I do like some of those choices. I still think the function param labels are weird, though. But that’s another topic. :)

2. 10

mut -> uniq

Definitely this!

For the context of those who aren’t familiar, &mut pointers are really more about guaranteeing uniqueness than mutability. The property &mut pointers guarantee is that there is only one pointing at a given object at a time, and that nothing access that object except through them while they exist.

Mut isn’t really correct because you can have mutability through a & pointer using Cell types. You can have nearly no mutability through a &mut pointer by just not implementing any mutable methods on the type (though you can’t stop people from doing *mut_ptr = new_value()).

The decision to call this mut was to be similar to let mut x = 3… I’m still unconvinced by that argument.

1. 4

Not to mention the holy war over whether let mut x = 3 should even exist, or if every binding is inherently a mutable binding since you aren’t actually prevented from turning a non-mutable binding into a mutable one:

let x = 3;
let mut x = x;
// mutate the ever living crap out of x

1. 4

My favorite is {x} allowing mutability, because now you’re not accessing x, but a temporary value returned by {}.

1. 2

I never knew about that one! Cute.

2. 4

I think this mostly doesn’t matter - I doubt anyone would first-try Rust, given its complexity, so it’s not really that much of an issue. Keywords are all sort of arbitrary anyway, and you’re just gonna have to learn them. Who’d think go would spawn a thread?

I, for one, think these are pretty nice - many people will learn Python so they expect len and str, and fn and mod are OK abbreviations. I think the terseness makes Rust code look nice (I sorta like looking at Rust code).

Though I’d agree on mut (quite misleading) and impl(implement what?).

1. 5

Shame there’s no section about languages on TIOBE 2016 and loved on StackOverflow. They are:

• Python
• C#
• JS
• Swift
• SQL

Python is a very good counterexample - the first language to so many, with many legacy systems running it but new stuff being written in it every day. Also an example of a language adapting to times - Python was probably not seen as a serious language when it was created but it’s being used for all manner of AI and scientific stuff, and not graying like Ruby (despite having very similar goals). JS has infinite “greener” alternatives (TypeScript being mentioned as green), and has been bashed to death and is still loved. Same for SQL.

1. 10

It’s not actually e-ink though. It’s a transflective display, so it doesn’t have the battery benefits. Still useful for working with a laptop in sunlight though.

1. 2

Yeah, I wanted to to say this as well.

Never the less, it is a great display. I have a modded Lenovo IdeaPad S10-2 with a Pixel Qi Display and I run Haiku-OS on this machine.

It’s the best option for working (writing) outdoors.

I don’t think these displays are still produced, so get one of those from ebay, while they are still available.

1. 1

Yeah, let’s keep the quotes (and case for that matter)

1. 1

Could you space your posts a bit in the future @vermaden? There’s currently 6 of your stories on the frontpage

1. 1

I will try to, sorry, did not meant to ‘steal’ the front page.

For the ‘excuse’ - none of these stories are ‘mine’ or from ‘mine’ blog :)

1. 1

It looks really nice!

I think something that gets forgotten about, especially with the various Markdown dialects is that a nice property of the original Markdown was that it was pretty close to what one would write in a Readme or an email, Usenet, etc. if there was only regular text (ASCII for example) available.

This has the advantage that unless the author doesn’t care just doing cat README.md or similar would still be very readable.

Of course there is a lot of extension and of course there is now many other use cases, like static site generators, websites, chat applications, manuals, etc. where the extensions are interesting. While it of course would be nice to have a “one size fits all” type small markup languages, I wonder if it wouldn’t make sense for some of these projects to start with clearly defined use cases (and what isn’t). That gives both developers a measure to prevent feature creep and users a quick way to see if it fits their project.

So I am curious. What would be the target applications for this specific markup language?

1. 2

Originally, the goal was to be “easy to type”. Initially, I made a point of avoiding the use of the shift key, which lead to duplication being favored (code was initially wrapped in ''), but that’s harder to type really. I have found typeup makes it really easy to reformat notes written in no format at all. My notes often use paragraphs instead of lists and never use Markdown tables because of their overhead. In typeup, they look almost the same except some wrapping. For example, instead of the trouble of a markdown table, you’d just write:

Irish: Celtic
Swahili: Bantu


and to make it typeup:

#:{
Language: Family
Irish: Celtic
Swahili: Bantu
}


This has the added benefit of being unintrusive visually (if a bit ugly). Typeup also aims to provide better tooling than existing languages, for example very simple builtin metadata so no bodging on frontmatter. There’s a lot of opportunities for improvement on Markdown in extensibility and tooling.

I should emphasize this is the first version of typeup. A lot of stuff is yet to be added: math, extensibility, footnotes, escaping, better nesting and plumbing to make it easier to use typeup in a Markdown-dominated world and just to showcase it (SSGs etc.). One of the things I hope to do is add Pandoc AST as an output format, which I’ve seen no other format doing. That would open up many output formats and lots of customizability

1. 2

Have you considered how users might express LaTeX math notation in your markup language? Users who write math-heavy documents are often an afterthought when designing specs like this. There’s the traditional $...$ and $$...$$ for inline and block math, but if you want something less intrusive you might take Scholarly Markdown’s approach that fails gracefully in the absence of a math renderer.

1. 1

if you want something less intrusive you might take Scholarly Markdown’s approach that fails gracefully in the absence of a math renderer

This just seems to be backwards-compatibility with other Markdown renderers, which I’m not really striving for. Nor do I want to overload existing syntax, that would be quite messy.

Of course, falling back to just printing the raw expression could be done.

What syntax you consider for something less intrusive than  and $$? 1. 2 Some options: • I think the ... and $$... syntax is what people who write math will reach for out of habit. But if it poses parsing difficulties, you might choose to use ... for inline and choose another method for block math. • I’m not a fan of the LaTeX  syntax for block math, mostly because the \ character can be a burden to type on some non-English keyboard layouts. Nevertheless it’s an option. • You could go full LaTeX and look for $$...$$ and \begin{align}...\end{align} etc. • Instead of overloading existing code block syntax, you could always introduce a new type of block delimiter like this, to be consistent with your existing markup. This would also placate users who like the ...$$ syntax. :) $$
block math here
$ I do personally think that in the absence of special notation just for math, “named” code blocks are the way to go. That way each block can be sent to the appropriate postprocessor, and you have a simple avenue for extensibility later. (for example, chemists might ask you to support SMILES diagrams) You can also take a look at how Madoko and MathPix Markdown handle math. 1. 2 I do personally think that in the absence of special notation just for math, “named” code blocks are the way to go. That way each block can be sent to the appropriate postprocessor, and you have a simple avenue for extensibility later. (for example, chemists might ask you to support SMILES diagrams) That’s what rST does: there’s general inline (role) and block (directive) syntax, and the build process exposed an intermediate doctree representation. Opens up all sorts of useful extensions. 1. 6 As the once long-time maintainer of cmark-gfm (which powers many comment fields around the internet, Lobsters included) and contributor to the CommonMark spec, .. I really like this! • Simplifying the rules for bold/italics is such a breath of fresh air. The alternative is mind-rending (scroll down to the numbered list of rules for defining emphasis and strong emphasis). • Simple link syntax is very pleasant. • It may be a bug that you can’t link an image: $ cat test.tup
[![alt text https://placekitten.com/200/200] http://placekitten.com]
$typeup < test.tup <p><a href="https://placekitten.com/200/200">![alt text</a> http://placekitten.com]</p>$

• I don’t love pipes for quoting; it seems a bit arbitrary when use of > is widespread (e.g. in Markdown) because > was what we were already using in text emails.
• The arbitrariness of [] for unordered and {} for ordered is a little awkward, as is the lack of proper/“full” nesting support. List parsing is one of the more awkward parts of CommonMark, but it also gives a real sense of deep expressiveness (like the code block I embedded in the list item above). This might be the one place that makes typeup feel like it lacks enough power for real-world use.
• Table syntax is novel and workable, I like it.

Nice work!

1. 2

Simplifying the rules for bold/italics is such a breath of fresh air. The alternative is mind-rending (scroll down to the numbered list of rules for defining emphasis and strong emphasis).

I didn’t know it was this complex! It’s nice to be able to keep the spec in mind for sure. One thing I have basically ignored in the first version is escaping, so if your text contains _ or *, you’re out of luck for now. I don’t know whether forcing people to escape these will be good enough

It may be a bug that you can’t link an image:

This is because of a circular dependency. In the grammar, I implemented link/image parsing in a function to use from the grammar, which can’t use the grammar to do styled text (which no bolding/italic in images either). This is mostly because I needed a quick and dirty way to do it (Janet’s greedy PEGs are less intuitive than just string/splitting it). This shouldn’t be hard to fix but it’s made harder by the fact that you can’t pass a capture to a rule in Janet PEGs (you can pass it to another PEG but that can cause circular dependencies). I enjoyed writing the parser but a from-scratch parser would probably be more robust

I don’t love pipes for quoting; it seems a bit arbitrary when use of > is widespread (e.g. in Markdown) because > was what we were already using in text emails.

Yeah, pipe quotes don’t have much benefits apart from maybe looking more like rendered quotes. Probably best to change it back to > though

The arbitrariness of [] for unordered and {} for ordered is a little awkward

I largely chose these because [ looks like “list” and { looks like “different list” to me. The list syntax is pretty unintuitive but it reflects my habit of just writing lists as paragraphs (I hate my keyboard so I am incredibly impatient typing the least of characters)

lack of proper/“full” nesting support

I agree this needs work, as does escaping. Probably a special syntax for “interpret as a paragraph wherever it is”. Also, some things aren’t nestable like quotes, much work to be done there (trying to write a draft spec made me realize just how little I’d thought about it)

1. 22

It’s unclear if there’s any advantage to using this.

I like the idea of metadata, but there are already markdown extensions for that.

Unordered lists are enclosed with [] and ordered lists are enclosed with {}.

That’s the exact reverse of common notation, where {} is a set and [] is an array.

But nice effort.

1. 4

This is my reaction as well.

I think it’s great that @skuzzmiglet could scratch their own itch and build this, but to be honest I’ve been SO INCREDIBLY grateful for the widespread support of Markdown as a near universal markup supported in more and more contexts and applications that I look at every new variant and unfairly think “NOoooOOOOOooo! Here we go again!”.

1. 1

I like the idea of metadata, but there are already markdown extensions for that.

MultiMarkdown’s is only at the start of the document and does weird auto-detecting, frontmatter adds a dependency (YAML and TOML are overkill, JSON is verbose) and Pandoc’s metadata is limited to dates, titles and manpage data.

That’s the exact reverse of common notation, where {} is a set and [] is an array.

Aren’t sets and arrays both order-preserving?

1. 11

Arrays are order-preserving, sets are not. A set is an unordered collection of unique elements. Many programming languages order their sets, but that’s either purely an implementation detail or an intentional deviation from the math definition.

1. 2

an intentional deviation from the math definition

It’s not a deviation, but an extension; ordered sets are still valid as sets, so long as they have a membership predicate. Math sets are not ordered simply because they don’t need to be.

1. 3

Math sets are not ordered simply because they don’t need to be.

1. 2

Ha, good point. If we don’t accept the axiom of choice then there may be unordered sets which cannot be represented in terms of an ordered data structure. (That being said, I think the existence of an ordered data structure kind of assumes well-ordering is possible, but.)

2. 1

It’s not a deviation, but an extension; ordered sets are still valid as sets, so long as they have a membership predicate.

Nope! Ordering violates the first axiom of set theory:

https://en.m.wikipedia.org/wiki/Axiom_of_extensionality

1. 1

It does not. That is a definition of equality based on membership, and you can still define it that way on ordered sets. (It’s fine to have another, separate equivalence relation which takes order into account.)

1. 1

Oh there’s a subtle miscommunication going on here. You’re assuming that “ordered set” means what it would mean in math: a set with a pre-defined ordering of its elements?

I was assuming that “ordered set” meant what it (might) mean in a programming context: a “set that remembers original insertion order.” https://code.activestate.com/recipes/576694/

The first definition is compatible with the axiom of extensionality. But the second definition violates it because the set {A, B} would be quite different than the set {B, A}.

1. 1

I was operating under the programming definition of ‘ordered’.

My point is that you can construct an equivalence relation for ordered sets that treats {A, B} as equivalent to {B, A}, without sacrificing the ability to construct other equivalence relations that would distinguish the two.

2. 1

Order is not a well-defined operation on sets.

1. 1

Sets are basically just predicates denoting membership. Bags add duplicates (which is what an unordered list is) and lists add a order on top of that.

1. 5

I don’t really see why I want his vs the dozens of existing wiki languages. It even sharea the thing I like least about markdown (using # for headers)

1. 3

Funnily enough using # for headers is the biggest thing I miss when writing rST instead of markdown.

1. 3

The annoying thing (to me) about MD header syntax is that the lower-level headers are much more visible than the higher level ones, which is backwards.

I’m not sure how to fix that, but it’s still annoying. (Textile’s “.h1” syntax just made no headers particularly visible, which wasn’t any better, really.)

1. 2

To me it’s that so many syntaxes use = for headings and # for ordered lists and Markdown breaks both of those at once with the weird header choice.

1. 1

Interesting. More # for lower-level headings is unintuitive to type, and increasing numbers of # reflect nesting better. I chose # for typeup because it’s the same for markdown, and as a character it can’t be improved much (I don’t mind borrowing from markdown)

1. 2

My biggest issue with it is that this doesn’t solve the most severe issue with MD I have - lack of backward-compatible extensibility. ASCIIDoc have that in form of the extensions syntax and I am looking forward creating something like that, that would support extensions.

1. 1

Extensibility has been left out of the first version for sanity. I was thinking of having a very simple syntax for passing raw text to transforming functions, but then stuff like TOC would be hard. Filters on the AST, pandoc-style, are also an option. It’ll have to be added at some point, because the core is quite lean for most people (no syntax highlighting, no TOC, etc)

1. 3

Did you write the typeup site in typeup? If so, could you share the source for the site?

1. 2

Sadly not, the current nesting rules don’t allow for multiline code in tables (I handwrote the HTML). I would love to bootstrap, though it may take some syntax bending. If you’re looking for more examples, https://git.sr.ht/~skuzzymiglet/typeup-doc/tree/master/item/example-document.tup has them.

New markup formats are sorta hard to actually use since so many webpages just take plain markdown. You could make scripts to open Vim and dump the converted text back but it’s a bit of a hassle for a rather small benefit (unless Lobsters, GitHub and MS Teams start supporting typeup :)). The hard solution would be Chrome/Firefox plugins and custom-extending everything.

1. 3

The itch.io Lisp Game Jam is starting, thinking of participating (first time). I’ve got an idea for a game in which you have to match certain inputs and reject others in a limited-size regex. Janet will probably be my tool of choice, if that fails I have Fennel + Love2D to fall back to. Hoping to make the most of the weekend because I’m super tired on weekdays now

1. 17

Oh, like outage post-mortems?

I second this, good idea.

(could you dig up some example stories from the past to flesh out the tag request?)

1. 17
1. 4

Thank you for spending cycles on that!

I think that makes a really compelling case for @pushcx et al. to consider.

1. 3

I think so too. I don’t see this as fitting in very well with any of the existing tags, and it feels very in the Lobsters spirit to me.

2. 1

These are all outages. “Post-mortem” and “incident” don’t adequately express that it’s network/infra related imo. Maybe “services” covers these, though quite broad too.

1. 1

Off to a much better start after easter, hopefully I’ll get back into old habits. Getting a Violin piece of mine a bit further after some headaches (I trimmed some stuff yesterday and having a lot of fun bodging in new material). Making a little stack-based-ish, terse, order-independent music notation language thing, hopefully

1. 1

Suggested flag as “release” as this is just a github repo.

1. 0

s/flag/tag? And we assume Lobsters haven’t seen this before and this isn’t a link to an release with new features so no. Let’s keep release’s meaning

1. 1

Basically cannot have a new tag and cannot use the closest to it. Makes no sense to me.

I will still keep on suggesting it when people post direct github pages.

1. 2

Looks very similar to tmux and screen with windows/panes.

1. 5

The difference being that it don’t care about detaching a session and just focuses on virtual-virtual terminals. The same author (who also created the interesting vis editor) also wrote abduco that just implements detaching.

I used to use dvtm together with st, which is a good combination.

1. 2

I saw that, but if you’re just going to rely on another app to do session stuff, then how is this statement (by the author) true?

Together with dvtm it provides a simpler and cleaner alternative to tmux or screen.


Relying on multiple applications (with their own config, process, etc) to replace the functionality of one doesn’t seem simpler or cleaner on the surface, but they don’t explain how it is.

1. 3

I immediately see the benefit, personally. I’m generally not interested in tiling etc., but I want session management. It’s nice to be able to pick one without the other.

1. 1

It’s unixy. Tiling and session management are two separate features that don’t depend on one another. So why bundle them? I do get why some people are interested in it, but I also agree that I don’t need both all the time.

1. 1

I use abduco everywhere:

• It’s made sucklessly, so it’s easy to hack, very fast to compile, compatible with TCC, only uses a Makefile etc
• It changes your terminal minimally, only changing your cursor, which I don’t mind. In tmux and dvtm, I have to wrestle with weird \$TERMINAL behaviour
• The less features, the less documentation there is to read. The manpage is small, and there’s a small number of intuitive options
1. 10
1. 3

To be fair it was a different URL, so the duplicate submission detector didn’t work. The author must have migrated their blog off medium.

And from a comment on the previous post: Introducing Glommio, a Thread-per-Core Crate for Rust & Linux, which uses io_uring.

1. 3

The author must have migrated their blog off medium.

Well, they got their own domain name but it’s still hosted by Medium

1. 2

Yeah, I don’t blame OP at all. I just knew I had seen that article before so I went looking for it.