Don't fall in love with your technology(prog21.dadgum.com)
prog21.dadgum.com
Don't fall in love with your technology
http://prog21.dadgum.com/128.html
14 comments
Of all the arguments for the author to pick, the "archaic" editor issue is probably the most insignificant/ most misunderstood. There is no arguing (at least in my little world) that using tools like vi/ emacs make you a FAR better programmer than hand holding IDE's like VS. When you need to make vi/ emacs do something for you, a knowledge not only of the programming process, but also the inner workings of the editor must be understood. There is really no better way to expand knowledge than being forced to do things for yourself. Perhaps one could make an argument for productivity (in regards to things like VS), but I believe that a skilled vi/ emacs user will be more productive in many languages, whereas most Microsoft coders live in a world of .Net, or Java coders live in a world of Java.
Disclaimer: Church of Emacs
Disclaimer: Church of Emacs
Geek loves to praise his tools and pulled assumptions over thin air for everything else.
vim/emacs are nice (I'm a vim user) but gosh... have you ever tried the latest JetBrains offering? PyCharm? RubyMine? the JS editor.
The only reason I'm using VIM is because I'm just that _weird_. My dream setup would be a 11"/13" laptop with nothing other than a console and a web browser. If IDEs can fit that screen (which they can't right now...) I would dump vim in an instant and never look back.
vim/emacs are nice (I'm a vim user) but gosh... have you ever tried the latest JetBrains offering? PyCharm? RubyMine? the JS editor.
The only reason I'm using VIM is because I'm just that _weird_. My dream setup would be a 11"/13" laptop with nothing other than a console and a web browser. If IDEs can fit that screen (which they can't right now...) I would dump vim in an instant and never look back.
That IS my setup at work. I've recently discovered mutt and irssi which I use for email and chat, respectively. All development happens in tmux sessions with vim. My dock contains finder, iterm2, chrome and the trashcan. If I could remove finder and the trashcan I would...
On a slightly related topic, I've started investigating writing a console based email client recently in Python using Urwid for curses stuff that's a little less archaic than mutt.
On a slightly related topic, I've started investigating writing a console based email client recently in Python using Urwid for curses stuff that's a little less archaic than mutt.
You have to know what type of person you are. If you love solving problems and bringing something new to the market, then don't stick to any technology like a religion, they are just tools, and a means to an end.
If you like coding as a hobby, then feel free to fall in love with the technology, but realize you might not be taking the best path to creating something useful or solving problems.
If you like coding as a hobby, then feel free to fall in love with the technology, but realize you might not be taking the best path to creating something useful or solving problems.
I get it about Forth, but not so sure about vi/emacs/makefiles - what does the author think was used to build his beloved touchscreen displays?
Ipad software is not written on an ipad.
Ipad software is not written on an ipad.
Why would anyone expect anything but talk about the language forth in comp.lang.forth? And this isn't the first time the blog tries to make possibly valid points through a bunch of bad examples, the most prominent example being "Free your technical aesthetics from the 1970s" which was factually wrong for the most part (yet he still stands by it).
I think I'm being trolled, therefore I'm removing it's feed from my reader.
I think I'm being trolled, therefore I'm removing it's feed from my reader.
Wow, I thought this was a community that valued shipping. All the top comments here say otherwise. Where are the makers?
I've recently realized that most of the enjoyment I derive from building things comes from the process (figuring out neat / new ways to do things, debugging, thinking). Shipping is a necessary tedium for me. Maybe people like me have more fun fiddling with the minutiae of our tools than actually "doing cool things".
No value judgment there, just an observation.
No value judgment there, just an observation.
I used to feel the same way but after many years of tinkering with languages, tools, operating systems etc the novelty began to wear off and I began to feel unsatisfied by the things I'd actually shipped into the world.
These days I get far more satisfaction from putting something new that's useful or fun in front of users and I don't care much exactly what it took to get it there.
These days I get far more satisfaction from putting something new that's useful or fun in front of users and I don't care much exactly what it took to get it there.
For me it was probably hanging out on HN for the last two years that changed my mindset. I used to like spending time building (as in, building forever, not shipping) things with interesting technologies and great attention to code style, etc. Right now I try to focus on making something useful for me or others[1]. Programming is now more of a tool (one of many) than an art for me (though I still love to play around with technologies and concepts).
I blame this mindshift on the prevailing focus on shipping something useful ASAP that can be seen here :).
[1] - to the point that yesterday, after spending few hours researching available software and technologies, I decided to pay few bucks for a solution that I would normally strive to code myself.
I blame this mindshift on the prevailing focus on shipping something useful ASAP that can be seen here :).
[1] - to the point that yesterday, after spending few hours researching available software and technologies, I decided to pay few bucks for a solution that I would normally strive to code myself.
This sounds like an engineer chiding artists for not being productive.
There's nothing wrong with deriving pleasure from deep analysis of a programming language - similarly with all of art or mathematics.
Feel free to fall in love with your technology, just realize it's not as likely to make you rich if your goal isn't to ship product.
There's nothing wrong with deriving pleasure from deep analysis of a programming language - similarly with all of art or mathematics.
Feel free to fall in love with your technology, just realize it's not as likely to make you rich if your goal isn't to ship product.
This author enjoys turning a nice line of code or structuring a nice program as much as anyone. Read his past posts. I don't see anything here remotely against art or enjoying the challenge of your work. The point is for him it's important not to get lost in the tools at the expense of not making things.
Agreed, completely, however there is one difference: When an artist ceases to ship, they starve.
Art, like science, is not necessarily a profession. It can be an avocation. There are many important artists and scientists that did not support themselves with their art or science.
"l'Unix pour l'Unix" (Unix for Unix's sake)?!
I know some folks who are like that. I think most of the Unix/Linux advocates I personally know started this way.
He mentions vi/emacs debate, but perhaps more relevant is all the Linux Desktop and KDE/Gnome drama. Tablets and touchscreen interfaces blow the entire desktop paradigm to smithereens. The desktop UI is done, folks. The Linux community needs to wake up. All that drama, all the work on creating competing UI widget codebases, window managers, etc, and it's ALL going to get thrown out with the bathwater.
Could you please explain the sentiment about the desktop paradigm becoming outmoded? People seem to say this so frequently and I can't understand it at all. What about people who write code, for example? Do you expect them to be able to achieve the same standard of productivity as they currently can on <insert favorite platform here>?
Don't worry; ten years from now some people will still shout how wonderful is yet another Apple's ultimate hardware build from "miraculously excavated" Jobs' notes -- for instance an eye-track-controlled sphere covered with continuous display showing only "Give 10$ to Apple" button. While others will fork dwm to overcome recent "overly revolutional" changes which catastrophically degraded their productivity.
People who write code are a tiny, tiny, tiny fraction of the overall computer-using population. That fraction will only get smaller in the years to come as mobile devices get cheaper and more capable.
Traditional desktop interfaces will survive, but they will survive in the same way that, say, Emacs survives -- as a niche product for that tiny market segment, not as the default way the Teeming Millions interact with their personal tech.
Traditional desktop interfaces will survive, but they will survive in the same way that, say, Emacs survives -- as a niche product for that tiny market segment, not as the default way the Teeming Millions interact with their personal tech.
Let everybody interact in the way they want. That is freedom of choice. And the secret lies in the interfaces and protocols. I can read email in many different ways. That is the freedom the protocol gives me. It is open, well documented and wide spread.
We should strive to support open protocols instead of closed APIs which are controlled by single companies.
Then everybody can use whatever User Interface they prefer and everbody can come up with new User Interfaces any time.
The AIM/ICQ/MSN vs. XMPP world illustrates this principle. Even if someone supports the closed protocols with a multi protocol client, the support eventually gets deliberately broken by the controlling party.
Protocols are way more important than the currently popular implementation of it.
We should strive to support open protocols instead of closed APIs which are controlled by single companies.
Then everybody can use whatever User Interface they prefer and everbody can come up with new User Interfaces any time.
The AIM/ICQ/MSN vs. XMPP world illustrates this principle. Even if someone supports the closed protocols with a multi protocol client, the support eventually gets deliberately broken by the controlling party.
Protocols are way more important than the currently popular implementation of it.
> People who write code are a tiny, tiny, tiny fraction of the overall computer-using population. That fraction will only get smaller in the years to come as mobile devices get cheaper and more capable.
Hm, but only as long as the saturation of "computers" is increasing rapidly. If you were to focus on a developed country with good smart phone penetration, I think it's possible that the percentage of coders is increasing as old people die and young people take to new technology more readily. I guess maybe it depends on where you draw the line between power user/script kiddie/programmer.
Hm, but only as long as the saturation of "computers" is increasing rapidly. If you were to focus on a developed country with good smart phone penetration, I think it's possible that the percentage of coders is increasing as old people die and young people take to new technology more readily. I guess maybe it depends on where you draw the line between power user/script kiddie/programmer.
That fraction will only get smaller in the years to come as mobile devices get cheaper and more capable.
I doubt this statement. The number of people that write code is bound to increase in the future, not become smaller. And that has (among other things) to do with mobile devices getting cheaper and more capable. And generally with further increase of automation / software complexity. And with more people that want to be producers instead of consumers in the computer age...
I doubt this statement. The number of people that write code is bound to increase in the future, not become smaller. And that has (among other things) to do with mobile devices getting cheaper and more capable. And generally with further increase of automation / software complexity. And with more people that want to be producers instead of consumers in the computer age...
I'm talking about percentages. It's not that the population of programmers won't grow; it's that the population of non-programming users will grow more.
I code for 8 hours a day at work using gnome shell. It works perfectly fine. I'm equally productive in OS X. So yes, I do.
Sure, but the question is whether you would be equally productive on Android with a touchscreen instead of keyboard. I know I wouldn't.
what? how is that the question? the argument is that the desktop paradigm is on its way out, not that the keyboard is. the goal is to have a consistent UI that can be used equally well from a touchscreen or a mouse/keyboard interface. nobody is suggesting killing the keyboard, that's retarded.
So keyboard and mouse is in no way desktop paradigm? Really?
Fifteen years ago it was the web browser that was going to blow the desktop OS to smithereens. Larry Ellison announced the "network computer" that had no local storage (i.e., no hard drive) booted from the net and revolved around the browser. Although the web browser has become more important over the last 15 years, the only thing we have today that resembles a network computer is the Google Chromebook, and the only people who have those things are people who got them below cost and want to replace the (Chrome) OS with a desktop OS and (returning to the theme of the OP) people who really really really love the web.
There has been over 30 years of research and field experience with the WIMP paradigm. The code bases (source trees) for the three most "popular" (most relied-on) desktop OSes are over 20 years old. (Yes, I know that the code base for Windows XP and later differs from that of Windows 98 and earlier, but the code base for XP and later, namely, the NT code base, is itself over 20 years old if you count the final 18 months or so of its pre-release development.) I concede that there is a good chance that iOS and Android and Windows Metro will eventually kill the desktop OS, but that is going to take another 10 years and probably significantly longer.
There has been over 30 years of research and field experience with the WIMP paradigm. The code bases (source trees) for the three most "popular" (most relied-on) desktop OSes are over 20 years old. (Yes, I know that the code base for Windows XP and later differs from that of Windows 98 and earlier, but the code base for XP and later, namely, the NT code base, is itself over 20 years old if you count the final 18 months or so of its pre-release development.) I concede that there is a good chance that iOS and Android and Windows Metro will eventually kill the desktop OS, but that is going to take another 10 years and probably significantly longer.
The web already has replaced Windows desktop software for most peoples uses of a computer. Facebook, news, email, photo sharing (flikr), music (di.fm), video (youtube)... That's all most people need from a computer and tablets, with an optional keyboard accomplish this just fine.
There is no inherent reason that people need to use a virtual desktop, remote controlled by a mouse. The desktop metaphors, overlapping windows, cascading menus, constant nagging popups, files and folders, hardware drivers, blue screens... all this stuff is a nightmare for average users. They are already abandoning the desktop model because it never worked very well.
There is no inherent reason that people need to use a virtual desktop, remote controlled by a mouse. The desktop metaphors, overlapping windows, cascading menus, constant nagging popups, files and folders, hardware drivers, blue screens... all this stuff is a nightmare for average users. They are already abandoning the desktop model because it never worked very well.
I kinda agree. Android desktop should be the next linux desktop.
Then we can forget about windows/osx/gnome/kde/...
Then we can forget about windows/osx/gnome/kde/...
...and continue onwards with GO Launcher vs. Launcher Pro vs. Zeam vs. ...
I love the sentiment that the love should be directed towards what we produce. It’s natural that the tools that enable it should be part of that feeling. But the satisfaction is in the product.
Every tool I use is someone else's product, and I'm glad they love it. In fact, I demand that they love it. For me, that's what separated Unix from Mac OS and Windows when I was first exposed to it over a decade ago. Unlike in those other two operating systems, here wasn't a separation between the ugly, dirty parts no one was supposed to love and the beautiful parts that "mattered." In Unix, and now in Linux, I might just use the filesystem to store my source code files -- it's just a tool for me -- but there's somebody who loves the filesystem and makes it as beautiful for me as they know how.
Those that don't understand 'Makefiles' are doomed to reinvent them, poorly.
It's hard to reinvent something that is so poorly designed, any more poorly.
You'll be surprised !! - http://www.cmake.org/
cmake is not a makefile reinvention! Like GNU automake, it generates makefiles (or input files for VisualC/XCode). It configures the build for the specific target system, and library versions and locations.
"That's the same year that multi-touch interfaces exploded, low power consumption became key, and the tired, old trappings of faux-desktops were finally set aside for something completely new. "
Funnily, this statement sounds a lot more like it is spoken by someone who has fallen in love, in this case someone infatuated with multi-touch interfaces and so on.
It sounds like the author is arguing that new is automatically better. I mean, I think I understand the point he is trying to make about being trapped in the familiar and being unable to appreciate new approaches, I just don't think it's said very well here. Is he claiming that input interfaces and power consumption are areas of technology that are seeing high innovation and rapid adoption of new ideas, in contrast to the area of build systems and editors? That seems patently absurd to me. Input devices have barely changed at all since the typewriter (the exception would be the invention of the mouse), and although touch interfaces have uses in some areas, in others they are not an improvement at all - one new piece of input technology making it into general use since the sixties does not rapid innovation make. Oh, and build systems and editors are the two things where there are new approaches popping up all the time. The latest I heard was that google Go will ship version 1 with their own build system, for example.
Funnily, this statement sounds a lot more like it is spoken by someone who has fallen in love, in this case someone infatuated with multi-touch interfaces and so on.
It sounds like the author is arguing that new is automatically better. I mean, I think I understand the point he is trying to make about being trapped in the familiar and being unable to appreciate new approaches, I just don't think it's said very well here. Is he claiming that input interfaces and power consumption are areas of technology that are seeing high innovation and rapid adoption of new ideas, in contrast to the area of build systems and editors? That seems patently absurd to me. Input devices have barely changed at all since the typewriter (the exception would be the invention of the mouse), and although touch interfaces have uses in some areas, in others they are not an improvement at all - one new piece of input technology making it into general use since the sixties does not rapid innovation make. Oh, and build systems and editors are the two things where there are new approaches popping up all the time. The latest I heard was that google Go will ship version 1 with their own build system, for example.
It reads like a rambling. He's pitting Linux advocates against touch technology? I don't even understand why. Android is based on Linux, and Ubuntu has been developing a touch-friendly interface for a long time.
And what does that have to do with makefiles? Is there suddenly some magical "miniority report" touch wand that replaces them? (yes, I know there are alternative systems, but they're generally a new syntax for representing the same thing)
"Absurd" is indeed the appropriate word. Too much of the tech brochure cool-aid...
And what does that have to do with makefiles? Is there suddenly some magical "miniority report" touch wand that replaces them? (yes, I know there are alternative systems, but they're generally a new syntax for representing the same thing)
"Absurd" is indeed the appropriate word. Too much of the tech brochure cool-aid...
Forget the details. They are examples. Back up. Make something.
Huh? Like "don't read the article, that's just details, make something!".
But it can't be Linux-based? Or use makefiles?
To "make something" you do need to care about details. At least a bit (depending on the complexity).
But it can't be Linux-based? Or use makefiles?
To "make something" you do need to care about details. At least a bit (depending on the complexity).
No, like read the article and get the point he's trying to make instead of insisting that he's judging one tool against another.
Click around and read some archives on that blog. The author writes lots of interesting things about all different kinds of technology, lots of it quite old. But he also writes from a perspective of what it means to him. Far from infatuation with the latest and greatest from Apple. That's an example, for crying out loud. Just read the last paragraph of the OP over and over until it sinks in.
I don't think I mentioned Apple? You say it's an example, but an example of what? If I misunderstood what he meant, then perhaps you can enlighten me.
I did the read the last paragraph of the OP, and I tried to summarize my interpretation of it in my post. If you disagree, perhaps it would be helpful if you shared your point of view. Just telling me to read it again is not very informative.
I did the read the last paragraph of the OP, and I tried to summarize my interpretation of it in my post. If you disagree, perhaps it would be helpful if you shared your point of view. Just telling me to read it again is not very informative.
But, but... which should I use, Emacs or Vim???
This might be the explanation for the unthinking conservatism influential in the Linux community.
Can you quote some examples of this? Like in any community there is a lot of conservatism, but how is it influential?
I hear quite some complaints that Ubuntu/Debian/kernel changes are going too fast, more than that it is going too slow. Seems the conservatists complain a lot (about the new UIs, about new logging systems, about new init daemons, about new process IPC systems, etc) but are not really that influential on the actual projects.
What am I missing?
I hear quite some complaints that Ubuntu/Debian/kernel changes are going too fast, more than that it is going too slow. Seems the conservatists complain a lot (about the new UIs, about new logging systems, about new init daemons, about new process IPC systems, etc) but are not really that influential on the actual projects.
What am I missing?
An example of the influence of conservatism is the fact that important parts of GNU/Linux (e.g., all of the terminal-emulation applications) rely on pseudo terminals (PTYs). In contrast, Plan 9's kernel never supported PTYs and Plan 9's analog to a terminal emulator (namely, the thing you use to interact with a shell) never relied on them -- and Plan 9 started in the mid-1980s. There is a real terminal emulator available on Plan 9 (called vt100 IIRC) but it is implemented entirely in userland and nothing else in a typical Plan 9 install depends on it.
Yes, there is benefit to being able to get kernel messages during boot over an RS-232 link, but note that the whole infrastructure of TERMCAP files and cursor addressing is not needed for that capability, and yet TERMCAP files and cursor addressing remain an integral part of Linux -- if your TERMCAP file is misconfigured or your TERM environment variable is set wrong, you might be unable to get to a shell prompt.
Part of the reason this "cursor addressing" infrastructure is still integrated into IIUC all of the important distros is that reducing technical debt in a distro is a thankless task, but (since the complete dominance of the ncurses library for cursor addressing makes ("made"? Mabye ncurses is no longer completely dominant -- I've been away from Linux for a few years) it fairly easy to remove TERMCAP files, etc, from the set of things that have to be configured correctly to get to a shell prompt) I think that part of the reason that if your TERMCAP file is messed up, you might not be able to get a shell prompt is the hesitancy to change the design of the parts of a distro that come from the Unix of Bell Labs in the 1970s, which is frequently talked about in reverential tones.
(Yes, I know that cursor addressing might not date back to the 1970s, but it does date back to the 1980s and is now considered fairly integral to one of the things (the PTY) that was in Unix from the beginning.)
Note that it is possible for Linux to suffer from conservatism and from unnecessary design churn at the same time. For example, the design churn might be restricted to the parts of Linux that do not come from the Unix of the 1970s.
For a second example of conservatism in Linux, consider the persistent of /usr as discussed recently in
http://news.ycombinator.com/item?id=3519952
Yes, there is benefit to being able to get kernel messages during boot over an RS-232 link, but note that the whole infrastructure of TERMCAP files and cursor addressing is not needed for that capability, and yet TERMCAP files and cursor addressing remain an integral part of Linux -- if your TERMCAP file is misconfigured or your TERM environment variable is set wrong, you might be unable to get to a shell prompt.
Part of the reason this "cursor addressing" infrastructure is still integrated into IIUC all of the important distros is that reducing technical debt in a distro is a thankless task, but (since the complete dominance of the ncurses library for cursor addressing makes ("made"? Mabye ncurses is no longer completely dominant -- I've been away from Linux for a few years) it fairly easy to remove TERMCAP files, etc, from the set of things that have to be configured correctly to get to a shell prompt) I think that part of the reason that if your TERMCAP file is messed up, you might not be able to get a shell prompt is the hesitancy to change the design of the parts of a distro that come from the Unix of Bell Labs in the 1970s, which is frequently talked about in reverential tones.
(Yes, I know that cursor addressing might not date back to the 1970s, but it does date back to the 1980s and is now considered fairly integral to one of the things (the PTY) that was in Unix from the beginning.)
Note that it is possible for Linux to suffer from conservatism and from unnecessary design churn at the same time. For example, the design churn might be restricted to the parts of Linux that do not come from the Unix of the 1970s.
For a second example of conservatism in Linux, consider the persistent of /usr as discussed recently in
http://news.ycombinator.com/item?id=3519952
The advantage of a PTY paradigm is that there is simply an input/output stream consisting of text and control commands, which can be transparantly sent over the network (ssh), over a RS-232 link (embedded debugging), and so on.
What would you propose as a replacement? There have been ideas of using HTML/JS, streams and objects instead (see TermKit), among other things. Which certainly has some advantages. But for most things, the current terminal works fine. The terminal is mainly used as fallback anyway, new developments mostly focus on GUIs.
Don't get me wrong: it would be great if people agreed on one TERMCAP format and threw away the rest (just like I'd love people to just settle on UTF-8 encoding for text). But that seems to be the case in recent distro's. They work out of the box. I haven't had to bother with TERMCAP settings in Linux in like 10 years... with Solaris it's a different issue...
And I agree that the /usr directory structure being cleaned up was long due.
What would you propose as a replacement? There have been ideas of using HTML/JS, streams and objects instead (see TermKit), among other things. Which certainly has some advantages. But for most things, the current terminal works fine. The terminal is mainly used as fallback anyway, new developments mostly focus on GUIs.
Don't get me wrong: it would be great if people agreed on one TERMCAP format and threw away the rest (just like I'd love people to just settle on UTF-8 encoding for text). But that seems to be the case in recent distro's. They work out of the box. I haven't had to bother with TERMCAP settings in Linux in like 10 years... with Solaris it's a different issue...
And I agree that the /usr directory structure being cleaned up was long due.
>What would you propose as a replacement?
No offense but I'd rather not elaborate except to refer you again to Plan 9 as a proof of feasibility: thousand of man hours have been spent by people using Plan 9 to interact with remote shells.
No offense but I'd rather not elaborate except to refer you again to Plan 9 as a proof of feasibility: thousand of man hours have been spent by people using Plan 9 to interact with remote shells.
[deleted]
The complete and utter inability to come up with a consistent, modern, human-readable, non-arbitrary directory structure comes to mind. People are so blinded by the arbitrarily "designed" [1] FHS they refuse to even entertain the idea that it might just be time to replace it with something better.
[1] http://www.osnews.com/story/25556/Understanding_the_bin_sbin...
EDIT for clarification: layers upon layers upon layers of virtual directory structures don't count. It only adds complexity and makes the system more obtuse.
[1] http://www.osnews.com/story/25556/Understanding_the_bin_sbin...
EDIT for clarification: layers upon layers upon layers of virtual directory structures don't count. It only adds complexity and makes the system more obtuse.
I freely admit that being very familiar with older tools and paradigms will make me unfairly biased against new approaches that may in fact be objectively better. But network effects being what they are, I'm not particularly keen on striking out after novel approaches (Plan 9 sounds like a massive improvement on Unix paradigms, but whose got the time?).
Of course I don't really have a problem shipping. I tend to keep my eye on the ball, sharpening tools only as an occasional distraction, so I guess the article isn't directed at me.