What's so different about Obsidian that sets it apart from previous plugin-based architectures? In particular, what is true about Obsidian which wasn't true about Eclipse some 20 years ago?
The marketing department sets it apart
Kernighan and Pike were right: Do one thing, and do it well
71–80 of 256 posts
Re: Kernighan and Pike were right: Do one thing, and do it well
#72The point about "do one thing" is that it takes a lot of rewrites to work out what one thing to do, and where the boundaries are.
Unix tools have developed in tandem in the unix ecosystem over decades of rewrites. They rubbed the rough edges off of each other.
The major failing of most "systems design", architecture and companies is a reluctance to replace what is there with something better. No one likes a rewrite.
And this affects microservices too. Once a microservice exists it's boundaries are defined. sure you can rewrite it to be more peformant but you cannot chnage its interfaces or it's scope - something is depending on that.
The ability to reform those interfaces is what makes it possible to grind down and find the one thing to do well.
And that takes lucking into the right fundamentals and being willing and able to make large scale changes.
"Move fast and break things" might actually be excellent advice
Re: Kernighan and Pike were right: Do one thing, and do it well
#73Two things come in mind after reading this:
There is no contradiction between monolith and DOTADIW. The code unit is the function, so each function does one thing and does it well.
I don't get why microservices is the opposite of large code base : having the code splitted in different files or in different repo, changes nothing about the sum of all lines of code, no ?
Re: Kernighan and Pike were right: Do one thing, and do it well
#74Earlier quoted context omitted.
I think you’re actually making the point for him here. You are correct that GNU is not Unix. And what version of ls has the most installations? I betcha it’s the ls from GNU Coreutils. I do agree that GNU tools are sometimes too maximalist. But they are also more useful than the minimalist alternatives.
I don't believe GNU's triumph over the BSD derivates was for the most part technical, they just happened to be at the right moment at the right time to ride along Linux's success. A consequence of the proliferation of arguments in the GNU tools is imho that it made the GNU manpages too verbose and information dense to the detriment of their usefulness.
Good point. However: The users could have revolted and gone to *BSD land instead. But for some reason, most users didn’t.
Re: Kernighan and Pike were right: Do one thing, and do it well
#75Can't say I love Obsidian being held up as the best we can do for program design. It's closed source. It could be an elaborate system of duct tape and string holding the thing together. I mean it likely is quite good based on their velocity and quality. But if we're to learn anything I'd really like to see its source code.
It’s okey to prefer open source over proprietary applications. But obviously we can still learn lessons about interface design from proprietary systems. We don’t need the source code in order to observe those aspects of the application. (And if we need understand how to application operates under the hood, it’s entirely possible to use tools like IDA and Ghidra.)
Make an extensible platform through a plug-in facility is hardly new or specifically closed source solutions, doesn't it?
Re: Kernighan and Pike were right: Do one thing, and do it well
#76You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…
I also don't get the comparison to UNIX philosophy into the domain of service development. These are totally different domains with their own patterns of resource usage and interaction. Piping "fairly" simple input -> output code that is sharing machine resources and releasing them at the end of execution is total different than running a micro service architecture across multiple containers/hosts. Even if some of th…
Unix has a lot of services that listen to 'localhost'. It has had elements of a service oriented architecture since the first daemon was launched, even though the IPC endpoint wasn't always something listening to a socket.
Re: Kernighan and Pike were right: Do one thing, and do it well
#77example of program "so simple it might be free of bugs" is buggy.
classic bad tool work.
EDIT: imagine a line starting 'pub fn'. correct solution? use parsers for parsing, not hacks.
Re: Kernighan and Pike were right: Do one thing, and do it well
#78I’ve been learning PowerShell recently and as I was writing down the good things about learning about a shell scripting language I came to this conclusion.
I normally use Python for things like this, but I have gotten burned more times than I care to admit with simple scripts having dependency issues.
I realized that shell languages are not only smaller languages, but are more limited in scope. This means there are less dependency issues to handle.
On top of that PowerShell scripts are easy to stitch together with pipes, so doing things like parallelizing and sending a job to the background as a task, then checking on it later is a lot easier.
Furthermore the stitching together of shell feels very functional, and because the cmdlets only do one thing getting it to be parallelized is infinitely easier. To this day PowerShell is the only code I’ve ever parallelized on purpose.
I then realized this was all possible due to the self contained nature of the cmdlets, which goes back to the Unix philosophy invented in 1969, about doing one thing and one thing well
Re: Kernighan and Pike were right: Do one thing, and do it well
#79To count the number of functions in a rust file you could run: cat main.rs | grep "^\s*fn\s" | wc -l This both promotes the "one thing well" model, while revealing its inherent limitations. How many functions are in this rust file? /* confuse things fn fo fp fn fm fl */ fn main() { println!("Hello, world!"); } The above grep reports two, when there is only one. It can be made to work if everyone agrees to follow conv…
This sort of heuristic bugs me too. We should be able to write language server-adjacent tools which could do this sort of thing as easily as grep. You could do a lot of useful stuff with that, for example to implement custom linting rules: - Count non-comment tokens within each scope, to look for complex scopes: `foo --tokens --exclude-comments --group-by=scope` - Count expressions (as opposed to just SLOC) per funct…
Most languages are open source, it should not be difficult to extract their parser and do this stuff. As far as I know, only Babel ( JavaScript ) and Java have a plugin ecosystem, but only related to compiling.
Re: Kernighan and Pike were right: Do one thing, and do it well
#80The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusable parts. It's one of the key ideas in functional programming, and it's somewhat core to object-oriented programming. (OO is too big to be able to claim their is a consistent philosophy behind it.) But ... firstly, let's stop with the Unix worship. They didn'…
Let's just be careful what we call Unix though. In SVR4, I don't think "ls" had that many options. It didn't even have colour (not that I would know; my Wyse 60 could only have Green, Orange or White text... and the colour was set in the factory). It's the same for many programs that started small but grew loads of knobs with age. You can't claim that this was the Unix vision, because what we call Unix today isn't ev…
FWIW, ls in Research-V6 back in 1975 had 10 options. https://github.com/dspinellis/unix-history-repo/blob/Researc...
By BSD 3 in 1980 it had 11 options. https://github.com/dspinellis/unix-history-repo/blob/BSD-3-S...
The thing is, we can see even from the 1970s 'ls' how the Unix model doesn't meet the goal "to chain these simple programs together to create complex behaviors".
There is no option to escape or NUL terminate a filename, making it possible to construct a filename containing a newline which makes the output look like two file entries.
The option for that was added later.
There's also the issue that embedded terminal codes will be interpreted by the terminal.