10 ms·

Letter to John Carmack

149 points by austinhallock 14y ago

chao- 14y ago
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.
- RyanMcGreal 14y ago
  You could always install DOSBOX and GW-BASIC. Then you can play around with the PLAY statement (feed it a string of notes), the SOUND statement (feed it frequencies) and the DRAW/LINE/PRESET/COLOR/PALETTE statements (draw coloured shapes on the screen).
  - jmj42 14y ago
    I remember, at age 8 or 9, being so proud of myself for having developed an app that played a couple of complete songs using SOUND in tandy basic on our first PC (an 8088 w/ a whopping huge 10MB hard drive). My father (an amateur singer), used the "Wind beneath My Wings" version for to warm up before practice.
    - Scriptor 14y ago
      When I was 10 I started reading a VB book and was inordinately proud of myself for learning how to customize the toolbars in the IDE. I just assumed that that was a major part of programming. I also misunderstood the part on autocompletion and thought it meant most of your code was autogenerated. I wasn't the most tech-literate child, but at least I've come a decent way since then.
      - chris_wot 14y ago
        Damn I feel old. I was using GW-BASIC when I was 8 :-(
    - bitwize 14y ago
      Me: PLAY "l16ecececececececececececececececececececececececec" My dad: * runs out to answer the "telephone" * Me: * trollface
  - reidrac 14y ago
    I learnt to program with GW-BASIC when I was 13 and, as you say, it had all these high level built in functions that made easy getting results. Most of the stuff I programmed when I was 13 was crap, but it was amazingly funny! Today I would recommend Python to start tinkering, but to be honest I think it was easier back then. My PC had 512KB of RAM (it doesn't matter, GW-BASIC allowed only 64KB for both your code and your data), CGA graphic card (4 colors), 8MHz CPU and no HDD disk; and even with all these limitations, I think it was easier than Python + PyGame.
- tluyben2 14y ago
  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 14y ago
    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.
aw3c2 14y ago
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_OpenGL_Introduction#Initialization http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenG... . 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.
- dangoor 14y ago
  The web platform is rapidly improving for games, on all fronts. The HTML5 offline (appcache) spec allows you to have resources available when offline (and you don't need to write your own code to stuff things into localstorage...) Besides, localstorage is not considered, by browser hackers, to be the best idea performance-wise. They recommend IndexedDB. Those specifics aside, my main point is to say that game makers are targeting the browser and browser vendors are very much aware of the pain points they have and are working to correct them. Browsers today evolve much faster than they did a few years ago. (obdisclaimer: I work for Mozilla)
- ajuc 14y ago
  You only need localStorage for saving game or preferences. Static assets (like models, textures, most of the level) should be, well, static, and can be as huge, as you like them. Also you can write html5 game as one-page website without server part, and downloading it to play it offline is as simple as file->save complete web page as.. in your browser. You can provide installer for your players that just unpacks the game to directory and places shortcut in start menu (no dll-s, no register settings), you can pack your game into chrome app format for some users and place your game in chrome app store. One thing I think chrome gets wrong is its security policy that by default prevents local web apps (when you open html file on your disk in browser directly) from doing ajax requests on the same directory. That means you need to wrap static assets in html, and that's stupid, I should be able to load xml from the directory my index.html is stored in. But whatever, there's workaround. I think most games don't really need super detailed 3d graphic, and simplicity of distribution (nothing to install, just click link and play) is the killer feature of html5 for simple casual games.
rjzzleep 14y ago
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 14y ago
  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 14y ago
    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-programming-7-creating-and-rendering-bitmaps/ http://digitalerr0r.wordpress.com/2011/04/30/commodore-64-pr... 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 14y ago
      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.
      - 14y ago
preshing 14y ago
Why does it matter whether Carmack likes JavaScript? If he doesn't like it, it won't vanish in a puff of smoke.
- geoka9 14y ago
  I guess it matters because Carmack's opinion carries weight in the industry.
  - petercooper 14y ago
    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.
- rjzzleep 14y ago
  it won't vanish in a puff of smoke. but i have a feeling it will turn into the new internet explorer 6 of the web at some point
pwny 14y ago
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 14y ago
  the arguments here will cause innovation.
tumult 14y ago
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.
- chris_wot 14y ago
  Yeah, no one is "telling" John Carmack et al. to do anything. Unless you consider making an argument to be ordering folks around, in which case may I suggest you listen to this guy John who recently talked about JavaScript...
  - tumult 14y ago
    Don't hate JavaScript. It's our generation's Apple II.
    - chris_wot 14y ago
      And? He's not ordering anyone around, he's urging him to consider others may find it useful. There's a world of difference between that and a direct order. Sorry you can't see that!
    - pirateking 14y ago
      It is not. It is closer to our generations HyperCard (but not nearly as cool). The iPad COULD have been our generation's Apple II if it came bundled with an un-sandboxed Xcode iOS app and Terminal... dreams of an alternate universe.
debacle 14y ago
> 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.
- DanI-S 14y ago
  Not to knock Processing, but I don't see how it can be described as 'just as portable' when a WebGL-capable interpreter is already installed on millions of machines worldwide, with zero knowledge required to use it?
- swang 14y ago
  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 14y ago
    Yes, thank you. I know how browsers work.
    - batista 14y ago
      So you just momentarily forgot it when writing your previous comment?
- TazeTSchnitzel 14y ago
mr_luc 14y ago
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.
- Johngibb 14y ago
  Well, let's not say "never" going to happen... I'd like to think that _someday_ gigabit internet will be the norm. :)
- donkeylips 14y ago
quux 14y ago
Anyone have a link to a video of Carmack's keynote?
dsirijus 14y ago
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.
tszming 14y ago
If you have watched Carmack's previous keynote, he strongly believe in static typing and static analysis, not only features and performance.
tsahyt 14y ago
>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 14y ago
  > 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".
Yuioup 14y ago
No, Python is what John should be teaching his son, not fucking JavaScript.
- EvilTerran 14y ago
  http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html "In Comments Be civil."
  - duaneb 14y ago
    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 14y ago
      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.)
      - slurgfest 14y ago
        I agree with the guy's actual statement but I agree with you that the coarse phrasing was unnecessary and unhelpful here
papsosouid 14y ago
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.
kabir_h 14y ago
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/ http://mrdoob.github.com/three.js/
bonch 14y ago
The condescending explanation of JavaScript to Carmack is odd, as if Carmack doesn't know about it or have experience with other scripting languages (including ones he's written), or that he doesn't understand the advantage of writing fewer lines of code. Carmack has spoken in favor of static typing and other compile-time checks after negative experiences using a scripting language in Doom 3, including poor performance and debugging. The demand that JavaScript be taught to Carmack's son just caps the douche-iness.
NinjaWarrior 14y ago
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 14y ago
  Just like with C++. That language is a horrible mostruosity, yet projects keep migrating to it, e.g., Id's game engines, GCC, etc.
  - pwny 14y ago
    Projects keep migrating/being built in it because it offers things other languages don't (for example being relatively close to the metal while still being Object Oriented) and it's available. On the other side you have web people who hate javascript or would like a solution more suited to their needs and can barely do anything about it since it's the only browser language. I find C++ just as messy as anyone else but its context is so different from javascript's that it doesn't even make sense to compare them.
  - w0utert 14y ago
    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.
