I’m salivating after those ligatures. If only ligature support was available in a sane manner in Emacs.
I get programming ligatures in Emacs, but then, I’m using the Mac build, and font that has the ligatures in it (Iosevka).
(mac-auto-operator-composition-mode t) ;; enable ligatures
I use vim on the terminal and ligatures in Iosevka work just fine. But it does require a terminal emulator with ligature support.
I’ve heard some people raving about tiddly wiki for this which seems like it has a lot of flexible interfaces. I don’t share my notes publicly as often, but I take tons of notes, and I almost always have this tui mind map that I wrote open in a tmux pane.
Why don’t you share your notes publicly? I think there is so much value to be had if everyone shared their notes in public.
I have a lot of personal info in there that I don’t need to share. But I am often thinking “I should be writing more for public consumption” and I also started making a gitbook, with sort of a long plan of turning it into a sort of “designing data intensive applications” but with an eye toward actually building the underlying infrastructure that supports data intensive applications. Sort of a missing guide for modern database and distributed systems implementation. But it’s been hard for me to overcome the friction of really building a durable habit of writing for others.
That’s the cool thing about a wiki. You write the notes for yourself. Just share it with others.
Would love to read your book. I’d release it gradually too as the topic of building the infrastructure for data intensive apps is vast.
Not to discourage you from writing, because I do believe that there’s always room for new takes on a topic, but Martin Kleppman’s Designing Data-Intensive Applications may be of interest to you, if you haven’t seen it. I’m not sure that it goes into “underlying infrastructure”, as you’re thinking, though.
I love that book! I want to do something similar but targeting people building infrastructure instead of the applications on top.
Gotcha. That sounds useful, though I’d think less evergreen because the technology on which the infrastructure is built will keep changing.
I’ve seen a lot about the virtues of event sourcing, but a lot less about how one implements event sourcing at different scales. Am I correct that’s the kind of thing you’d dig in to?
No software I tried supported tagging things as public or private. So I am forced to make everything private.
Cowyo is a wiki with public and private pages. Fairly straightforward codebase.
@icefall This void reminds me a lot of maxthink, an old DOS personal organizer (http://maxthink.com) I’ll take a deep look, thanks for sharing.
@nikivi, your gitbook is a prime. Very well crafted. I also try to keep notes on a similar structure but yours are way more strucutred.
The simplicity that was TiddlyWiki has unfortunately been mostly lost in the name of security. It used to be a single file that you could open and edit, and everything would save automatically and transparently.
Now you have to install a browser extension for it to save correctly, which makes TiddlyWiki much harder to transfer between browsers.
Edit: I’m not taking sides on the security-functionality tradeoff, to forestall any off-topic discussion.
However, TiddlyWiki has been along a looooong time (at least 10 years) now, and I assume that this would mean the Wiki portion of the software is superb.
Documentation for the syntax is at http://mandoc.bsd.lv/man/mdoc.7.html.
https://manpages.bsd.lv/ is also a good resource if one has never written [gt]roff and/or manpages before.
Oof, that looks like a much better resource. The syntax still needs some getting used to, but being shown the benefits of semantic markup (i.e. how does the PDF conversion look? Does it work well?) might persuade me to write some mandoc.
The syntax still needs some getting used to
The syntax still needs some getting used to
It becomes fairly pleasant. I’ve converted a few pages from man to mdoc for the suckless project (although my patches haven’t been accepted) and all you really need is the manpage you linked as a reference. I’ve also written a few myself, and once you understand the boilerplate + semantic, the rest is easy.
how does the PDF conversion look? Does it work well?
how does the PDF conversion look? Does it work well?
It’s really easy: running
$ mandoc -Tpdf ed.1 > ed.pdf
on ed.1 results in this file. Nothing too special imo.
I am curious about one thing. The image model of small talk, which is considered one of its strengths is similar to the notebook state in Jupyter notebooks right? How does smalltalk get away from all the associated disadvantages?
What am I missing when people talk about image based development?
The main thing I think you’re missing is that the actual Smalltalk development experience looks nothing like the experience of using Jupyter.
First, Smalltalk, unlike every other language I’m aware of, and unlike Jupyter notebooks, is not written as files. Instead, you work entirely in a tool called the browser, where you can see a list of classes, those classes’ definitions, and a list of all methods within a class. The order in which these classes and methods were defined is irrelevant and invisible. This alone eliminates a huge swath of the notebook complaints.
Second, with few exceptions, the version of objects you’re seeing is always live; while you might have a Workspace (REPL) open with a test and output, that’s visibly very distinct from an Inspector, which shows you the current state of any given variable. The Browser likewise only shows you the current definitions of a class or method. (Previous versions are usually available through what you can think of as a very powerful undo tool.) You thus don’t end up with the current v. previous value skew issues with notebooks.
Notebooks are suffering because they’re trying to bring a kind of Smalltalky experience to a world where code is written linearly in an editor. I agree, that’s tough, and that’s really the underlying issue that the post you linked is hitting. Smalltalk (and Common Lisp environments) instead focus on saying that, if you’re gonna have an image-style situation, you need tooling that focuses on the dynamic nature of the preserved data.
[Edit: all that said, by the way, I think you can make a case that some specifics of how Smalltalk’s image works in relation to its dev environment are a bit off. One way to fix that is the direction Self went with Morphic, where truly everything is live, and direct object manipulation rules the day. The other direction you can go is what Common Lisp and Factor do, which is to say that the image contains code, but not data—in other words, making images more like Java .jars/.NET assemblies/Python .pyc files. The purist in me prefers Self’s approach, the practical part of me prefers Factor/Common Lisp’s.]
Thank you for your response.
I am not sure I understand. Say I have an object A that contains another object B constructed in a particular way as a member. Now, if I edit the constructor of the object B, so that the variables inside B are initialized slightly differently, would it reflect on the already constructed object inside A?
Not in that specific case, no. For other things (e.g., changing variable names, class shape, changing a method definition, etc.), the answer is yes. The best way to think of it: the Smalltalk image is a database, and like most databases, if you change the schema or a stored procedure, that takes effect immediately, but existing data would need to be backfilled or changed. This is exactly the thing I was flagging on why Common Lisp and Factor do not do this: their images are code only, no data. (Or Self, for which the answer to your question is, at least in some cases, actually yes.)
This is different than the main thing highlighted in the article, though. There, the concern wasn’t as much about state existing at all, as much as the fact that the presentation made it look as if the output accurately reflected the input, which wasn’t guaranteed. Thus, in a notebook,
In: x = 5
is potentially not accurately reflecting the real value of x, whereas in Smalltalk, if you went behind the scenes and changed x to, say, 10, then any Inspector on x would also change immediately to 10.
Thanks again for the detailed response!
I understood the rest of the post, but I do not get it when you say that in Common Lisp (and Factor), image is code only, and not data. How is that different from storing everything in a file?
Eh, I probably confused things. The images for Factor and Lisp are just compiled code, effectively, albeit stored in a high-level format that’s designed to make debugging a running app a lot easier. That’s why I said they’re equivalent to Java .class files or the like. I was more mentioning that because the word “images” means something very different in Smalltalk/Self v. Common Lisp/Factor-like systems.
So, what does it mean when Factor says it has an image based model? Is it simply saying that it is compiled?
Going back to the original question; My experience is with R, where the image is frequently not a boon, unless one is very careful not to reuse variable names during data cleaning. And the linearity of notebooks isn’t a factor when you work in the command line. R does let you see the current definitions of everything but that is not as helpful as it first seemed to be. Hence my question.
Interesting! So if I define a class, instantiate it, change a method definition, and call that method on the class, the new definition is called?
That would indeed be much more useful than a notebook-like approach.
That’s completely correct, and also applies to certain other refactorings on the class (e.g., renaming instance variables or the like).
One problem I could see with image files is servicing them; how do you patch several image files, or worse, deal with divergences in each due to patching of behaviour?
Regarding the security of unikernels, I believe that there is a reasonable rebuttal from Bryan Cantrill: https://www.joyent.com/blog/unikernels-are-unfit-for-production
Nice read, but doesn’t sound like Cantrill is unbiased here.
He might be biased (joyent/containers vs unikernels) but @bcantrill’s opinions are usually more driven by wanting stronger engineering practices than marketing.