
Letter to John Carmack - austinhallock
http://www.phoboslab.org/log/2012/08/letter-to-john-carmack
======
tumult
I am 100% with Carmack. Sorry, guy. JavaScript is crap. The reasons that
JavaScript sucks have been hashed to death in the past. If you are already
disagreeing with me, then anything I say here won't change your mind, because
you've already heard the arguments before and built up a repertoire of
responses. That's fine, whatever floats your boat. Lots of fun games have
been, and will be written, in silly languages like JavaScript and ActionScript
and whatever. People used to write games in assembly, and they were still fun.
In the end, it's the game that matters.

But don't tell John Carmack, or any of the other many people who have been
writing simulation engines and 3D rendering engines since around when you were
born to use your web browser scripting engine. Seriously. (Also before I was
born.)

And unsecured access to the graphics stack is a terrible idea. Flash already
randomly causes my GPU to crash.

~~~
greggman
I've been writing "writing simulation engines and 3D rendering engines since
around when you were born" and I love JavaScript.

Like most C/C++/ASM programmers I hated it at first and I'm under no delusion
that it's going to replace C/C++/ASM any time soon. But like many say, "the
right tool for the job". By any measure Lua is complete shit and yet Carmack
made it popular by using as the glue for most of his games.

JavaScript does many things extremely elegantly and the environment it runs in
is fun, cross platform and accessible. It's fun to make things in JavaScript
the same way it was fun to make programs on my Atari 800, Commodore 64. You
type something and click "refresh" and it's up. No downloading a 2-4gig dev
environment. No finding 4 SDKs you need to install. No figuring out how to get
your image libraries to link. No worrying about how to get the initial screen
up,

And even better, when it works you just send you friends a link. No
installing. No worries if they are on OSX and you are on Windows or Linux.

Are you going to write Shadow of the Colossus in JavaScript? Probably not. But
ICO? Yea, no problem. Any Zelda to date? Sure. 80-90% of all games ever
shipped would run just fine in JavaScript at this point in time. Very few
games actually need every once of perf.

> And unsecured access to the graphics stack is a terrible idea.

WebGL does not provide unsecured access to the graphics stack so I'm not sure
what this BS remark was about.

~~~
hyperlogic
> "By any measure Lua is complete shit and yet Carmack made it popular by
> using as the glue for most of his games."

This just isn't the case. In recent games iD software has moved away from
using scripting languages at all. Later in the same talk, Carmack praises iOS
for reversing the trend against Java and bringing back native languages.
Saying that native languages are the only way you can get predictable
performance for things like smooth scrolling.

------
chao-
I don't have enough knowledge of native graphics libraries, nor of WebGL, to
speak to the core issue in this article. But, as a young'n, the last line
really strikes a chord with me.

I will never experience the joy people had fiddling around with their Apple
II's and I _still_ don't know the first thing about the Commodore 64 besides
the name. My attitude toward the "How will the kids ever learn unless they can
tinker with it?" nostalgia that comes up on HN has always been: "Meh. No one I
work with had an Apple II, and we all still ended up as tech-types."

That said, the first computer I owned myself ran Windows 98, and the first
thing I learned to do with it was noodle around in HTML and JavaScript. Well,
Okay. It was second thing I learned to do, after installing Sim City 2000 and
wasting a week's worth of time.

It was very poignant to realize all at once how the internet provided a chance
to be part of an easily-accessible ecosystem, one where you could tell a
computer _to do something_ and it _just did it_. Even if it was in a browser.

~~~
tluyben2
Buy an old computer from your local classifieds site/paper; it'll cost you $15
or something including working disks, mags and books. And start coding on it
(and hardware tinkering if you like that); it's like a Bonzai tree; it makes a
brilliant and relaxing hobby. If you do this a few hours / week, you'll get
that serene feeling (at least I do :) of something which is very fulfilling
without the stress of HAVING to do it (Javascript is also a job of many and
that gives the mixes/stressy feelings).

