I think there’s some truth in it. A few weeks ago, I spent a day chasing a bug that ended up being a one-character fix. Recounting this to a non-programmer, the reaction was ‘I don’t understand why you like computers, that sounds really frustrating’. The same person happily spends hours doing Sudoku and similar puzzles and to me this kind of programming is just another kind of puzzle which, like cooking, has the added benefit that you get something tangible out at the end and not just the feeling of enjoyment from completing the game.
Whether you regard this kind of puzzle solving as frustrating or not probably has a large impact on whether you will find days full of programming to be an unmitigated torture of frustration or a joyful activity that you can’t quite believe people are willing to pay you for.
Of course, some parts (notably, almost anything involving build systems) will be frustrating for almost anyone.
I wonder why people seem to generally dislike two line prompts? I’ve fell in love with idea as soon as I’ve realized it is possible:
14:39:29|~/projects/rust-analyzer|master⚡*
λ
Having command at a fixed offset form the terminal edge makes scanning history of commands much easier, full path gives essential context, and time & git status are just nice touches.
Am I missing some reasons why single line prompts are more convenient?
Those are my reasons: predictability/ease of scanning. Most of my prompt is built to be as visually quiet as possible to help me focus. It’s a micro-optimization, but I love the feeling of it.
The only real issue with two line prompts that I know of is that fish has a few open bugs around handling of redraws in the presence of those. But that’s about it.
For me it’s mostly about reducing visual noise, everything I want in a prompt (directory and git status) fits comfortably in one line, optionally showing the exit status if it’s different from 0.
I just stick all that crap into RPROMPT, why waste two lines with optional information when the right prompt can deal with it and get overwritten if what you type gets longer?
We’ll have to disagree I guess then. My prompt in $HOME is literally:
$ .......a long way over to the right ->~
The right fills up with git status and dir information as I chdir around but otherwise I can’t stand my prompt taking up a bajillion characters based on the directory I’m in. I want all the crap i type to be at index 2 always. But thats just my weirdness really.
Also means less lines to delete when copy/pasting my history.
Mine is two lines as well, which kind of freaks out some people who don’t know it can even do that. This is mine, but I’d like to check out the return value stuff:
# define the unprinting start and end escape sequences, so bash doesn't
# count these as taking up room on the command line
UPb="\["
UPe="\]"
# Setup color variables
BLACK="$UPb\033[0;30m$UPe"
DGRAY="$UPb\033[1;30m$UPe"
RED="$UPb\033[0;31m$UPe"
LRED="$UPb\033[1;31m$UPe"
GREEN="$UPb\033[0;32m$UPe"
LGREEN="$UPb\033[1;32m$UPe"
BROWN="$UPb\033[0;33m$UPe"
YELLOW="$UPb\033[1;33m$UPe"
BLUE="$UPb\033[0;34m$UPe"
LBLUE="$UPb\033[1;34m$UPe"
PURPLE="$UPb\033[0;35m$UPe"
LPURPLE="$UPb\033[1;35m$UPe"
CYAN="$UPb\033[0;36m$UPe"
LCYAN="$UPb\033[1;36m$UPe"
LGRAY="$UPb\033[0;37m$UPe"
WHITE="$UPb\033[1;37m$UPe"
NEUTRAL="$UPb\033[0m$UPe"
export BLACK DGRAY RED LRED GREEN LGREEN BROWN YELLOW BLUE
export LBLUE PURPLE LPURPLE CYAN LCYAN LGRAY WHITE NEUTRAL UPb UPe
export PS1="*** $LCYAN\@$NEUTRAL *** $YELLOW\w$NEUTRAL ***\n"
I add the \h for host name in my work shell, because I ssh to a lot of places
Like you I prefer two line prompts primarily for the ease of scanning. My informational line does not drastically differ between locations and projects, but having a set size/location for my commands makes it very easy for me to scan.
The X Windows server I use for Windows is Xming, which has both a free and a paid version. The free version works like a champ with WSL - just run it, set DISPLAY=:0 and you’re good. But I guess it will be a little more complicated once I move to WSL2.
I imagine the exact same steps as VcXsrv should apply? Just make sure it’s allowed through Windows Firewall and that the DISPLAY variable is set to the IP address within /etc/resolv.conf but I’ve never tried it myself. I don’t think it’s as complicated as I would have expected it to be
Not really a Delphi / Pascal person, but I loved C++Builder, which leveraged the VCL controls. I even have a page (not updated since 2005!) full of links to C++Builder & VCL pointers:
Is there a good write up anywhere that goes into detail on what the VCL was? I’m curious if there are some interesting ideas in there that haven’t been re-implemented in modern systems.
I’m tempted to make another attempt at getting our audio code to work with the Android NDK. The last one a few years ago failed miserably, but there’s more interest in the mobile side of things again, so maybe time to try it once more.
Just got back home after a week away to the Mothership in London. Wow, what a fantastic city! I had a blast despite having to work for 4 days. We had great weather, so that sure helped. Can’t wait to go thru the photos.
Back to the grind this morning. Big expansion plans and we need programmers, so I’ll wade thru some resumes. Interested? Careers at Visionable
This week I need to focus on our desktop client. We need to get it released and luckily, Qt 5.12.5 has been release too, so we can move to that and hope it fixes some of our more gnarly display bugs. If I can get this out, I can move back to the API DLL, which I am writing in D, which I am loving!
I disagree. It’s the C++ I always wanted. Expressive, fast, unopinionated, flexible, easy to use. That’s its cause. Everyone is always like “but the GC…” and I’ve never cared about that. Maybe I’m not low-level enough or something, but the GC suits me just fine because I’ve never noticed it’s there.
I spent the day rewriting a lot of my personal scripts in D, and all I have to say is, “wow.” What a great language. Everything I struggled to do in C – strings, arrays, memory – doesn’t exist in D. It’s pretty expressive for a type-sensitive language. It reminds me a lot of Go.
I was only vaguely interested in reading this article to start with, mostly to see how git was visualized since I’m not familiar with it, but the page tells me this ’‘visual’’ guide requires JavaScript to display the visuals and so it’s not very visual for me.
Asides from this unnecessary JavaScript, however, it seems to be a fairly simple page, so I wonder why it isn’t simply static with, say, VIDEO tags or GIFs or whatnot. The only thing I notice is the visuals will apparently morph as you go along, but that’s not worth JavaScript, if you can’t even get that effect with CSS or whatnot.
Lastly, the end of the page has Google Analytics spyware, so that’s more than enough reason to not let the domain run JavaScript, if you were even considering it. I vehemently dislike when I come across what should be a static page, ofttimes with rather simple CSS, and yet it has this malware embedded in it, sometimes as the only JavaScript whatsoever. It’s disgusting.
To each their own I guess. I’m not freaked out by modern technology and new ways of presenting information. I thought it was a very interesting way to teach a fairly dry topic, esp. one I’m not too keen on but feel like i have to know better.
I remember enjoying the book but kind of upset that it talked so much about hardware and hardware design, giving the short shrift to the software guys.
Plugging away on an experimental interface to our conferencing app, one that places the windows into an MDI-like interface. We bringing on some UX “experts”, so we’ll see what they think. It can get confusing for folks when their video windows are scattered about the desktop. Maybe this will help.
If you wanted to know what I worked on in a past life, check out this insteresting and pretty accurate article on Looking Glass Technology and Ultima Underworld, my last game dev project:
It’s pretty easy with Qt. Our app, a video conferencing app, has a main UI window and, when in a meeting, creates a window for each video feed (which can be up to 32 or more - honestly!). I just created a new mainwindow with an QMdiArea widget in it and then just add all the others windows as QMdiSubWindows instead of right on the root window. Works pretty nice and keeps things easier to manage. I may experiments with leaving the main UI window outside and just create the MdiWIndow to contain video feeds when you join a meeting as well.
This is so peak C++, multiple memory allocations, #include <algorithm> which pulls in 17000 lines on my system, a 2500 word blog post, and a book advertisement to get nicer formatting when evaluating a boolean.
The solution he proposes is extremely bad on every axis, it’s glacially slow to compile and execute, requires the reader to understand a huge amount of the language vs understanding operators, and is completely inflexible.
How about:
bool good = true;
good = good && customer.purchasedGoodsValue()) >= 1000;
good = good && !customer.hasReturnedItems());
good = good && std::find(begin(surveyResponders), end(surveyResponders), customer) != end(surveyResponders);
bool bad = false;
bad = bad || customer.hasDefaulted();
good = good && !bad;
Work: Trying to get our program up to at least Qt 5.9. Unfortunately, I don’t have time to make it a 64bit app, so 5.9 is as far as we can go for now, as QWebEngine is 64bit only on Windows after that.
In my free time, I’d love to get up to speed on Rust.
A busy, bittersweet time - closing the camper for the season. Clean the camper, pull in the dock, take down the deck awning, that sort of stuff. Then we wait until next May. Sigh.
Oh crap, I didn’t mean it like that, haha :-)
But seriously, it’s pretty amazing, the fact that a software package is alive and keeps improving for decades and decades.
Very rarely can you hear someone is using a piece of software for 20+ years.
No worries! 20 years might be underestimating, actually :) There’s some stuff in my emacs config files even I don’t understand any more! This might even spur me on to cleaning it up - a once a decade occurrence.
Yes, absolutely. Ed was a good editor in the 1970s, when 300 baud links were reasonably fast things and teletypes with printed output were common, and even significantly into the 1980s, when you might still be dealing with 300 baud serial links (1200 baud if you were lucky), heavily overloaded systems, very dumb CRT-based terminals, or some combination of all three. About its only significant limitation in those situations is that it’s a single file at a time editor, which makes some things more awkward. Using any visual editor in those situations is a frustrating exercise in patience (or outright impossible on hardcopy teletypes or sufficiently dumb terminals).
The ancestors of ed, such as CTSS QED and it’s descendants on Multics (QEDX, Ted) all worked on multiple buffers, but those (and other) features were not carried forward to the simpler UNIX ed.
Given that Ken Thompson was fully familiar with QED et al (cf), the omission of multiple buffer support in ed is clearly deliberate. I wonder if Thompson felt forced to do it by resource constraints on Unix or if he just decided that it wasn’t important enough and omitting it simplified the experience in ways he wanted.
(By the time of V7 I suspect that resource constraints weren’t a big enough issue, and the Bell Labs people certainly were willing to rewrite programs if they should be improved. And I believe that people did versions of QED for early Unix, too.)
I don’t think I’ve ever actually used ed. I grew up in the 90s, so by then it was pico/nano. Is edlin from the MS-DOS days similar? If so I did use edline quite a bit, but would not be able to tell you anything about how to use it today.
Based on the edlin Wikipedia page, edlin is kind of a relatively simplified take on ed (although that’s not necessarily its historical origins). Full ed is fairly powerful, with a lot of text manipulation commands that don’t require you to retype lines to modify them and a bunch of ways of specifying what lines you want to operate on (including ‘lines that match this regular expression’). Interested parties can see the GNU ed manual. It’s probably simplest to start with the commands list if you want to see what ed is capable of.
(GNU ed is a moderate superset of V7 ed in both commands and its regular expression support.)
Nice! I’ll have to make an Emacs template for when I first open a Makefile to insert that boilerplate. I’d also add the code to generate the header file dependency tree using the correct g++ flags.
“Worker” seems like the standard almost everybody’s arrived at for that part of the architecture, while the name for the lazy bum in the middle is not really standardized. I’d go with “manager” or “hub”, though, if I were you.
Not sure I completely agree with the main premise - “A very high tolerance for daily, grinding frustration.” - but some probably see it that way.
I think there’s some truth in it. A few weeks ago, I spent a day chasing a bug that ended up being a one-character fix. Recounting this to a non-programmer, the reaction was ‘I don’t understand why you like computers, that sounds really frustrating’. The same person happily spends hours doing Sudoku and similar puzzles and to me this kind of programming is just another kind of puzzle which, like cooking, has the added benefit that you get something tangible out at the end and not just the feeling of enjoyment from completing the game.
Whether you regard this kind of puzzle solving as frustrating or not probably has a large impact on whether you will find days full of programming to be an unmitigated torture of frustration or a joyful activity that you can’t quite believe people are willing to pay you for.
Of course, some parts (notably, almost anything involving build systems) will be frustrating for almost anyone.
I wonder why people seem to generally dislike two line prompts? I’ve fell in love with idea as soon as I’ve realized it is possible:
Having command at a fixed offset form the terminal edge makes scanning history of commands much easier, full path gives essential context, and time & git status are just nice touches.
Am I missing some reasons why single line prompts are more convenient?
Those are my reasons: predictability/ease of scanning. Most of my prompt is built to be as visually quiet as possible to help me focus. It’s a micro-optimization, but I love the feeling of it.
The only real issue with two line prompts that I know of is that fish has a few open bugs around handling of redraws in the presence of those. But that’s about it.
For me it’s mostly about reducing visual noise, everything I want in a prompt (directory and git status) fits comfortably in one line, optionally showing the exit status if it’s different from 0.
I just stick all that crap into RPROMPT, why waste two lines with optional information when the right prompt can deal with it and get overwritten if what you type gets longer?
I‘ve tried the right prompt, but two lines work better for me, amusingly, for exactly same reason :)
Vertical space is cheap win infinite scroll, horizontal spaces feels significantly more crowded.
We’ll have to disagree I guess then. My prompt in $HOME is literally:
The right fills up with git status and dir information as I chdir around but otherwise I can’t stand my prompt taking up a bajillion characters based on the directory I’m in. I want all the crap i type to be at index 2 always. But thats just my weirdness really.
Also means less lines to delete when copy/pasting my history.
My prompt is 2 lines, but the second line has nothing. It’s really nice to start commands at column 0, and nudges me to use multi-line commands more.
Mine is two lines as well, which kind of freaks out some people who don’t know it can even do that. This is mine, but I’d like to check out the return value stuff:
I add the \h for host name in my work shell, because I ssh to a lot of places
You can replace all that color stuff with
%F{...}syntax, it’s going to be more readable.That just shows you how long I have dragged this along! And is that true as well for bash?
Honestly, idk. I discovered %F stuff a week ago, before that my config had a lot of vars with ANSI escapes too! :)
Like you I prefer two line prompts primarily for the ease of scanning. My informational line does not drastically differ between locations and projects, but having a set size/location for my commands makes it very easy for me to scan.
The X Windows server I use for Windows is Xming, which has both a free and a paid version. The free version works like a champ with WSL - just run it, set DISPLAY=:0 and you’re good. But I guess it will be a little more complicated once I move to WSL2.
I imagine the exact same steps as VcXsrv should apply? Just make sure it’s allowed through Windows Firewall and that the DISPLAY variable is set to the IP address within /etc/resolv.conf but I’ve never tried it myself. I don’t think it’s as complicated as I would have expected it to be
Not really a Delphi / Pascal person, but I loved C++Builder, which leveraged the VCL controls. I even have a page (not updated since 2005!) full of links to C++Builder & VCL pointers:
http://www.buddydog.org/C++Builder/c++builder.html
Actually surprised there doesn’t seem to be a ‘delphi’ or at least a ‘pascal’ tag.
Is there a good write up anywhere that goes into detail on what the VCL was? I’m curious if there are some interesting ideas in there that haven’t been re-implemented in modern systems.
No idea! VCL still is something!
This is pretty impressive! I can’t even find the time to do Linux From Scratch never mind write my own!
I’m tempted to make another attempt at getting our audio code to work with the Android NDK. The last one a few years ago failed miserably, but there’s more interest in the mobile side of things again, so maybe time to try it once more.
Just got back home after a week away to the Mothership in London. Wow, what a fantastic city! I had a blast despite having to work for 4 days. We had great weather, so that sure helped. Can’t wait to go thru the photos.
Back to the grind this morning. Big expansion plans and we need programmers, so I’ll wade thru some resumes. Interested? Careers at Visionable
This week I need to focus on our desktop client. We need to get it released and luckily, Qt 5.12.5 has been release too, so we can move to that and hope it fixes some of our more gnarly display bugs. If I can get this out, I can move back to the API DLL, which I am writing in D, which I am loving!
Get better a D! I’ve been using it (and loving it!) in a project at work and I want to get better at it.
Yay, D! I am enjoying it a lot too. If you wan to chat about it in irc, #d in Freenode has been pretty helpful to me.
I love D. Unfortunately, it’s still a rebel without cause.
I disagree. It’s the C++ I always wanted. Expressive, fast, unopinionated, flexible, easy to use. That’s its cause. Everyone is always like “but the GC…” and I’ve never cared about that. Maybe I’m not low-level enough or something, but the GC suits me just fine because I’ve never noticed it’s there.
I spent the day rewriting a lot of my personal scripts in D, and all I have to say is, “wow.” What a great language. Everything I struggled to do in C – strings, arrays, memory – doesn’t exist in D. It’s pretty expressive for a type-sensitive language. It reminds me a lot of Go.
I was only vaguely interested in reading this article to start with, mostly to see how git was visualized since I’m not familiar with it, but the page tells me this ’‘visual’’ guide requires JavaScript to display the visuals and so it’s not very visual for me.
Asides from this unnecessary JavaScript, however, it seems to be a fairly simple page, so I wonder why it isn’t simply static with, say, VIDEO tags or GIFs or whatnot. The only thing I notice is the visuals will apparently morph as you go along, but that’s not worth JavaScript, if you can’t even get that effect with CSS or whatnot.
Lastly, the end of the page has Google Analytics spyware, so that’s more than enough reason to not let the domain run JavaScript, if you were even considering it. I vehemently dislike when I come across what should be a static page, ofttimes with rather simple CSS, and yet it has this malware embedded in it, sometimes as the only JavaScript whatsoever. It’s disgusting.
To each their own I guess. I’m not freaked out by modern technology and new ways of presenting information. I thought it was a very interesting way to teach a fairly dry topic, esp. one I’m not too keen on but feel like i have to know better.
Great idea - time for a reread!
I remember enjoying the book but kind of upset that it talked so much about hardware and hardware design, giving the short shrift to the software guys.
Plugging away on an experimental interface to our conferencing app, one that places the windows into an MDI-like interface. We bringing on some UX “experts”, so we’ll see what they think. It can get confusing for folks when their video windows are scattered about the desktop. Maybe this will help.
If you wanted to know what I worked on in a past life, check out this insteresting and pretty accurate article on Looking Glass Technology and Ultima Underworld, my last game dev project:
https://www.filfre.net/2019/01/life-off-the-grid-part-1-making-ultima-underworld
Interesting and impressive! Would you be able to demonstrate what you mean with an MDI-like interface or the actual project?
It’s pretty easy with Qt. Our app, a video conferencing app, has a main UI window and, when in a meeting, creates a window for each video feed (which can be up to 32 or more - honestly!). I just created a new mainwindow with an QMdiArea widget in it and then just add all the others windows as QMdiSubWindows instead of right on the root window. Works pretty nice and keeps things easier to manage. I may experiments with leaving the main UI window outside and just create the MdiWIndow to contain video feeds when you join a meeting as well.
This is so peak C++, multiple memory allocations,
#include <algorithm>which pulls in 17000 lines on my system, a 2500 word blog post, and a book advertisement to get nicer formatting when evaluating a boolean.The solution he proposes is extremely bad on every axis, it’s glacially slow to compile and execute, requires the reader to understand a huge amount of the language vs understanding operators, and is completely inflexible.
How about:
Except ‘bad’ will always be false …
Work: Trying to get our program up to at least Qt 5.9. Unfortunately, I don’t have time to make it a 64bit app, so 5.9 is as far as we can go for now, as QWebEngine is 64bit only on Windows after that.
In my free time, I’d love to get up to speed on Rust.
And there’s already a du replacement called ‘dup’: https://github.com/ritze/dup
That’s a wrapper that hasn’t been touched in years.
A busy, bittersweet time - closing the camper for the season. Clean the camper, pull in the dock, take down the deck awning, that sort of stuff. Then we wait until next May. Sigh.
Yes - thanks for the post! I’ve been using Emacs for 20+ years and I still love hearing / reading about it.
Woah, 20+ years, 67% of my life :)
Gee thanks :)
Oh crap, I didn’t mean it like that, haha :-) But seriously, it’s pretty amazing, the fact that a software package is alive and keeps improving for decades and decades.
Very rarely can you hear someone is using a piece of software for 20+ years.
No worries! 20 years might be underestimating, actually :) There’s some stuff in my emacs config files even I don’t understand any more! This might even spur me on to cleaning it up - a once a decade occurrence.
Oh great - another pointless project I won’t be able to ignore!
I actually had to laugh when I saw this title. Was ed ever a “good” editor?
Yes, absolutely. Ed was a good editor in the 1970s, when 300 baud links were reasonably fast things and teletypes with printed output were common, and even significantly into the 1980s, when you might still be dealing with 300 baud serial links (1200 baud if you were lucky), heavily overloaded systems, very dumb CRT-based terminals, or some combination of all three. About its only significant limitation in those situations is that it’s a single file at a time editor, which makes some things more awkward. Using any visual editor in those situations is a frustrating exercise in patience (or outright impossible on hardcopy teletypes or sufficiently dumb terminals).
(I’m the author of the linked-to article.)
The ancestors of ed, such as CTSS QED and it’s descendants on Multics (QEDX, Ted) all worked on multiple buffers, but those (and other) features were not carried forward to the simpler UNIX ed.
Given that Ken Thompson was fully familiar with QED et al (cf), the omission of multiple buffer support in ed is clearly deliberate. I wonder if Thompson felt forced to do it by resource constraints on Unix or if he just decided that it wasn’t important enough and omitting it simplified the experience in ways he wanted.
(By the time of V7 I suspect that resource constraints weren’t a big enough issue, and the Bell Labs people certainly were willing to rewrite programs if they should be improved. And I believe that people did versions of QED for early Unix, too.)
I don’t think I’ve ever actually used ed. I grew up in the 90s, so by then it was pico/nano. Is edlin from the MS-DOS days similar? If so I did use edline quite a bit, but would not be able to tell you anything about how to use it today.
I never used edlin, but I’d guess that editor has more in common with CP/M ED than UNIX ed.
Based on the edlin Wikipedia page, edlin is kind of a relatively simplified take on ed (although that’s not necessarily its historical origins). Full ed is fairly powerful, with a lot of text manipulation commands that don’t require you to retype lines to modify them and a bunch of ways of specifying what lines you want to operate on (including ‘lines that match this regular expression’). Interested parties can see the GNU ed manual. It’s probably simplest to start with the commands list if you want to see what ed is capable of.
(GNU ed is a moderate superset of V7 ed in both commands and its regular expression support.)
Ed is the standard editor.
I’d have to say no - it was clearly inferior to the QED descendants QEDX (and it’s descendent, Ted), which preceded it.
In defense of ‘ed’, this simplification was a design decision, according to Ritchie.
When using Multics, I often find myself reaching for QEDX, especially for quick editing tasks.
Nice! I’ll have to make an Emacs template for when I first open a Makefile to insert that boilerplate. I’d also add the code to generate the header file dependency tree using the correct g++ flags.
Here’s the rule I use (GNUMake) to do the dependencies:
This will exclude the system header files, but include all local headerfiles. Remove the
-Yto include system headers.On BSD:
Better than this crufty make command I’ve been carrying around for probably 20 years!
Make already gets such overwhelmingly negative press so let’s not leave this as-is lest others think this is how things have to be. Here is mine:
Nice! I’m not even sure where I got mine, just a case of “leave it alone it works”.
Our code uses this terminology and if I had more time, I’d change it as well. Maybe just server / client?
If you want to keep all the terminology consistent with other apps, Travis CI seems to call them the “workers” and the “hub”. “Worker” is also used by TaskCluster, but they just call the central job thing “the queue.” Kubernetes calls its nodes the “master” and either “worker” or “minion”, and Docker Swarm has the “manager”, while the rest of them are just called “nodes”.
“Worker” seems like the standard almost everybody’s arrived at for that part of the architecture, while the name for the lazy bum in the middle is not really standardized. I’d go with “manager” or “hub”, though, if I were you.
I like the idea of Manager, because that’s what the main program does - manage all the other ones.
Server/client is already a term of art so that’s a bit loaded. I have always thought leader/follower is the most clear alternative.