

Don't fall in love with your technology - angrycoder
http://prog21.dadgum.com/128.html

======
krig
"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.

~~~
wladimir
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...

~~~
shoover
Forget the details. They are examples. Back up. Make something.

~~~
wladimir
Huh? Like "don't read the article, that's just details, make something!".

But it can't be Linux-based? Or use _make_ files?

To "make something" you do need to care about details. At least a bit
(depending on the complexity).

~~~
shoover
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.

------
frodwith
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.

~~~
cageface
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.

~~~
TeMPOraL
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.

------
klochner
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.

~~~
rbxbx
Agreed, completely, however there is one difference: When an artist ceases to
ship, they starve.

~~~
commieneko
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.

~~~
twelvechairs
"l'Unix pour l'Unix" (Unix for Unix's sake)?!

~~~
TeMPOraL
I know some folks who are like that. I think most of the Unix/Linux advocates
I personally know started this way.

------
dasil003
He mentions vi/emacs. I am pretty much in love with vim, and I anticipate
never using another editor for my daily work. This will certainly prevent me
from discovering the joys of Microsoft's latest toolchain. On the other hand,
I think it makes a much wider world of programming accessible because of the
richness of the Unix world.

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.

~~~
fein
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

~~~
hello_moto
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.

~~~
198d
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.

------
mwsherman
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.

~~~
dkarl
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.

------
AznHisoka
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.

------
ivix
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.

------
EdiX
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.

------
shoover
Wow, I thought this was a community that valued shipping. All the top comments
here say otherwise. Where are the makers?

------
hollerith
This might be the explanation for the unthinking conservatism influential in
the Linux community.

~~~
wladimir
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?

~~~
hollerith
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>

~~~
wladimir
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.

~~~
hollerith
>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.

------
silon3
Those that don't understand 'Makefiles' are doomed to reinvent them, poorly.

~~~
Peaker
It's hard to reinvent something that is so poorly designed, any more poorly.

~~~
eliben
You'll be surprised !! - <http://www.cmake.org/>

~~~
wladimir
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.

~~~
eliben
I know that :) But if one thinks Makefiles are complex with ugly syntax, CMake
will be a revelation (more complex, uglier syntax)

------
wavephorm
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.

~~~
ek
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>?

~~~
smacktoward
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.

~~~
wladimir
_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...

~~~
smacktoward
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._

------
Tichy
But, but... which should I use, Emacs or Vim???

