Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Ruby

Interview With the Creator of Ruby 89

snydeq writes "Ruby creator Yukihiro Matsumoto discusses the past, present, and future of the popular programming language, calling mobile the next target for Ruby: 'I'm currently working on an alternative subset or dialect of Ruby for the small devices. I'm going to make it public early next year. Of course, mobile computing is the way to go, so that's one of the reasons I focus on the Ruby dialect working on the smaller devices.'"
This discussion has been archived. No new comments can be posted.

Interview With the Creator of Ruby

Comments Filter:
  • Most of those smaller devices don't require subsets of functionality or features. Any general purpose language that doesn't require a super heavy runtime environment or a bazillion linked libraries should get along fine with an API to interact with events generated by the device. See Android, etc.
    • by Anonymous Coward

      You seem to be implying that Android does not implement a subset of Java.

      http://www.zdnet.com/blog/burnette/java-vs-android-apis/504

      • by gl4ss ( 559668 )

        androids version of _java_ is quite complete.
        it's certainly not midp 1.0 type of subset on the vm side. you know, because you're not lacking things like floats.
        api's are another matter of course. but what would you do with a mouth class if you had no face to scream from.

        if he's talking things like hw abstraction api's, then that's another matter. and highly platform specific. ui classes are also another matter.

        otherwise there's no difference between mobile and non mobile, unless ruby needs some stupid busyl

      • Android includes a subset of the libraries normally included in the JDK, not a subset of language features.
  • by AdmiralXyz ( 1378985 ) on Wednesday September 07, 2011 @10:43AM (#37327922)
    There's nothing really wrong with TFA, but there's nothing there either. It's so bland. The questions are just "Why did you create Ruby? What's next for Ruby?" I mean, seriously? If you were interviewing someone for a high school newspaper that might be OK, but they really can't do anything better? There's nothing more interesting you could ask Matz?
    • by Anonymous Coward

      Such as?

      • by Anonymous Coward on Wednesday September 07, 2011 @01:14PM (#37330242)

        Oh let's see...

        1. What are prospects of incorporating true, concurrent multithreads?

        2. JIT - why or why not? and when?

        3. Is performance closer to Java realistic for Ruby? What are the obstacles?

        This is just the most pressing stuff and I don't even use Ruby much anymore.

  • by Microlith ( 54737 )

    Of course, mobile computing is the way to go, so that's one of the reasons I focus on the Ruby dialect working on the smaller devices.

    While I do have Ruby on my N900, I wish him the best of luck in his goals. Between the attacks from the Apple and MS camp on Android and little to no attention being paid to real solutions like MeeGo, all we'll be left with in short order is anti-geek platforms like Windows Phone and iOS, where running things like Ruby (or Python) are expressly verboten.

    • by Anonymous Coward

      The real question is why in the world would any non-developer (and I use the term lightly) run a CPU burning, battery draining, GC requiring interpreted language on a mobile device in the first place? Python / Ruby / Perl / TCL, all of these are prototyping / utility languages. They're not designed to build low overhead / low cycle apps. I can see why developers who aren't proficient in C / C++ / Objective-C want them, but in the context of user experience, there's absolutely no net benefit to using these l

      • The real question is why in the world would any non-developer (and I use the term lightly) run a CPU burning, battery draining, GC requiring interpreted language on a mobile device in the first place? Python / Ruby / Perl / TCL, all of these are prototyping / utility languages. They're not designed to build low overhead / low cycle apps. I can see why developers who aren't proficient in C / C++ / Objective-C want them, but in the context of user experience, there's absolutely no net benefit to using these languages in creating apps for mobile devices.

        Actually, there is. Most mobile devices are not rebooted frequently and have a relatively (to desktops) small amount of RAM. Also, many mobile apps are long running. An app might be run for weeks before being closed or before the device is rebooted. This is a recipe fore heap fragmentation. Garbage collected language runtimes don't fragment memory, or if they do they can clean it up very easily. Once a C malloc hands you a block of RAM, the OS and language runtime cannot move it around to reduce fragme

        • You do know that, except for low-level system code and the vm itself, most of Android is written in Java?
        • by chromatic ( 9471 )

          Garbage collected language runtimes don't fragment memory, or if they do they can clean it up very easily.

          It's incredibly easy to fragment memory in a language with GC; see Firefox.

          With that said, you can use a copying or compacting GC strategy to minimize the possibility, but then you increase your memory requirements to manage the copy and you reduce your cache coherence.

    • all we'll be left with in short order is anti-geek platforms like Windows Phone and iOS, where running things like Ruby (or Python) are expressly verboten.

      I'm not aware of any restrictions regarding writing apps in Python (or any other language) for Windows Phone. The problem is that it doesn't have a Python implementation targeting it - CPython requires a native code compiler, which is not available, and IronPython requires DLR, which relies on certain .NET features not available on WP. It is still quite possible to implement something less efficient than IronPython on WP subset of CLR, and then write apps in it.

      As for iOS, it used to have an explicit provis

  • I am not sure why... (Score:4, Interesting)

    by Windwraith ( 932426 ) on Wednesday September 07, 2011 @10:45AM (#37327956)

    ...but this statement:

    > Of course, mobile computing is the way to go

    It kind of depresses me for some reason. I am not being ironic, I am serious. I don't know why that makes me feel down.

    I feel like all the training I did to be able to code games** in a PC is going to be obsolete before I know it.

    **or any other desktop coding

    • by lynnae ( 2439544 ) on Wednesday September 07, 2011 @10:50AM (#37328050)

      I feel like all the training I did to be able to code games** in a PC is going to be obsolete before I know it.

      **or any other desktop coding

      welcome to the world of developing.

      This is how it's been, and how it will continue to be. Keep growing your skill set and you'll be fine (and a better programmer for it).

      • I am not really a professional coder. I don't even work in computer-science related jobs. I just spent my limited brain power into somewhat successfully learning a portable language like C with GL and such.
        Because of that, I am not as passionate about coding as many users in Slashdot. For me it's a means to an end (game dev), and a pretty painful one at that.

        Without time and resources ($$$) to buy books it was a pretty slow and painful experience (specially because asking for coding stuff usually has 2/3 pe

        • I am not really a professional coder. I don't even work in computer-science related jobs.

          Same here; I'm a web developer.

        • by gknoy ( 899301 )

          Of course you're capable of moving on. It just takes time and work.

          There are books on Android programming - several of them (I like "Hello Android") have great code examples. The Android SDK (and emulator) is free, and uses the (also free) Eclipse IDE. The cook isn't free, but the SDK (and code samples + tutorials from Google) and IDE all cost nothing but your time to download them. Pick something and DO it. You can! You will mainly get better at coding from writing code, so make up a toy application tha

          • Heh, well, I always thought of "sales" as "players" instead. I never intended to sell any of my (game) work, just hoping that people picks it up and enjoys it.

            *old man voice* Come son, listen to my story. (Skip to last paragraph if you don't care :P)

            Actually the promise came because someone, years ago, was concerned about starting a game because of costs in software and hardware. Writing my first game was painful but proved that it was possible, took a few months to get the engine rolling (C89 + GL + SDL +

        • by lynnae ( 2439544 )
          What I do to make it interesting for myself is to decide on one particular application, and then build that application in every language I know, and every language I learn.

          It teaches me the differences between the languages, and some of their relative strengths and weaknesses. (plus it gives a portfolio of my work, since the programs I work on for my job are not showcaseable).

          Lots of people would be bored to death by that approach, but I bet they each have their own.

          If you learn well from books, g
    • > I am not sure why...

      No?

      > I feel like all the training I did to be able to code games in a PC is going to be obsolete before I know it.

      Oh, there it is!

      But really, it's not that mobile computing is "the way to go", just that desktop computing is no longer "the only way to go".

      People who've been closed-mindedly programming their Windows apps for years are scared that they now have to think in different terms, be those architectural terms like "do I need to think about 64-bit processors" or "do I need t

      • Actually I develop cross-platform FOSS games, not really stuck with Windows apps you know ;)
        That I code games doesn't mean I don't take it seriously, despite (as pointed in other post) not being as passionate about it as other people here.

        To be honest, I find portable devices to be expensive and not powerful at all.
        In my lunch break, with my cheap netbook, I can do everything I can do at home (2D work, 3D work, coding, tracker music, compiling, debugging, etc). It's the only way to develop a game while havi

        • by TheLink ( 130905 )
          Speaking of cross platform, I wrote a program in perl that works on OSX, Solaris, OpenSolaris, AIX, Linux (Ubuntu, RedHat, etc).

          The main problem I'm facing is the Linux distros don't generally include libraries that allow my program to easily make https connections (http works).

          Compiling the https stuff for each and every distro (and significant version) and bundling them sucks.

          I'm not aware of many ways around it. I need the stuff to be able to run on as many OSes and OS versions as possible, and the downl
          • Well, yes, I actually do different builds for and in my target platforms. It's an extremely brute and simple approach but never had a complaint from users.
            For the rest I provide the sources and detailed install instructions (download this, open this, type this, done) and a dummy build script in bash for those without autotools, and a more precise script for those with debian systems (fetches and builds everything).

            • by TheLink ( 130905 )
              Thanks. How do you deal with stuff like different versions/releases of Suse, OpenSUSE, different versions of Redhat, Ubuntu, Debian, Mint, Fedora, etc.

              Do you find that in practice they tend to be backward compatible within the distro? So you just build for the oldest supported distro (with latest backported patches of libs if possible - ugh) and it works on the new distros?

              Or do you find you end up having to build for each distro version? If so it probably means that we might not bother with supporting "Lin
    • by vlm ( 69642 ) on Wednesday September 07, 2011 @11:11AM (#37328416)

      I feel like all the training I did to be able to code games** in a PC is going to be obsolete before I know it.

      Training rapidly becomes useless. Education never becomes useless.

      Memorize how to use a linked list library in Pascal = rapidly useless

      Learn what a linked list is, why and when you'd use it = useful forever

      Also much like human languages (supposedly) the first three languages are pretty tough, but once you learn a bit of ten or so, its pretty simple since all the concepts are the same. The hard part is knowing how to index thru an array without a picket fence mistake and figuring out how to troubleshoot it. The easy part is remembering or googling the syntax.

      • I'm a kludgy self taught coder and I just googled for a moment to no avail ... can you help this perma-newb out:
        What is a "picket fence mistake"?

        • by byner ( 1428013 )

          When building a fence, if you put a post say every meter, how many posts do you need for a 10m section of fence?

          It's an example illustrating an one-off error. It's pretty common to get this or similar problems wrong and catch yourself later.

        • As a better answer to the two others who posted, I will give an example. C and C++ (and others) start array indexing from zero.If you have a 10 element array, in C/C++ you would access the last element as myarray[9]. You know that you have 10 elements, and if you are not careful you might try to index the last element as myarray[10]. This will generally cause errors in you program and you hope the compiler can catch them for you. In languages like C/C++, this could even be a hidden error since if you are no
          • I get it. Thanks. I learned perl way back when to avoid malloc but should probably go back and get closer to the machine.

      • You got a good point, and fortunately learning how to do those in C gives you enough understanding to do them in...Lua, for example. Or Ruby to stay on-topic.

    • by TheLink ( 130905 )
      The stationary computers aren't going to vanish.

      The mobile devices (pagers, portable gaming devices, phones, laptops, tablets, prosthetic brains) are the ones that will be squeezed into one device. And that's where the extinctions will be.

      Most people don't want to carry so many extra portable devices.

      So if you had a prosthetic brain that did everything a phone did (and more: virtual telepathy, virtual telekinesis), you would be tempted to not carry a phone - especially if the antenna wasn't passing near an
    • All that VB5 stuff I did back in the 90s...all that work learning DAO, RDO and ADO...no one cars now...sniff. Good thing I learned C#, Ruby and Objective C...
  • Mobiles today are about the same power as desktops were when anyone cared about ruby so it should fit well

  • by smooth wombat ( 796938 ) on Wednesday September 07, 2011 @11:06AM (#37328318) Journal

    how hard was it to find shoes in the correct color then add all those sequins? I mean, I've seen the pair at the Smithsonian but it's my understanding there were others made as well.

    Also, did Dorothy get to keep a pair?

  • I tried to install a program written in Ruby and the experience left me with a very bad impression [lee-phillips.org] of the Ruby ecosystem.
    • I had similarly annoying experiences with updating stuff on OSX. It could do with a nice package manager.

      • by lee1 ( 219161 )
        I agree (and no, Fink, etc., don't cut it). It's one of the reasons I prefer Linux and only use OSX if I have to.
    • FWIW, the difference between the 1.8 and 1.9 versions is effectively a major version change despite not being numbered that way.

  • Ruby is a nice little language. There are a few oddities and the C Ruby interpreter, as Matz admitted, is not very efficient.

    Rails, which is what everyone thinks of when they hear Ruby, on the other hand -- well, I'll stay far away from it thanks.

    Count me among those developers who never thought that the way to build robust and flexible applications is to first define some database tables, then write a little CRUD code to generate screens. Maybe back in 1989, when SQL databases were new and there were a lo

  • Matsumoto, when you created Ruby you did not have facial hair. But shortly after growing some, Rails came out and changed everything. Now Ruby is popular. Do you feel this is connected to your facial hair?
    • It's more complicated than that. For you see, when he started growing facial hair, he started waxing his cock, balls, taint and asshole. (It's some sort of ying/yang thing). Hairy crotch, ruby languishes. Bald balls, ruby flourishes.

Life in the state of nature is solitary, poor, nasty, brutish, and short. - Thomas Hobbes, Leviathan

Working...