In a year or so you will _understand_ fully a) what we are on about b) how
very cheap and simple things can be very fulfilling c) why 'older folks'
sometimes sigh when yet a faster CPU is eaten 100% by Windows while not
significant seems to have changed d) how your computer works internally ; if
you are interested on the digital pulse and IC level (I can extend my MSX
computers using 74series logic ICs, which is, again very fulfilling) e) how
you can do stuff efficiently in very little memory on very slow computers.

That e) point is something which might not seem valuable, but it is and it
still is; if you know how to do things on these computers, you understand how
computers work and why some assembly code is much slower than other. Although
computers are vastly more complex these days, you can extrapolate quite a bit
on high level and it will be easier to read current tech documentation about
hardware (and software) as well.

Anyway; I would recommend everyone to at least try this as I strongly believe
it will help current generation understand better. It's also better for your
children (and children of others you might know) to let them tinker and learn
this young instead of playing XBOX 360 games (that's my opinion but I believe
it sticks). Maybe their friends won't be as impressed with them trying to
implement a ray caster on a 3.58 mhz machine, but when they get to 12 they can
program the Next Great App and win science fairs while the others, well, can
play Skyrim.

~~~
zumda
I see there is a lot of nostalgia in that post that I (and others like me)
will probably never understand. But, I still don't see the point.

It's nice that we could buy and old machine and program something on it. But
at the same time we could do it in Javascript, on the web with a very pretty
interface. So why should we trade all the knowledge, the tools and the
languages that we (well, people like you how tend to get all nostalgic over
this topic) have built and and write something on an archaic system?

I never had such an old system, yet at the same time, I understand the
constraints more or less, I now a bit of assembler, C and still question where
this knowledge is really benefiting me. (Though I do find it very
interesting!)

If I want to have a constraint environment, I could join a JavaScript 1k
challenge and also work with artificial constraints (at the same time I could
still enjoy the modern tools, environments and even graphics).

Maybe I just really don't see the point.

And to your last point, I think a better approach would be to show our
children either PyGame or even modding tools for modern games. I just don't
think a young child would really be _that_ interested in the archaic inner
workings of a slow machine, but could be really interested in making mods. I'm
not saying there are no such children around (I'm sure there are), I'm just
questioning the approach here.

~~~
tluyben2
I don't think you see the point :)

The point is that there is, in essence, no point. That's the same as the point
of working on a Bonzai tree. It has no point except that you can come to
inner/outer peace and beauty.

If you read carefully you see that actually I see 'few hours per week', so
there is no mentioning of 'trade all the knowledge'; you are not going to work
on ancient stuff fulltime.

For children you might be right; I just know what I was like and what the kids
I hung out with were like; I grew up in the 80ties and significant parts of
that I spent disassembling, soldering, recreating and such of OLD (50-60s)
radio's. Because they are EASY to understand and master.

My issue with PyGame for children (versus for instance an Arduino kid,
Rasberry PI or Xgamestation or, much cheaper and better documented, an ancient
computer) is that I have seen many kids growing up like that (replace PyGame
with VB or HTML) and they don't have A CLUE how a computer works. And when
they try to learn that, it is hard to make that step from this, basically,
blackbox system to how it actually works. You got that, but many don't.

But yes, I'm biased, I just know quite a few people who followed me and are
happy with it; I just summed up stuff I/we get from that. I'm probably just
crazy :) And I do know you can do this in JS too but people just _don't_
because their computeres are powerful enough to do it with a ton of fancy libs
and tools. In my experience it ends up people (and yes there are exceptions;
you are probably one of them) just being lazy.

~~~
Goronmon
_The point is that there is, in essence, no point. That's the same as the
point of working on a Bonzai tree._

Well, if there is truthfully no point, you could replace working on an ancient
computer with actually working on a Bonzai tree, or a rock garden, etc.

But I would assume you meant more "There is no point, aside from gaining an
appreciate for how machines worked in an older, more basic form" heh.

~~~
tluyben2
I think you can replace it with that (I used to do other stuff for relaxation
and focus change, I just now like this more), but i think you'll get more out
of an old computer than a rock garden :)

