In part 1 of my conversation with Goro, a Perl hacker and engineer at Cookpad, Inc., we talk about how he started programming from playing an early text-based MMOPRG, how games can be a great training ground for future programmers, and the need for a "third" editor beyond vim and emacs.
(interviewer's note: I've changed the format of the interviews to be conversational rather than set Q&A. My ideal is something like Daniel Jalkut's Bitsplitting podcast. Feedback is always hugely appreciated!)
Goro's First Foray into Programming
gfx: Well then. Shall we deep-dive into why Perl is a wonderful language?
hkm: Well let's start with how you originally started programming.
gfx: Well about 15 years ago there was a MMORPG called Dark Kingdom 2. Back then, MMORPGs were pretty slow paced. You'd schedule "action" for your character for the week, and once a week the game would "update" and send you the result of your actions for the week.
hkm: Oh so this "update" isn't a version update of the game, but rather that's how often you actually get information back. Is this one of those really early text-based Japanese RPGs?? This might be the game that my friends were playing back in the day.
gfx: Exactly. It's kind of like a TRPG but put online. A big part of the community revolved around just chatting about this weekly data output, and since we'd only get updates once a week, we'd have a lot of time to chatter. There were a few thousand players at the time, and you could batch download the data for all the players (their actions, the results of those actions, and how their character parameters changed) in a zip file.
The game itself would only provide this raw data, but there were other 3rd party sites that would collect this data, process it and show stats like "how many players are there in this town" or "how this character has grown over time".
Oh! And you could PK (Player Kill), so it was really important to know where other players were in the game. But since the game itself didn't provide this information, PK'ers would use this data from 3rd party sites to find their prey. :P
hkm: I used to play a game called Ultima Online back in the day which also had PK'ing, so I have a feel for what that the dynamic must have been like.
gfx: When a game has PK'ing, there's this "tension" that makes the game fun :) Though granted, it's a pain in the butt when you're on the side being hunted down!
hkm: I never got on the PK side since I get really nervous in competitive game situations. I kind of regret it now since it's like missing out on half of the game!
gfx: Ah yes. Actually, this game was the reason I started learning about programming. Before getting into this game, I had never touched programming at all. Around the time I dropped out of High School, we got a computer in the house that I could use freely. That's the first time I encountered the Internet.
hkm: Wait, wasn't this during the era when Internet access was really expensive in Japan?
gfx: Well it was either 2000 or 2001 that I started, but even then there was no fixed price plan in Japan yet (or even if there was, it was super expensive). But after 10pm, it was "free to call" time, so I would be online all night and stop when this free period ended.
hkm: Out of curiousity, what time did it end?
gfx: It'd run from 10pm to about 7am.
hkm: Prime time for us gamers ;)
So because it was a once a week batch update system, it was easy to establish a workflow of download, process, and upload to your site. It'd be much harder if you had to do real time log collection...
gfx: Right, it would have been much harder the game were being updated in real time. If it were in real time, I would have never made something like this.
hkm: If the game were in real time, the bar would hake been set so high to make something useful that maybe you would have given up right away.
gfx: I totally agree. In that sense it really was a good, peaceful time in Internet history. The data was only a few thousand entries, so text data could be used just fine without a database.
hkm: Haha, I know what you mean. My own websites (including this one) are just statically generated from text files. No database! :P
gfx: Yup, though eventually I realized that I should have some sort of database and set up SQLite. For a long time I was using CSV files and whatnot though.
hkm: So basically you started playing this game and encountered other people running these 3rd party data sites and thought "hey, this is really useful and seems really interesting!" which made you look into what you could start doing yourself, gradually expanding your coding comfort zone and implementing new, richer features?
hkm: So you looked things up online, figuring out how to call C functions from within Perl, etc?
gfx: That's right. :)
hkm: If this were the early 90's we wouldn't have had these online resources, so I must say that we're really reaping the rewards of progress here. Man the Internet is great huh?
hkm: OH, is this like a calculator for the game?
And I'd grab some of the numbers for the equation from server side.
hkm: Even today, there are people who provide these web calculators for games like Puzzle and Dragons (huge mobile game in Japan).
gfx: Some things never change, especially when it makes games easier. :)
hkm: Reminds me of a friend who created some really complicated open source simulator for World of Warcraft. He even put that on his resume! (laughs)
gfx: Wow (laughs). Well suffice to say that our motivation towards games can be pretty strong.
hkm: I totally agree. I think my hacker tendences started in games like Ultima Online where I was really driven to reduce the repetitive grinding -- though in my case I just used a Macro recorder rather than code.
gfx: It's unfortunate that the recent online games have made it harder to do these sorts of hacks. It'd be nice if the companies would officially let us make these sorts of things, since it's really a great training ground for future hackers and programmers. I really think that this is one of the really fun parts of online games. It'd really be fun if there was a game where almost everything moved through macros, where the game really is about writing those macros.
hkm: You know that reminds me of the new game Notch (creator of minecraft) is making, where the game actually has a fully programmable 16 bit CPU inside the game.
gfx: Wow that sounds amazing.
hkm: Notch's company (Mojang) seems to be filled with programmers from top to bottom, so I guess it makes sense that they would be the ones to put a programmable environment inside a game. It makes me think about how much nicer playing Pokemon would be if we had macros.
gfx: Oh man totally. It would raise the bar for the players of course, but I'd love to play such a game.
hkm: The Japanese Ministry of Education is discussing making programming part of the official curriculum and a similar push seems to be materializing in the States, but I'd imagine that we'd learn much better via things like games. We'd be able to explore through trial and error to make the things we want to make, rather than what we're told to make. I feel like that sort of thing could be more productive than coursework...
gfx: I'm definitely looking forward to such a future :)
Having just a few thousand users would be more than enough (playing alone would get old fast), and there are plenty of scripting languages that can be readily embedded -- JS, mRuby, Lua, ... -- so things are easier now for the creators as well.
hkm: That reminds me that in Counter Strike 1.6, a lot of the more serious (but still recreational) players would access the settings text file to change mouse sensitivities and key bindings, and now that I think about it many of my friends who became programmers messed with this stuff often. This isn't programming at all, yet this feeling of control over the system probably gave us some of the momentum to pursue our technical interests further.
gfx: I don't know this particular game, but I sense a lot of similarities to endlessly messing with settings files for emacs or vim.
hkm: That begs the question: which camp are you in?
gfx: I'm a vim user, since emacs is too difficult for me.
hkm: By "difficult", do you mean the key bindings or elisp?
gfx: I'd say both. And I find that emacs isn't really easy to use without customizing it heavily.
hkm: Haha I'm an emacs user, but I guess I don't use it too heavily. All I really do is write blogs and some HTML/CSS with it, so I just use the basic navigation shortcuts, search, block replace, and some short macros...
gfx: If you use that much I think that's plenty :P
hkm: I personally think block replace is the best thing ever. :)
gfx: I do feel that the initial hurdle is lower for vim than emacs. And once I learned vim, well I no longer had a reason to switch.
hkm: Other than not being able to save or exit the program...
gfx: Oh yes.... ;)
hkm: I accidentally launched vi the other day on my Linode instance and wasn't able to get out! (laughs)
gfx: Yeah... so honestly I don't think neither emacs nor vim are really ideal. I'm hopeful that a 3rd editor enters the scene soon...
hkm: Well Sublime Text seems to be really popular these days. If you were to cherry pick features, what would you do?
gfx: Well I'm not familiar with emacs so we'll put that aside, but with respect to vim, I think it's not ideal that it has different modes. Well actually, having modes is okay, but the default mode should be insert mode rather than command mode. I think this alone raises the bar for new vim users.
Also, the worst part about vim is vimscript, which is the language used to customize vim. You honestly can't do any normal, sane coding with it.
hkm: I do hear that vimscript is terrible...
gfx: Though elisp isn't much better... it's much more powerful as a scripting language, but if asked whether it is user friendly...
So taking this into account, Sublime Text showed some sane sensibilities in choosing Python for its scripting language.
hkm: It does seem like the younger generation of programmers are gravitating towards Sublime.
gfx: Well you know, I used to use the Hidemaru editor back when I used Windows.
hkm: You know I keep hearing about Hidemaru. What is it exactly?
gfx: Hmm, well it's an editor that works pretty well out of the box, is very light, and has quite a few features.
hkm: I'm imagining something like Nopepad++?
gfx: Yup that's pretty apt. But Hidemaru's scripting language sucks too.
hkm: What does it use?
gfx: It's its original language, which sort of resembles BASIC.
hkm: I had imagined something like Ichitaro (Japanese word processor -- think MS Word but 3x worse), but I guess I was totally wrong. I have nothing but positive things to say about notepad++ so Hidemaru must be quite decent.
gfx: Right... but for a 3rd editor to emerge after emacs and vim, I think it's mandatory that it has a proper programming language for its macro programming.
hkm: So this is with respect for developers rather than casual users right?
gfx: True, but when the users can easily expand features, the editor becomes more powerful and an ecosystem surrounding the editor grows.
hkm: I guess it's also true that even the novices grow up at some point, and they'll eventually want to customize their editors.
gfx: That, I think is the ideal editor. But the bar is far too high for both vim and emacs. Regular folks really can't code in them. Sublime has a drawback that it's not FOSS, but I think it has a great chance at continuing its growth.
hkm: Do you feel that as a FOSS community member and as someone who learned from FOSS, a proprietary editor gives you qualms?
gfx: Well Hidemaru is a proprietary editor so I don't have any reservations about using proprietary software. But it has the effect of reducing the number of potential users.
It also prevents patches from being provided from the outside, so I'm afraid that we'd have to abandon the editor when the developers stop working on the product. So as a development tool FOSS is much more desireable.
hkm: I guess it'd be ideal if Sublime Text went open source in the event that its developers abandon the projecs (like Text Mate), but obviously there's no guarantee. On the other hand emacs and vim let us 'control our own destiny' so to speak.
gfx: Right, it's a tough situation for sure. And that's why I'm really hoping for a 3rd major editor to come out.
hkm: Are there any candidates that you can think of?
gfx: Hmm... I can't think of any.
hkm: Well editors are things that programmers tend to want to make right? Every developer seems to want to make their own editor and their own programming language.
gfx: I totally understand how they feel, and I think it's motivated by the fact that ecams and vim both suck.
hkm: Do you have a desire to make your own editor, once you become an Open Source NEET in the future? 
gfx: Oh for sure.
hkm: Any thoughts on what it'd be like?
gfx: It'd definitely draw heavily from vim. The default would be insert mode, and I'd change the scripting language.
hkm: What language would you use? Perl? (laughs)
gfx: Haha, well hmm... at this moment I think I'd use mRuby. mRuby is independent of the filesystem so I think it's ideal for a macro language. It's also easy to write DSL.
Another challenge is to decide between GUI and CUI (graphical vs command line).
hkm: Both emacs and vim have both right?
gfx: Right. And I think the best is to have both, especially since you need to be in the terminal when you're working server side. You have to be in the terminal then, so not having terminal support really limits your use cases.
I personally use vim in the command line and rarely use gvim.
hkm: I tend to go back and forth, but I found that the GUI version of emacs on Ubuntu won't accept Japanese input, so I had to go back to the terminal :P.
gfx: Wow I did not know that, but I have heard of some corner cases for Japanese input.
hkm: I've heard of several people who've chosen to use Sublime or Textwrangler in order to write in Japanese.
gfx: I've heard that even in Sublime, Japanese input causes the screen to jitter in certian versions. Also, OSX has a GUI framework called GTK+, but if you use this you can't use Japanese input at all. So accepting Japanese input in a GUI application is pretty hard.
So initially I think I'd create a terminal based editor. But of course there are many users who prefer a GUI editor, particularly Windows users. So the best option is to support both GUI and CUI, but that raises the bar significantly so it's a conundrum.
hkm: Hmm, well since it's a personal pet project, I feel like something like the GMail launch (video) would work? 
gfx: Making an editor is something I'd love to do, but I also want to make compiler/interpreter as well. And if I had to choose which of these to devote myself to, it'd be the compiler/interpreter.
hkm: Is one more daunting than the other? I'd expect the compiler/interpreter to be much more challenging.
gfx: I actually think they're about the same. They're both a bit endless when you start chasing ideals.
hkm: Is it because designing the extensible architecture is challenging?
gfx: Right. And these days autocomplete has become so good that supporting this to the extent I'd want to will be quite a task. Both Visual Studio and Eclipse for Java are quite great at this, but getting a standard editor (rather than an IDE) to this level is quite difficult. As it stands, autocomplete on vim is quite a challenge.
hkm: So you'd like to design an editor where developers can create plugins that can extend and improve the autocomplete as well?
gfx: Exactly. I think whether or not we can really thoroughly design that part is the crux of editor design. I think one thing that's particularly bad about vim is that it can't do asynchronous operations by default.
If you have a very large project, you'd need to scan the entire project and populate the autocomplete options. So in some cases we have to wait 1-5 seconds when waiting for autocomplete, which makes coding impossible. You'd want to keep scanning and populating autocomplete candidates in the background while not affecting the foreground editing, but this isn't possible in vim. This is essence why I think vim is a dead end.
hkm: So this is what Visual Studio must be doing.
gfx: Right. Eclipse as well. So you'd expect to be able to do this asynchronous operation in vim, but the reality is that you can't.
hkm: So you'd be looking to combine the great navigability and shortcut capabilities on vim with the option enabling the "richness" of features of IDEs.
gfx: Right. I understand that given its long history, it's almost impossible for vim to support such features. After all, it's only in recent years that such "rich" features have come into demand.
I primarily use vim, but it's really impossible to write Java without Eclipse.
hkm: I remember giving up after 5 seconds when trying to code a Hello World Android app in emacs.
I guess emacs and vim have so much history and old design decisions baked in that they are fundamentally not designed to support the sort of features that modern programming demands?
gfx: Yeah, and so now is the time that we really need a new editor. And of course I expect that I'm not alone in thinking this way. Many others are probably thinking the same thing right now. And ideally, we'd all make our own editors, we'd duke it out, and it'd be great if 10 years from now, 1 (or more) of these editors would have matured and have become robust.
And I mentioned mRuby as a candidate language, but ideally I'd like to make it in my own language. Of course, that's not exactly easy. ;)
Continued to Part 2 where we talk about what Goro considers to be his ideal language, and his affection for Perl.
 A NEET or neet is a young person who is "Not in Education, Employment, or Training". (Wikipedia) An "Open Source NEET" is a software developer who has chosen not to be employed and instead spend all her time on FOSS work.