etanol 14y ago
> 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 14y ago
  It's how I, and many other programmers I've worked with in my age range, got started.
huhtenberg 14y ago
Stage 3 of linked X-fire game on my super-duper 64bit laptop running latest FF is just plain laggy. Just saying.
duaneb 14y ago
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).
Avshalom 14y ago
An aside to anyone who does want to just push pixels with native code in 3 lines: http://code.google.com/p/pixeltoaster/ 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++.
goggles99 14y ago
The Web browser will eventually be an OS. It will provide a common language runtime for graphics and code execution.
goggles99 14y ago
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.
vishaldpatel 14y ago
Dear John..
ja30278 14y ago
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.
dinkumthinkum 14y ago
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."

149 points by austinhallock 14y ago

chao- 14y ago

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.

RyanMcGreal 14y ago
You could always install DOSBOX and GW-BASIC. Then you can play around with the PLAY statement (feed it a string of notes), the SOUND statement (feed it frequencies) and the DRAW/LINE/PRESET/COLOR/PALETTE statements (draw coloured shapes on the screen).
- jmj42 14y ago
  I remember, at age 8 or 9, being so proud of myself for having developed an app that played a couple of complete songs using SOUND in tandy basic on our first PC (an 8088 w/ a whopping huge 10MB hard drive). My father (an amateur singer), used the "Wind beneath My Wings" version for to warm up before practice.
  - Scriptor 14y ago
    When I was 10 I started reading a VB book and was inordinately proud of myself for learning how to customize the toolbars in the IDE. I just assumed that that was a major part of programming. I also misunderstood the part on autocompletion and thought it meant most of your code was autogenerated. I wasn't the most tech-literate child, but at least I've come a decent way since then.
    - chris_wot 14y ago
      Damn I feel old. I was using GW-BASIC when I was 8 :-(
  - bitwize 14y ago
    Me: PLAY "l16ecececececececececececececececececececececececec" My dad: * runs out to answer the "telephone" * Me: * trollface
- reidrac 14y ago
  I learnt to program with GW-BASIC when I was 13 and, as you say, it had all these high level built in functions that made easy getting results. Most of the stuff I programmed when I was 13 was crap, but it was amazingly funny! Today I would recommend Python to start tinkering, but to be honest I think it was easier back then. My PC had 512KB of RAM (it doesn't matter, GW-BASIC allowed only 64KB for both your code and your data), CGA graphic card (4 colors), 8MHz CPU and no HDD disk; and even with all these limitations, I think it was easier than Python + PyGame.
tluyben2 14y ago
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 14y ago
  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.

aw3c2 14y ago

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_OpenGL_Introduction#Initialization http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenG... . 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.

dangoor 14y ago
The web platform is rapidly improving for games, on all fronts. The HTML5 offline (appcache) spec allows you to have resources available when offline (and you don't need to write your own code to stuff things into localstorage...) Besides, localstorage is not considered, by browser hackers, to be the best idea performance-wise. They recommend IndexedDB. Those specifics aside, my main point is to say that game makers are targeting the browser and browser vendors are very much aware of the pain points they have and are working to correct them. Browsers today evolve much faster than they did a few years ago. (obdisclaimer: I work for Mozilla)
ajuc 14y ago
You only need localStorage for saving game or preferences. Static assets (like models, textures, most of the level) should be, well, static, and can be as huge, as you like them. Also you can write html5 game as one-page website without server part, and downloading it to play it offline is as simple as file->save complete web page as.. in your browser. You can provide installer for your players that just unpacks the game to directory and places shortcut in start menu (no dll-s, no register settings), you can pack your game into chrome app format for some users and place your game in chrome app store. One thing I think chrome gets wrong is its security policy that by default prevents local web apps (when you open html file on your disk in browser directly) from doing ajax requests on the same directory. That means you need to wrap static assets in html, and that's stupid, I should be able to load xml from the directory my index.html is stored in. But whatever, there's workaround. I think most games don't really need super detailed 3d graphic, and simplicity of distribution (nothing to install, just click link and play) is the killer feature of html5 for simple casual games.

rjzzleep 14y ago

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 14y ago
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 14y ago
  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-programming-7-creating-and-rendering-bitmaps/ http://digitalerr0r.wordpress.com/2011/04/30/commodore-64-pr... 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 14y ago
    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.
    - 14y ago

preshing 14y ago

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

geoka9 14y ago
I guess it matters because Carmack's opinion carries weight in the industry.
- petercooper 14y ago
  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.
rjzzleep 14y ago
it won't vanish in a puff of smoke. but i have a feeling it will turn into the new internet explorer 6 of the web at some point

pwny 14y ago

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 14y ago
the arguments here will cause innovation.

tumult 14y ago

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.

chris_wot 14y ago
Yeah, no one is "telling" John Carmack et al. to do anything. Unless you consider making an argument to be ordering folks around, in which case may I suggest you listen to this guy John who recently talked about JavaScript...
- tumult 14y ago
  Don't hate JavaScript. It's our generation's Apple II.
  - chris_wot 14y ago
    And? He's not ordering anyone around, he's urging him to consider others may find it useful. There's a world of difference between that and a direct order. Sorry you can't see that!
  - pirateking 14y ago
    It is not. It is closer to our generations HyperCard (but not nearly as cool). The iPad COULD have been our generation's Apple II if it came bundled with an un-sandboxed Xcode iOS app and Terminal... dreams of an alternate universe.

debacle 14y ago

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

DanI-S 14y ago
Not to knock Processing, but I don't see how it can be described as 'just as portable' when a WebGL-capable interpreter is already installed on millions of machines worldwide, with zero knowledge required to use it?
swang 14y ago
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 14y ago
  Yes, thank you. I know how browsers work.
  - batista 14y ago
    So you just momentarily forgot it when writing your previous comment?
TazeTSchnitzel 14y ago

mr_luc 14y ago

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.

Johngibb 14y ago
Well, let's not say "never" going to happen... I'd like to think that _someday_ gigabit internet will be the norm. :)
donkeylips 14y ago

quux 14y ago

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

dsirijus 14y ago

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.

tszming 14y ago

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

tsahyt 14y ago

>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 14y ago
> 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".

Yuioup 14y ago

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

EvilTerran 14y ago
http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html "In Comments Be civil."
- duaneb 14y ago
  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 14y ago
    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.)
    - slurgfest 14y ago
      I agree with the guy's actual statement but I agree with you that the coarse phrasing was unnecessary and unhelpful here

papsosouid 14y ago

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.

kabir_h 14y ago

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/ http://mrdoob.github.com/three.js/

bonch 14y ago

The condescending explanation of JavaScript to Carmack is odd, as if Carmack doesn't know about it or have experience with other scripting languages (including ones he's written), or that he doesn't understand the advantage of writing fewer lines of code. Carmack has spoken in favor of static typing and other compile-time checks after negative experiences using a scripting language in Doom 3, including poor performance and debugging. The demand that JavaScript be taught to Carmack's son just caps the douche-iness.

NinjaWarrior 14y ago

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 14y ago
Just like with C++. That language is a horrible mostruosity, yet projects keep migrating to it, e.g., Id's game engines, GCC, etc.
- pwny 14y ago
  Projects keep migrating/being built in it because it offers things other languages don't (for example being relatively close to the metal while still being Object Oriented) and it's available. On the other side you have web people who hate javascript or would like a solution more suited to their needs and can barely do anything about it since it's the only browser language. I find C++ just as messy as anyone else but its context is so different from javascript's that it doesn't even make sense to compare them.
- w0utert 14y ago
  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.

etanol 14y ago

> 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 14y ago
It's how I, and many other programmers I've worked with in my age range, got started.

huhtenberg 14y ago

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

duaneb 14y ago

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

Avshalom 14y ago

An aside to anyone who does want to just push pixels with native code in 3 lines: http://code.google.com/p/pixeltoaster/ 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++.

goggles99 14y ago

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

goggles99 14y ago

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.

vishaldpatel 14y ago

Dear John..

ja30278 14y ago

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.

dinkumthinkum 14y ago

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