------
debacle
> We're there again: take 3 lines of JavaScript and you're drawing an image to
> a canvas element. Take 20 more lines and you have a rendering loop and a
> sprite that moves with the arrow keys.

Processing (Java), PyGame (Python), and I'm sure many other libraries can do
the same thing. They're also faster, cleaner, more robust, and you're not
writing some insane garbled blend of JavaScript and GLSL with all the
associated scaffolding code between the two vastly differently typed
languages.

I would highly recommend Processing for any graphics playing that you might
do. Yes, you have to write a bit more code (it is Java, after all), but it's
also much more rewarding and just as portable as something written for WebGL.

~~~
swang
Those libraries/languages don't have the user install base of javascript,
which is nearly every single piece of computing that has been released in the
last 10 years, albeit most of those older models probably won't be able to run
the javascript that's running now.

And there is no "click download" required like those two libraries would need
and also no need for patch updates. Your "download" is just pointing to a URL.

~~~
debacle
Yes, thank you. I know how browsers work.

~~~
batista
So you just momentarily forgot it when writing your previous comment?

------
aw3c2
With Web/Local Storage you are limited to 5-10 Megabytes of data.

There will be a shitstorm once graphic drivers get exploited through WebGL.

The game the writer self-promotes is a completely different genre than what id
Software does (2D shmup versus a 3D FPS with detailed graphics). It eats a
whole CPU core for a seemingly trivial game (might just be missing sleeping in
the code, I have no clue).

