Hacker News Reader

Comment by slowpoke | Hacker News Reader

  To write fast code it requires a programmer and if you have 
  a programmer why not just do it in C++ where it will be 
  several times faster?

Why should I as a programmer not profit from extremely fast design/implement/test/fix/repeat iterations? I'm not saying scripting/high level languages like Lua, Python or Ruby should always be preferred. But it's equally wrong to assert that C-oid languages are always the superior choice. It's much more a question of knowing when to use what and why, which in my opinion makes an important part of being a good programmer.

View on HN

I've never seen the effort involved in making a nice quick-feedback REPL-style affair pay off. Perhaps for certain types of game it would be worth it, and perhaps amortized over a long enough period the result would become value for money. My experience has been that making a script system work that way, and work reliably, and provide a nice interface, just takes up more time than you end up saving.

Anyway, all the programmers I've known would want good debugging facilities as well, like the ones you get in Visual Studio/ProDG/Code Warrior/Xcode/gdb/etc. - oops, only kidding about gdb! This thing really needs a GUI. This all just expands the time-suck further.

That's not to say it can't be made to work, of course! People can do anything, if they set their mind to it hard enough, and if they wait for long enough, maybe it will even become value for money.

Let me tell you about one project I have been working on. It was a large embedded device, with lots of highly optimized code in C and ASM on Sharks and Blackfins. The problem was, every time you changed the code, you also had to push it on the device via FTP, then power down the device to reset it's memory, then reboot it with the new binary and reconnect your FTP and debugging host. Some of that could be automated, some not.

However, we also had a scripting interface. Update a script, tell the software to restart, done. Easy.

Nice.. I too was working with embedded C++ dev w/ a Blackfin & Sharc combo and yes the standard build cycle was kind of lame. I attended a Blackfin course that just happened to be located at Analog Devices HQ. In the 4 days that I was there I got an OSC (Open Sound Control) library w/ message parsing and Lua support up and running hooked up to desktop GUI audio control apps built with a framework I've created in Java. I continued to try and get things going with the OSC message parsing to Sharc communication for DSP control (Ambisonics mostly), but then Android steam rolled me..

I already had a real time app dev runtime / framework in Java for J2SE that immediately started porting to also run on Android. A modern SoC and Android w/ my framework on the desktop and on the device for 3rd party app dev is now driving my future audio hardware dev efforts. First though I get to do a general release of the software dev framework as a product which never really would have happened without Android showing up. Things changed a lot recently!

Anyway, good idea with the scripting / Blackfin deal though as that can pay off big.

Where it really does work is in explicitly actor-modeled games, like MMOs with thousands of NPCs. You don't want to have to compile a new shopkeeper and dlopen() him on the client; you just want to stream his source and eval() it, then toss it away.

My bet would be that most experienced programmers actually would prefer to compile a new NPC, and then load it in as a shared library. This arrangement stands at least some chance of working neatly with whatever debugger you are using, and should provide pretty decent iteration times.

I would certainly win this bet if it involved all the experienced programmers of my acquaintance.

Perhaps I wasn't specific enough with "MMOs." I'm talking about the kinds of games where players can create their own maps, with their own scripted NPCs, and push them onto the server, where other players will then pull them down and execute them in real-time. Second Life, MOOs, etc.

This is basically an equivalent model to web-browsing. You don't load compiled Javascript into your web browser's process address space and jump into it; you put an interpreter between you and it, both for the sake of the code (JS has its own debugger, which treats the browser as a black box that scripters rarely have to think about, and never see backtraces from) and for the sake of the web browser (which doesn't have to deal with any consequences of bad scripting affecting the validity of the browser's own data structures.)

Reply on news.ycombinator.com