If you use a good codebase, you do not need to write 200 lines just to setup
your screen, eg
[http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenG...](http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Introduction#Initialization)
.

And never forget that web-based games are kinda non-free unless you can
download them and play them locally. You are always at the whim of the
developer/hoster/provider. I much prefer games that run natively, disconnected
from the internet (attack vector) and whenever I want.

~~~
streptomycin
> With Web/Local Storage you are limited to 5-10 Megabytes of data.

IndexedDB has unlimited storage.

~~~
zumda
There is also a (proposed) file API. <http://www.w3.org/TR/FileAPI/>

------
tsahyt
>We're there again: take 3 lines of JavaScript and you're drawing an
image[...]

I think Carmack wasn't referring to how more abstractions could make his life
easier. I've never had the time to dig deeply into id Software's sources
(which get open sourced after a couple of years, in case someone didn't know),
but what I've often heard him complain about were the abstractions themselves!
This is basically about how we wrap a couple of layers around the drivers
these days - drivers which have become increasingly complex.

See, abstractions are a good thing. General purpose abstractions might be a
good thing for a lot of applications. For some, like graphics engines, they're
not. Suppose you're working on a cutting edge 3D engine and you want to
squeeze the last bit of performance from the machine. What you end up doing is
talking to the graphics card as directly as possible, with the least amount of
"layers of crap", as Carmack called them, inbetween you and the hardware.

General-purpose abstractions are loaded with stuff you don't necessarily need
and come with quite a bit of overhead. Suppose you have 10 layers between you
and the hardware, then everything you try to tell the hardware has to go
through all those layers and possibly back to you. That's quite a drawback.

Since drivers have become rather complex themselves as GFX hardware has become
more powerful in the last 2 decades you need quite a lot of code to talk to it
properly.

The same thing goes for setting up the screen for rendering. Windows wants you
to be quite verbose about what you're going to do (obviously). That's why you
need 200 lines of code to do so.

The only way round that is using libraries that abstract those things away
from you, but they do so at additional cost. Obviously it's possible to do the
same thing in just one line of <insert your favourite language here> in the
same way that it's possible to do the same thing in just a couple of lines of
low level code _as long as you have a library doing it for you_.

However, as pointed out, in an AAA game engine, that's not what you want to
do. There's a reason why the "highest common denominator" is usually D3D here.
It's because D3D is still reasonably quick (although not as quick as OpenGL)
and does enough things for you.

~~~
duaneb
> It's because D3D is still reasonably quick (although not as quick as OpenGL)

While I believe that OpenGL is better for everyone if only because it's an
open standard, I think that one article noting a difference between the two
APIs should not lead to the conclusion that "OpenGL is faster than D3D, full
stop".

~~~
tsahyt
Your reasoning is definately correct. I haven't made enough measurements
myself to justify the statement, but the couple of times I did, OpenGL was
usually a tad quicker. However that's more anecdotal evidence than anything
else.

------
NinjaWarrior
I totally agree with Carmack. Why the hell crap technologies dominate all the
time? HTML5 and JavaScript is the most disgusting thing I've experienced in my
20 years game programming history.

"Nobody pretends that the next AAA-title will be written in JavaScript. The
community understands that it's magnitudes slower than native code"

Obviously no. Most web standard adbocates insist that all software will and
should be web based. They must be criticized.

~~~
etanol
Just like with C++. That language is a horrible mostruosity, yet projects keep
migrating to it, e.g., Id's game engines, GCC, etc.

~~~
w0utert
Things can be horrible in many different ways. C++ is definitely horrible in
some ways, but when used properly, it allows you to do stuff you cannot do
with most 'less horrible' languages (if any). Going C++ is a very valid
tradeoff for many purposes, the only reason people are looking down on it now
is because the spec is a little messy, and because it is probably one of the
most difficult programming languages to _really_ master.

JavaScript on the other hand really is horrible in every way imaginable except
ubiquity. Personally, I think it's a really bad thing people are trying so
hard to point out 'the good parts' of JavaScript, because it devalues all
those other great languages that share the same 'good parts' without the rest
of the lunacy that is JavaScript. I'm thinking about languages such as Lua,
Go, Erlang, Clojure, etc.

There really is only a single excuse for using JavaScript, which is when you
are writing web applications, and only because it's (sadly) the only option
you have if that's your game. JavaScript is like the QWERTY keyboard layout,
back in the day it was designed it was ok for the purpose, and now we're stuck
with it because everyone standardized on it.

------
rjzzleep
op also completely misses the point. we're even further from the 4 lines than
we were ever before.

sure john could just use someones library. but in the terms john was speaking,
javascript + library + browser stack etc. etc. is not 4 lines it's hundreds of
thousands.

there was only one prof at university i enjoyed. he would stand in the cpu
design class and mock the java world and how things get slower despite us
having faster cpus.

ps. i earn my money with web work

pps. javascript is a horrible language. holding my breath for dart and
anything else thats not javascript

~~~
phoboslab
Yes, we're moving further and further away from the metal, but that's not the
point Carmack was making when he said that getting started and pushing pixels
to the screen was _easier_ on the Apple II than it is on Windows/Linux. He
didn't mean the actual machine code that is executed, but the code you have to
write/understand.

~~~
angersock
And he's still correct. It's still simpler/faster when you are allowed to to
just poke bytes in memory-mapped video ram ( see
[http://digitalerr0r.wordpress.com/2011/04/30/commodore-64-pr...](http://digitalerr0r.wordpress.com/2011/04/30/commodore-64-programming-7-creating-
and-rendering-bitmaps/) for an example on the C64 ).

The HTML scaffolding and JS for even a 2D canvas blit is still longer to type,
and is slow.

~~~
de90
That is in no way simpler, only faster. I have no experience with writing for
C64, but to me at a quick glance it makes little sense just skimming over
that.

Now take a language like RoR which I have never used. I can easily look at it
and atleast kind of see what is going on.

The abstractions we have now atleast allow for code that can read like a book,
and that is a lot less intimidating for someone trying to get started with
programming.

~~~
rjzzleep
"I have no experience with writing for C64" ^^^^^^^^ ???

it is simpler. it's not as intuitive, because youre putting it in relation to
your current experiences. your current experiences make it easy for you to
understand ror. but now imagine you wanna change something in the actual ror
stack. how simple does that become? not that simple anymore is it?

if you come from a different background and you look at functional programming
languages you might say wow that's difficult. but similarly a guy that's only
written functional code and looks at ror might say wow you're an idiot.

i hope you get the drift. it's just subjectivity youre talking about.

~~~
de90
The quoted line was from going back, editing, and even screwing that up. haha

I can see what you're saying. I still feel like intuitive code == simpler, but
we'll have to agree to disagree.

This has made me more interested in diving in and learning some lower level
stuff since you believe it is more simple. At the very least it'd be a great
learning experience.

~~~
angersock
A wonderful resource in Abrash's Graphics Programming Black Book (
[http://www.gamedev.net/page/resources/_/technical/graphics-p...](http://www.gamedev.net/page/resources/_/technical/graphics-
programming-and-theory/graphics-programming-black-book-r1698) ); this gives
you an appreciation for a lot of graphics and low-level issues (how to wrestle
with VGA, etc.).

The problem with "intuitive code == simpler" is that it doesn't account for
the scaffolding your intuitions are based upon. Like it or hate it, C is
pretty straightforward in what it claims to do, and assembly moreso.

Remember that a machine is ultimately the world's stupidest idiot savant
following your directions according to the rules of its hardware--any
abstractions built atop it to make things "more intuitive" will only serve to
shield you from the underlying simplicity of the system.

I'm not going to claim that high-level programming is anything other than a
productivity boost, but I will state that for learning the system and writing
system-friendly code you really need to be able to operate at a low level.
Oftentimes, that low-level is very reasonable and as "intuitive" in its
spartan domain as Ruby or something similar.

Unless you're the x86 isntruction set. Fuck that guy.

~~~
de90
Thank you for the link, I know what my next read will be!

------
pwny
It would be great if people stopped seeing native and web games as mutually
exclusive. I'm a huge fan of native games and all the oomph they can dish out.
Of course we're not going to see AAA titles in the browser any time soon and
of course native games will ALWAYS have an advantage, at least performance
wise, over browser games since they don't have the browser and javascript
overheads.

That being said, there are both native and browser games that are great, just
like there are some that are mediocre. The browser is imho a great place to
prototype a game, make a first game as a newbie or even publish something
that's not too resource hungry.

I'd even go as far as saying that WebGL will stimulate the development of
native games as well. WebGL based game development is a lot closer to native
game development in a way than Flash games are (at least from my limited
experience) so new developers might make the switch more easily when their
needs exceed what the browser can give them. Exactly the position John
Carmack's company is in, although they never had the modern browser at their
disposal in the past.

These are exciting times and I suffer a little bit inside whenever I see
talented people arguing over them instead of making the best of them.

~~~
bazookaBen
the arguments here will cause innovation.

------
preshing
Why does it matter whether Carmack likes JavaScript? If he doesn't like it, it
won't vanish in a puff of smoke.

~~~
geoka9
I guess it matters because Carmack's opinion carries weight in the industry.

~~~
petercooper
Carmack is one of my heroes but I don't think that's particularly true. He's
famous for not liking deep stories and throwing people straight into the
game.. yet most AAA titles nowadays have ridiculously elaborate stories and it
can take an age to get into gameplay. His opinion is always worth listening
to, but I'm not convinced most people follow it.

------
duaneb
As far as I can see the only true parallel between the
Javascript/HTML/Whatever environment and Apple II basic is that it comes pre-
installed on every computer. This does NOT mean that it is a good way to teach
anyone. It's not. It's pretty horrible, compared to pretty much everything
else.

IMHO it's a much bigger revolution in terms of being able to teach your kid
from across the globe over skype (or whatever).

------
mr_luc
A quick aside for the people who say that Javascript stuff pegs their CPU:
it's not always going to be that way.

We've got OpenGL now, and people are already writing shaders that do the work
of physics and matrix rotations, etc, but OpenCL (with a C) is already popping
up (you can get it running on node with a couple of different libraries, and
there's a Ruby lib for it as well), which will let us write substantially more
"general" code that runs on the gpu.

We were spoiled with traditional gaming; having unfettered access to the CPU,
and all of the space we wanted when installing from physical media, is pretty
crazy when you think about it.

I think the bigger question isn't "can Javascript be fast enough", because
once the GPU is handling the physics and graphics, Javascript will be _almost_
in the position of a traditional 3d engine's scripting language. It'll still
have to do more than, say, UnrealScript. The networking code will be in JS,
probably the model of the scene graph, etc. On the other hand, it's probably
faster than UnrealScript; I know it's faster than TorqueScript.

Space requirements are the real killer, though. Current techniques rely on
ever higher-resolution textures, 1024 pixels square or more, including
additionally a displacement map (so that the textures appear three-
dimensional) generally of equal resolution. These are for character textures
-- the environments that they inhabit include literally gigabytes of resources
that are streaming in and out of the GPU.

So almost any Modern Warfare game is never going to happen on the browser.
We're talking gigabytes of content, as opposed to the megabytes we typically
load even on content-heavy sites.

Nonetheless, a mixture of traditional and procedural techniques could get us a
lot of the way there. Maybe use up a couple of MB on character textures, which
contain difficult-to-generate details, and a few more on level geometry, but
generate procedural textures and displacement maps for the environment.

I know it seems like the traditional wisdom is "never gonna happen", but
that's only true so long as traditional games are "never gonna" get off the
CPU and move most of their code onto the GPU (physics as well as drawing).
Once the heavyweight tasks can be offloaded, a new and bewildering world opens
up.

~~~
donkeylips
In 1998 you couldn't even stream a music video over the internet. In 2012 you
can stream the entire game of Quake 2 through your browser in under 5 minutes.
If you told me this while I was installing Quake 2 through my CD-ROM and
waiting 30 minutes for it to finish, my head would have exploded.

<http://playwebgl.com/games/quake-2-webgl/>

~~~
mr_luc
We're definitely getting there. Still, with storage what it is right now, that
5 minutes becomes your startup time.

But a game built with this environment in mind would likely fare much better.
I truly feel that we're just a couple of mobile browser upgrades from
widespread accelerated browser 3d.

------
tszming
If you have watched Carmack's previous keynote, he strongly believe in static
typing and static analysis, not only features and performance.

------
quux
Anyone have a link to a video of Carmack's keynote?

------
dsirijus
Huh? I'm really not the one to pull in the generic argument but - there's a
place for both and much more.

It's great not needing write hundreds of lines of boilerplate code to get a 2D
physics game prototype running, and conversely, it is nice to get awesome
graphical support using directx sdk, much of it handled in there by sane API.

Whatever floats your boat.

------
kabir_h
Language arguments aside, it's hard not to look at the three.js 3D examples
and not be impressed by how far browser 3D rendering has come:
<http://mrdoob.github.com/three.js/>

------
ja30278
As an aside, I find that I usually disagree with anyone who feels compelled to
frame their argument as an 'open letter'.

In this case, I agree that javascript is ubiquitous, and has the advantage of
being delivered to the end-user in (more or less) source code form. However,
the language itself is a mess, and it's a bit of a shame that we seem to have
gotten stuck with it for so long as the only dynamic web runtime.

I think the most annoying thing about javascript is that people who learn it
for web-programming seem to insist on using it everywhere, without regard for
whether it's the best tool for the job.

------
Avshalom
An aside to anyone who does want to just push pixels with native code in 3
lines: <http://code.google.com/p/pixeltoaster/>

Pixeltoaster is a dead easy to use framebuffer wrapped on top of GL/SDL. It
also comes with a timer and keyboard/mouse input, it's pretty much as much fun
as you can have in C++.

------
dinkumthinkum
JavaScript is our generation's Apple II? Look I think Javascript is great but
this is just ridiculous. But then I think it's also crazy to throw away all
this great work on hardware and software and only innovate for the Web where
we are re-solving problems that were solved long ago just so they are "Web
based."

------
etanol
> _Right-Click - > View Source is what made the web so successful and it's
> awesome that we now have this for 3D graphics as well._

That can't be serious. I bet he didn't try it on GMail.

~~~
WesleyJohnson
It's how I, and many other programmers I've worked with in my age range, got
started.

------
huhtenberg
Stage 3 of linked X-fire game on my super-duper 64bit laptop running latest FF
is just plain laggy. Just saying.

------
vishaldpatel
Dear John..

------
papsosouid
Javascript doesn't have a monopoly on "you can move a sprite in only a few
lines of code". I can do that in C too, libraries aren't new. None of the
horribleness of javascript is justified simply because you don't feel like
using a higher level library in a sane language.

------
goggles99
Hmmm... well games these days come on a DVD with 2 gigs of graphics. How could
a JavaScript game streaming over the web do something like that??? PC games
with high end graphics and gamers have pretty much driven PC sales/upgrades
for the last decade. I really doubt that gaming enthusiasts are going to be
happy with their FPS going into the toilet and loading times taking 5 minutes
to download all the textures.

Are we going backwards in terms of technology?

Lets make a distinction here. Javascript is fine for phone games and puzzle
games. That is about it. Same reasons why embedded chips are STILL programmed
using 35 year old assembly/C and always will be. It is the right tool for the
job that wins.

Hype can be a very bad thing for technology. I realize that web developers are
creating quite a clamor with their aspirations of becoming game developers
(better money, more fun, and higher status among peers) but the real game devs
are going to blow you and your toys away (you are using the wrong tool for the
job). Basic programmers did this in the 80s and we all know what happened to
that LOL.

------
goggles99
The Web browser will eventually be an OS. It will provide a common language
runtime for graphics and code execution.

------
Yuioup
No, Python is what John should be teaching his son, not fucking JavaScript.

~~~
EvilTerran
<http://ycombinator.com/newsguidelines.html>

_"In Comments

Be civil."_

~~~
duaneb
Since when does swearing preclude civility?

EDIT: Rather, I thought society like HN had mostly moved _past_ such silly
problems with words who hurt nobody.

~~~
EvilTerran
Coarse language is (at least perceived to be) correlated with a lack of
interest in reasonable discussion; If someone says "he should be teaching his
son Python, not Javascript", you might be able to have a decent conversation
with them about the relative merits of the languages. If someone says "... not
_fucking_ Javascript", that's not gonna happen.

Additionally, coarse language gets people's backs up -- people use more of it
when they're... "being emotional", as it were, and it tends to bring out
emotional (cf reasoned) responses in kind.

In other words, profanity is mutually causal with poor-quality discussion, by
virtue of it being mutually causal with emotion overriding reason. I'd
consider anything satisfying that property to be uncivil by definition, but
that's semantics -- regardless, I conclude that coarse language is generally
out of place on HN.

(Incidentally, I see dismissing attitudes you disagree with as "silly" and "to
be moved past" in a similar light -- like profanity, it stands in lieu of
reasoned argument, and the only effect it may have is to annoy those who hold
the original sentiment.)

~~~
duaneb
I don't see what swearing has to do with reasonable discourse - logic stands
regardless of how it is communicated. Furthermore, there is always room for
expression that is related to the topic. Are we limited to reasonable
discourse? Are we not allowed to express how we feel about the topic at hand?
I don't think that lack of reasonable discussion implies lack of civility.
People can be passionate (even expressing this through profanity) without
detracting from the discussion at all.

Nonetheless, I see your point when extrapolated to wider use. I also admit
that I am biased in also hating Javascript; in a different context, I'm sure
I'd be equally as upset.

~~~
EvilTerran
Actually, you make a good point, there's no reason profanity _must_ "stand in
lieu of reasoned argument". In fact, a persuasive case can be made all the
_more_ impactful and compelling with a bit of coarse language, tactically
applied to convey emotional context -- consider some of the content on, say,
Cracked, or the Oatmeal.

So, on further reflection, I guess what irked me more was that the original
post contributed nothing to the conversation, rather than the profanity
therein; it's just easier to notice things present than things absent.

I suppose there's a "quality hierarchy" of sorts in my mind (loosely
corresponding to upmod/abstain/downmod):

    
    
      - well-argued comments, in which case manners are incidental
      - poorly-argued comments, but at least they're polite
      - neither well-argued nor polite

