Discussions

News: Interop Blog: Is Ruby the new Visual Basic?

  1. Interop Blog: Is Ruby the new Visual Basic? (57 messages)

    The Ruby programming bandwagon is picking up speed and both Sun and Microsoft have jumped onboard, Huw Collingbourne says in "Is Ruby the New VB?". In a way, Ruby embodies many of the features that made Visual Basic so successful. It is not so much what Ruby does today that is causing all the excitement - but, rather, what it might do some time soon.
    You might wonder why on earth Sun and Microsoft are so interested in Ruby. On the face of it, there is nothing earth shatteringly new about the language. Ruby is a scripting language, a bit like Perl, which implements a fairly strict version of object orientation, a bit like Smalltalk. Arguably, it is not so much what Ruby does today that is causing all the excitement - but, rather, what it might do some time soon. Over the last decade or so mainstream programming languages have become steadily more complex and syntax-heavy. Established procedural languages such as C and Pascal have been adapted by grafting onto them an ‘object-oriented’ layer in order to create languages such as C++ and Delphi. But the resulting languages have been hybrids lacking both the syntactic clarity and the rigorous object orientation of Smalltalk. The same criticisms can also be made of languages such as Java and C# which, in principle, have been designed from the ground up but, in fact, carry with them a lot of baggage from their C heritage. Ruby, by contrast, makes a completely fresh start. It is not only rigorously object oriented but it also benefits from a simple and decidedly un-C-like syntax. ... In a way, Ruby embodies many of the features that made Visual Basic so successful. Unfortunately, while the original version of VB was simple and concise, it lacked object orientation. Its successor, VB.NET, has gained object orientation but has sacrificed of a good deal of its simplicity and conciseness.
    Ruby's made a lot of headway in the Java market, not just as a platform, but by running on the Java VM. What do you think of the concept of Ruby as the "new VB?"

    Threaded Messages (57)

  2. Maybe Not[ Go to top ]

    Maybe Ruby, Groovy, Python, etc sit in some space between VB and Java/C++, balancing ease of use with power. So it could spill into a little of the VB space, but so did Java and C#. However when I think of VB, I also think of the "non-programmers" I've found who program/script Access and other MS Office applications. I don't think these people are ready to jump ship to get closures or anything VB can't already do.
  3. I mean really, haven't this been the case for past few years. Its now more about asp.net, ado.net, Hibernate, struts, jsf, ruby on rails, grails, catalyst etc ... rather than java, c#, VB.Net, ruby, perl, python or tcl And honestly is Vb .Net really that bad or that flawed, surf the net for Vb.Net Vs C# articles and you will find out that for various reasons (some of which technical) both languages are more or less feature equivilant I prefer Vb.Net over C# because its the default built-in expression language for various applications i use! so again this takes us back to the idea that you pick your framework first, language second Yet to totally contradict myself I wish if groovy would pick up more steam!
  4. What!?[ Go to top ]

    In a way, Ruby embodies many of the features that made Visual Basic so successful
    I'm not taking anything away from Ruby (I do quite a bit of Rail development), and I dislike VB, but I don't agree with this statement at all. VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful. Like I said above I personally don't like VB and wish it would die a horrible death, but anyone insinuating that Ruby is having as big of an impact as VB (or will be as successful as VB) is is delusional.
  5. Re: What!?[ Go to top ]

    VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful.
    I was looking over someones shoulder the other day at some VB and I was wondering why some company doesn't just steal this idea and create a little DSL for building GUIs like this? I think VB sucks as a general programming language but it really makes building desktop apps a lot easier than most anything I've ever used.
  6. Re: What!?[ Go to top ]

    ..I was looking over someones shoulder the other day at some VB and I was wondering why some company doesn't just steal this idea and create a little DSL for building GUIs like this?...
    Delphi used to allow building applications even easier than in VB and had very good language underneath (Object Pascal)... everything in Delphi was blazingly fast in 1994 - compile. debug, runtime, UI building....
  7. Re: What!?[ Go to top ]

    Agreed. Delphi was great. I am a long-time Delphi programmer (from the beta of version 1.0) and I would like to see Ruby being developed for event-driven programming in much the same was that Pascal was developed by Borland (to become Delphi). best wishes Huw
  8. Re: What!?[ Go to top ]

    Agreed. Delphi was great. I am a long-time Delphi programmer (from the beta of version 1.0) and I would like to see Ruby being developed for event-driven programming in much the same was that Pascal was developed by Borland (to become Delphi).

    best wishes

    Huw
    I've never used Delphi, but Dolphin Smalltalk is the most slick Windows GUI development environment I've seen by a long way. It really is good, unfotunately the company behind it folded earlier this year (not enough marketing dollars I guess). If you can exploit the OO capabilities of Ruby to come up with something similar then you really will be on to something special. Good luck, Paul.
  9. Smalltalk[ Go to top ]

    Dolphin Smalltalk! Now you and I are definitely thinking along the same lines. I love(d?) Dolphin Smalltalk and I was very disappointed when Object Arts (who made it) decided to stop future development. It constantly amazes me how many great ideas were put into the 'original' Smalltalk towards the end of the '70s/early '80s and which have still not been taken up by modern languages and IDEs. One of the things I find frustrating about many Ruby programmers' coding style is that they create 'flat' class hierachies - i.e. everything descends from Object - and populate them with long and complex methods, whereas Smalltalk programmers typically create dense hierachies (with many levels of descent) but very small methods (as only the differences from ancestor methods need to be coded). To a large extent, I think this is explained by the fact that the Smalltalk language is provided with an environment optimized for OOP so it's easy to create complex family trees whereas, until quite recently, there were no decent IDEs for Ruby at all. But there is still a long way to go before Ruby coding becomes as OOP-friendly as Smalltalk. It does seem bizarre in the 21st Century to be looking back to a language/IDE produced in the '70s and '80s but I really do think that there is much about Smalltalk that still seems surprisingly 'modern'. best wishes Huw
  10. Re: Smalltalk[ Go to top ]

    Ruby doesn't have keyword arguments, so can't quite get that English-like expressiveness that Smalltalk has. Smalltalk seemed to have suffered from the same problem that Common Lisp did. It never came up with a high-quality open source implementation (nope, Squeak doesn't cut it).
  11. Dolphin[ Go to top ]

    I would go further and say that Dolphin Smalltalk is(was) the slickest Smalltalk environment out there. But I think the demise of it contradicts your assertion that there's some widespread desire for Smalltalk-like languages. Yeah, Ruby is fun and has a concise, readable syntax. But at the end of the day it's all about Rails.
  12. Re: Dolphin[ Go to top ]

    I would go further and say that Dolphin Smalltalk is(was) the slickest Smalltalk environment out there.

    But I think the demise of it contradicts your assertion that there's some widespread desire for Smalltalk-like languages.

    Yeah, Ruby is fun and has a concise, readable syntax. But at the end of the day it's all about Rails.
    Hi Frank, You're right Rails is the catalyst. But once the Genie is out the bottle who knows what may happen next... :^) I'm a complete novice at Lisp, but I appreciate it's powers. Hardware has improved several orders of magnitude since Lisp and Smalltalk first saw the light of day. Yet software abstraction is still in the dark ages (constrained by the limits of the C language). A move beyond C and on to higher programming abstraction is long over due IMO, and at the moment Ruby is the leading contender in this direction. Lets wish Huw the best, and wait and see what happens. Cheers, Paul.
  13. Re: What!?[ Go to top ]

    In a way, Ruby embodies many of the features that made Visual Basic so successful


    I'm not taking anything away from Ruby (I do quite a bit of Rail development), and I dislike VB, but I don't agree with this statement at all.

    VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful.

    Like I said above I personally don't like VB and wish it would die a horrible death, but anyone insinuating that Ruby is having as big of an impact as VB (or will be as successful as VB) is is delusional.
    Completely agree. What made VB successful is that it made the creation of good-looking and functional Windows applications dead simple (and Visual Studio was a big part of this success). As much as I like Ruby, predicting its success by drawing a parallel with Visual Basic doesn't make any sense. -- Cedric
  14. Re: What!?[ Go to top ]

    Mmmh... I just looked up the company this person works for. Not surprisingly, it's a Ruby shop, but better than that: they make a Visual Studio based Ruby IDE. Nothing wrong with that, but please next time, disclose that this post is just an ad. -- Cedric
  15. Re: What!?[ Go to top ]

    In a way, Ruby embodies many of the features that made Visual Basic so successful


    I'm not taking anything away from Ruby (I do quite a bit of Rail development), and I dislike VB, but I don't agree with this statement at all.

    VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful.

    Like I said above I personally don't like VB and wish it would die a horrible death, but anyone insinuating that Ruby is having as big of an impact as VB (or will be as successful as VB) is is delusional.

    Completely agree. What made VB successful is that it made the creation of good-looking and functional Windows applications dead simple (and Visual Studio was a big part of this success).

    As much as I like Ruby, predicting its success by drawing a parallel with Visual Basic doesn't make any sense.

    --
    Cedric
    How about if Ruby makes creating good-looking and functional web applications dead simple (and some IDE becomes a big part of that success)? AFAIK creating reasonable web applications isnt yet something that an average "power user" can do, anything that can change that is bound to be successfull? I dont think that Ruby is there yet, and I am not sure if Ruby is the best candidate to ever get there, but what if.
  16. Re: What!?[ Go to top ]

    How about if Ruby makes creating good-looking and functional web applications dead simple (and some IDE becomes a big part of that success)?

    AFAIK creating reasonable web applications isnt yet something that an average "power user" can do, anything that can change that is bound to be successfull?
    Am I the only one who finds it humorous that Joe Sixpack could built a decent looking Windows app over a decade ago using VB, but the same guy couldn't build a similarly functional website today without a small army of Javascript gurus? Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  17. Re: What!?[ Go to top ]

    How about if Ruby makes creating good-looking and functional web applications dead simple (and some IDE becomes a big part of that success)?

    AFAIK creating reasonable web applications isnt yet something that an average "power user" can do, anything that can change that is bound to be successfull?


    Am I the only one who finds it humorous that Joe Sixpack could built a decent looking Windows app over a decade ago using VB, but the same guy couldn't build a similarly functional website today without a small army of Javascript gurus?

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java and .NET
    You are not alone (though you might want to be).
  18. Re: What!?[ Go to top ]

    I am not sure it is a good idea to have Joe Sixpack writing code, even in Visual Basic... he might cause a lot of problems in the long run. Then, most of the problems come from trying to use the wrong tool to solve a problem (Excel abuse comes to mind). Anyway, I hope Ruby is the next Visual Basic. At least we'll be able to run those clients on something other than Windows. Paul Casal Sr Developer jbilling.com The Enterprise Open Source Billing System
  19. Re: What!?[ Go to top ]

    I am not sure it is a good idea to have Joe Sixpack writing code, even in Visual Basic... he might cause a lot of problems in the long run. Then, most of the problems come from trying to use the wrong tool to solve a problem (Excel abuse comes to mind).

    Anyway, I hope Ruby is the next Visual Basic. At least we'll be able to run those clients on something other than Windows.

    Paul Casal
    Sr Developer
    jbilling.com
    The Enterprise Open Source Billing System
    Well, its not a good idea, but Joe Sixpack doesnt care, and he has a boss that doesnt want to wait 6 months for an app, built by someone who doesnt understand the business and hence takes valuable time from staff when creating countless iterations of a specification they dont understand. I guess Cobol was the first language that promised to enable business people to automate by themselfes, but it was certainly not the last, and VB was successfull for the same reasons. But then someone has to clean up the mess after Joe of course...
  20. I miss VB[ Go to top ]

    VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful.
    I'm sorry Ruby, but you are no VB. Please correct me if I'm wrong, but the 30 seconds I took browsing the Ruby on Steel VS IDE, I didn't see any of the GUI builder stuff that made VB famous. On a side note, anybody miss VB? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  21. Re: I miss VB[ Go to top ]

    VB had a GUI builder that was drop dead simple, a simple (easy to learn) event model, and lots of out of the box components all powered by a scriptingish language. Avg joe developer was able to build usable gui screens for the first time. This is the biggest thing what made VB successful.


    I'm sorry Ruby, but you are no VB. Please correct me if I'm wrong, but the 30 seconds I took browsing the Ruby on Steel VS IDE, I didn't see any of the GUI builder stuff that made VB famous.

    On a side note, anybody miss VB?

    --
    Bill Burke
    JBoss, a division of Red Hat
    http://bill.burkecentral.com
    The only thing I think that it shares with VB is - they make the simple things simple but they make the complex things pretty much impossible.
  22. Ruby Visual Design[ Go to top ]

    As mentioned in my blog post, visual design for .NET will follow the release of IronRuby. We have a form designer in development which you can see here: http://www.sapphiresteel.com/IronRuby-Visual-Form-Designer best wishes Huw
  23. Re: What!?[ Go to top ]

    ...I personally don't like VB and wish it would die a horrible death...
    developer snob?
  24. Re: What!?[ Go to top ]

    ...I personally don't like VB and wish it would die a horrible death...


    developer snob?
    I guess I do sound that way. my hatred comes out of having to support large amounts of VB spaghetti code produced by hack developers. I guess I should hate the developers not the language. I'm currently working on a project redoing an Excel/VBA application with 14,000+ lines of code. I have almost broken down in tears twice this week.
  25. Re: What!?[ Go to top ]

    I'm currently working on a project redoing an Excel/VBA application with 14,000+ lines of code. I have almost broken down in tears twice this week.
    I know how you must have felt, often I am left completely clueless by VB spaghetti, the only way I can get through sometimes is to analyze what it does from the outside, I am sure one can program neat in VB but is is too easy to mess up.
  26. Ironically, the original project that led to Visual Basic was code-named Ruby :-). http://en.wikipedia.org/wiki/Visual_basic
  27. Ruby and VB cannot be compared[ Go to top ]

    VB was a visual Windows implementation of Basic-like language syntax. An example of even-driver programming and easy manipulation of buttons, boxes etc and their properties. Windows and GUI were the key here. VB's scope was narrow... Ruby is following an entirely different path. Here the language is aiming for a 100% Object Oriented language. GUI is not the main issue. Ruby, if successful, might be the language many have been looking for all these years. As a S/370 man, I have never been so impressed by anything new, for the last 20 years... But Ruby changed all that. Concise and precise, no dependence on the stupid {}!!!
  28. Ruby Now and in the Future...[ Go to top ]

    Some interesting comments here. In my own view, Ruby is definitely not all about Rails - even though 'Ruby On Rails' has undoubtedly been responsible for kick-starting a fairly widespread interest in Ruby itself. This is why my own company's IDE, while offering first class support for Rails, is not described as a "Rails IDE" but as a "Ruby IDE". Some other companies disagree with us and brand their products "Rails" first and "Ruby" second. Time will tell which of us is right but as far as I am concerned, Rails adds some useful features to the Ruby language in the same way that other frameworks (Pear, Django, Seaside etc.) add useful features to their target languages. But the language comes first, the framework comes second... ;-) On the lack of GUI in Ruby. All we can say for sure at the moment is that the current interest in Ruby is not based on its interface design or event-driven programming capabilities (which are poor or non-existent). It is my belief that Ruby (its VMs, compilers, frameworks and support tools) will change very considerably in the next couple of years. JRuby and IronRuby are two interesting new projects. Ruby used with graphical frameworks such as Silverlight and Flex also offers some interesting possibilities. Again, time alone will tell. Maybe we should continue this conversation in 2009... :-) best wishes Huw
  29. While I doubt that VB has any place in the evolution of languages that led to Ruby (it seemed to be more of a response to Python), I can see where it can succeed in areas that VB is most commonly used; as a glue language for app-scripting, i.e. VBScript w/ Microsoft Office. It's particularly adept at domain-specific languages. I believe it may be better put to use in this arena than in web site development, seeing as it doesn't profile well against interpreters like the JVM or Perl's runtime.
  30. ...both Sun and Microsoft have jumped onboard...
    Microsoft is interesting, but who cares about Sun? If pretty much any other company "jumped onboard" it might also be interesting, but Sun jumps on board most anything, so why is that interesting? - Don
  31. wow[ Go to top ]

    ruby must be in trouble if it's being compared to VB in a +ve way.
  32. No[ Go to top ]

    DSL mean Domain Specific Language, Ruby's domain is not Visual, I wish it was but it's not. I never programmed in VB but I was reasonably useful with most 1980s basic dialects. From memory you could draw a box on the screen with as few as one or two lines of code, 10 at the very most. Logo is another great DSL for graphics but show me a program I can run on my various machines (Windows, Mac, Linux, Solaris and iPhone) in Ruby that will draw a box on the screen with so few lines without having to load extensions. Take this one step further and now display a "Hello World" dialog on the screen with "OK" and "Cancel" in under 10 lines and without extensions and I'll admit that Ruby is finally getting into the Visual domain. I would love to see this because I'm starting to demonstrate to my three children what programming is all about but the best I've found so far to draw pretty lines is Logo, sadly that doesn't run on the iPhone yet so role on Visual Ruby! Is Ruby the new VB? No, it's well structured and multi-platform. -John-
  33. Hi All, The reason why both Sun and Microsoft are jumping on to Ruby is because they both have a lots of clever people that really understand OO and functional languages like Smalltalk and Lisp. Sun did a lot of research on OO, specifically with Self, and Microsoft has a massive research budget and has been doing lots of interesting stuff with functional programming ideas such as LINQ. I remember reading articles by people who were struggling to build OO component frameworks in the early 90's with C++. Who remembers Taligent, OpenDoc and SOM? CORBA and COM are other examples, and let's not forget 'OO' Operating System attempts like Pink. All these things failed because C++ was not OO and wasn't the right tool for the job. Yet marketing bosses insisted that an inappropriate hybrid language derived from C was used because that was the incumbent technology of the day. What I find interesting is that a Japanese home hobbyist has knocked up a true OO language in his spare which has gone on to be "adopted" by "Software" companies like Sun and Microsoft with multi-million dollar research budgets :^). What is the lesson to be learned here? Firstly vendors will sell you what ever it is they think you will buy, and secondly we end up with the technology we deserve. As far as OO is concerned the mainstream is mostly in the dark ages and IMHO the average Java programmer still doesn't fully appreciate what OO is all about (i.e message passing). Without open source language efforts like Python, Squeak and Ruby mainstream programming was destined to stay in the dark ages for an eternity, and vendors would happily have carried on selling us so called "OO" manure like EJBs 2.1. Paul.
  34. I remember reading articles by people who were struggling to build OO component frameworks in the early 90's with C++. Who remembers Taligent, OpenDoc and SOM? CORBA and COM are other examples, and let's not forget 'OO' Operating System attempts like Pink. All these things failed because C++ was not OO and wasn't the right tool for the job.
    C++ was not OO º$%&/!=*???? Saint Bjarne Stroustrup enlightenment us :) OK C++ is not a pure OO language but who cares?? C++ has been a very successful language, the problems were more related to: 1) Fragmentation: too many compilers, too many dialects, not ISO conformance, non-portable APIs (MFC vs Unix world) and of course non-portable binaries. 2) Buggy compilers (for instance C++ exceptions), continuous ABI changes 3) Very high requisites (in the past): a C++ program generated a bigger executable than in C, C++ was a bit slower than C, C++ exceptions were usually forbidden because the executable was bigger or some compilers didn't support exceptions... Java solved many of these requisites with the bytecode paradigm, the one platform for all platforms and a hard control of the JVM providers (certification etc). My loved FireFox, I'm using now, is a C++ beast, I can hardly imagine it developed in Java (previous attempts were failed, may be now...). Think about your office suite... more examples? Ruby only will be successful if it provides something more than minor language quirks.
  35. I read the Mozilla Developer Center "C++ Portability Guide": 1 C++ portability rules * 1.1 Be very careful when writing C++ templates * 1.2 Don't use static constructors * 1.3 Don't use exceptions * 1.4 Don't use Run-time Type Information * 1.5 Don't use C++ standard library features, including iostream * 1.6 Don't use namespace facility ... and many more Do you understand the Java success? I don't see what problems Ruby can solve gratefully better than Java... I only see some AOP quirks because Ruby is a script language but not very much more.
  36. I remember reading articles by people who were struggling to build OO component frameworks in the early 90's with C++. Who remembers Taligent, OpenDoc and SOM? CORBA and COM are other examples, and let's not forget 'OO' Operating System attempts like Pink. All these things failed because C++ was not OO and wasn't the right tool for the job.


    C++ was not OO º$%&/!=*????

    Saint Bjarne Stroustrup enlightenment us :)

    OK C++ is not a pure OO language but who cares??

    C++ has been a very successful language, the problems were more related to:

    1) Fragmentation: too many compilers, too many dialects, not ISO conformance, non-portable APIs (MFC vs Unix world) and of course non-portable binaries.
    2) Buggy compilers (for instance C++ exceptions), continuous ABI changes
    3) Very high requisites (in the past): a C++ program generated a bigger executable than in C, C++ was a bit slower than C, C++ exceptions were usually forbidden because the executable was bigger or some compilers didn't support exceptions...

    Java solved many of these requisites with the bytecode paradigm, the one platform for all platforms and a hard control of the JVM providers (certification etc).

    My loved FireFox, I'm using now, is a C++ beast, I can hardly imagine it developed in Java (previous attempts were failed, may be now...). Think about your office suite... more examples?

    Ruby only will be successful if it provides something more than minor language quirks.
    To be fair, I have no problem with C++, but it is not a true OO language. The problem is recognising the difference between a virtual function call and a true polymorphic message send. Java is not true OO either. The most basic concept of OO programming, namely sending messages is misunderstood by most mainstream programmers simply because few choose to question the C++ interpretation of OO that is now prevalent. Nextstep and now OSX have a better track record with OO. OSX uses a language called Objective-C. Have you ever questioned why? Paul.

  37. Nextstep and now OSX have a better track record with OO. OSX uses a language called Objective-C. Have you ever questioned why?

    Paul.
    Inheritance (NextStep is the father of OSX), Apple's culture ("only in Apple", "Apple exclusive"...), and because Objective-C does the work (the old C too).

  38. Nextstep and now OSX have a better track record with OO. OSX uses a language called Objective-C. Have you ever questioned why?

    Paul.


    Inheritance (NextStep is the father of OSX), Apple's culture ("only in Apple", "Apple exclusive"...), and because Objective-C does the work (the old C too).
    Nexstep was written in Objective-C. Objective-C chose to retain true message sends borrowed from Smalltalk. The downside is that a method invocation can take a little longer, the upside is that Objects in Objective-C are late-bound and are not tied to a specific implementation at compile time. Why is this important? * No need for component frameworks like OpenDoc, SOM, COM, Corba etc because every objects is a component by default. * No need for IoC frameworks because classes are just objects that receive the message new and create object instances * More OO semantics are possible such as true polymorphism that doesn't rely on class inheritance. Maybe this explains why Nextstep is the only C compatible OO component model to survive from the 90's, and why OSX has a cross application services option on the Apple menu and a slick, dynamic UI and MS Windows has neither. Ruby is even more like Smalltalk. In Ruby only message sends are supported and there are no hard wired function calls allowed at all; and of course Ruby as uniformity where everything is an object. This explains why Ruby can support advanced OO abstraction techniques like Mixins. My main point is that both Sun and Microsoft know all this stuff and they have known it for quite some time (say about 30 years :^)). It is for these reasons that they are now jumping onto the Ruby bandwagon (higher programming abstraction and higher developer productivity). The only people that seem to be in the dark about this stuff is the mainstream programming community who have seemingly bought the misleading OO marketing spiel pushed out by these very same vendors hook line and sinker. Paul.
  39. Paul, it would be nice if those were the reasons that Sun and Microsoft were "jumping on to Ruby", but they're not. Sun is just responding to Blogsophere hype and Microsoft has more money than God, so it'll obviously throw a few bones to something cool like Ruby. Microsoft is productizing F# and has it's own functional agenda with C# and Haskell. There was no big OO realization.
  40. Paul, it would be nice if those were the reasons that Sun and Microsoft were "jumping on to Ruby", but they're not. Sun is just responding to Blogsophere hype and Microsoft has more money than God, so it'll obviously throw a few bones to something cool like Ruby. Microsoft is productizing F# and has it's own functional agenda with C# and Haskell.

    There was no big OO realization.
    I agree there is no OO realization, because they knew it all along. Sun are responsible for Self and bought out the Strongtalk team to work on the Java JVM so they know a thing or too about OO and Smalltalk. Also like you correctly point out Microsoft are heavily into functional programming, but if you know anything about Smalltalk you would realise that a function can be an object too :^) Perhaps there was good pragmatic reasons not to build on Smalltalk and to build on C++ instead, but those reasons had to do with hardware performance, and perhaps the cost of memory. Given the speed of processors today and the amount of memory needed for C# and Java, neither of these reasons are valid today. Sun has recently sponsored a development sprint for Rubinius. Rubinius is an open source Ruby implementation that is choosing to implement Ruby on a Smalltalk inspired VM. The most advanced IDE for Ruby development today is now Netbeans from Sun. JRuby has got to 1.0 in break-neck speed and can now run Rails, also future JRuby implementations will probably borrow code from Rubinius and in so doing will be mostly implemented in Ruby and have an architecture very much like Smalltalk. Do you spot a pattern here? Paul.
  41. Do you spot a pattern here?
    The pattern is as stated before. Sun is a slave to blogosphere hype, and Microsoft will throw a few bones to anything. But if you think there's some general trend towards completely late-bound OO, then you would be wrong. If anything, it would be towards Boo or what I believe is coming in VB10 - as in static type inference and late-binding when needed. There is no pattern towards Ruby. If anything, it's not even about Ruby, but Rails.
  42. Do you spot a pattern here?
    Yes, there is a pattern, but don't confuse it with a strategy. I don't see any evidence that Microsoft or Sun are suddenly showing any Ruby or functional programming language strategy. Tim Bray likes Ruby and JRuby, so he had the two main programmers hired. Java IDE's are engaged in a cutthroat competition where any distinguishing feature helps, so it's no wonder that NetBeans and others are adding Ruby features. A Microsoft department is throwing some money behind F# because they can. Like Frank says, this pattern strikes me more as reactions to some pet projects than any company-wide strategy, and to be honest, I think Sun would be foolish to officially endorse Ruby shortly after they changed their ticker name to JAVA... -- Cedric Author "Next Generation Testing in Java"
  43. both Sun and Microsoft are jumping on to Ruby
    Microsoft dabbles in everything. Sun has been pushing hard lately to expand the languages supported by the JVM, and JRuby is a great fit. Are you sure you are not reading a tad too much into this?
    What is the lesson to be learned here? Firstly vendors will sell you what ever it is they think you will buy
    Of course. This will always be true, no matter what language or product the statement is being applied to.
    As far as OO is concerned the mainstream is mostly in the dark ages and IMHO the average Java programmer still doesn't fully appreciate what OO is all about (i.e message passing).
    Are you insinuating that the average Ruby developer appreciates what OO is all about? Or in general understands what OO better then the average Java developer. I will admit, Smalltalk developers that I have worked with know their OO in and out, but in general I find Ruby developers to be very ignorant of OO concepts.
  44. both Sun and Microsoft are jumping on to Ruby


    Microsoft dabbles in everything. Sun has been pushing hard lately to expand the languages supported by the JVM, and JRuby is a great fit.

    Are you sure you are not reading a tad too much into this?

    What is the lesson to be learned here? Firstly vendors will sell you what ever it is they think you will buy


    Of course. This will always be true, no matter what language or product the statement is being applied to.

    As far as OO is concerned the mainstream is mostly in the dark ages and IMHO the average Java programmer still doesn't fully appreciate what OO is all about (i.e message passing).


    Are you insinuating that the average Ruby developer appreciates what OO is all about? Or in general understands what OO better then the average Java developer.

    I will admit, Smalltalk developers that I have worked with know their OO in and out, but in general I find Ruby developers to be very ignorant of OO concepts.
    I don't think I am reading to much into this. I am merely stating the facts as I see it. You may be right that average Ruby developer is just as ignorant of OO as his Java counter part, but ask an old Smalltalker which language he'd rather use Ruby or Java and you'll hear Ruby every time. Puting this all down to Rails misses the point. Sun and Microsoft IMO are covering their bets because they know that a popular Smalltalk-like language is a very compelling proposition. Add to this the Lisp like features of Ruby and DSL friendliness, and Rails could be the first of many well designed, extensible OO frameworks in Ruby. AFAIK, none of the other "scripting" languages out there have Mixins (pioneered with Smalltalk), or Open Classes (again Smalltalk) or Object Memory etc. People who say why not back Groovy miss these important points. On top of this Ruby has higher order functions similar to Lisp macros - BTW Rubinius compiles to Lisp as an intermediate form on the way to byte code. Java and C# still have a role and will be around for a long time to come yet. What I am saying is that these vendors are much wiser than the average mainstream programmer (like Joe Java or Joe Ruby) when it comes to understanding the potential of Ruby, and they know a potential winner when they see one. Listen to hardcore Sun people like David Geary (JSF) or Tim Bray (XML) and you will see that Sun's move into the Ruby space is more than a passing whim. Paul.
  45. AFAIK, none of the other "scripting" languages out there have Mixins (pioneered with Smalltalk), or Open Classes (again Smalltalk) or Object Memory etc.
    Yeah, but it doesn't have type safety or annotations. When a language comes out that has these features, I'll jump on the bandwagon. My bet is that the majority of people that like Ruby (or Python for that matter) like it because of its zero-turnaround features, *NOT* because if its language ones. -- Bill Burke http://bill.burkecentral.com
  46. >My bet is that the majority of people that like Ruby (or Python for that matter) like it because of its zero-turnaround features, *NOT* because if its language ones
    Strange comment. Zero turn-around is not a language feature? Try telling that to Lisp programmers. A REPL, iterative, quick feedback approach to development is a key attraction I agree, but I disagree that it isn't a language feature. Why? Well when the cost of tracer bullets are cheap enough then you can afford to fire, aim, fire aim, fire aim until you hit the bulls eye. When each bullet is mega expensive then you need to aim, aim, aim,... fire, because the cost of re-work is prohibitive. Support for Agile development practices is a key attraction for any language I think, and is one of the reasons why VB proved so successful and popular. Back then Agile Development went under the label of RAD ofcourse. BTW if you still feel the need for manifest types even when doing TDD, then manifest type annotations can be used with a late-bound language like Ruby. The two things are orthogonal. Take a look at Strongtalk. The Strongtalk type system is much more advanced then in Java. For example it can detect things like null objects statically. And type annotations are optional so you can choose to use them or not, it is up to you. The fact that most dynamic language programmers (Python, Ruby, etc) reject the use of manifest types is telling. There was talk of (optional) manifest type annotations being added to Python and the Python community were up in arms. I guess the argument is that the costs (in terms of reduced productivity) out way the benefits. Paul.
  47. Strange comment. Zero turn-around is not a language feature?
    Ok, I should have said syntax sugar.
    The fact that most dynamic language programmers (Python, Ruby, etc) reject the use of manifest types is telling. There was talk of (optional) manifest type annotations being added to Python and the Python community were up in arms. I guess the argument is that the costs (in terms of reduced productivity) out way the benefits.
    Type safety has had an opposite effect for me. It has been a huge productivity booster. Try learning a large block of code that you did not write and have to refactor. Try figuring out large chucks of code you get donated to your OSS project. Not fun without the hints type safety gives to your IDE. I've done projects in Perl, Tcl, and Pythong, and a little in PHP. Its the zeroturnaround that I liked. The other syntax sugar they provided did not increase my productivity. The two biggest, by far, productivity boosters for me in the Java space for the past 6 years have been JBoss's hot deployment and annotations. Given the amount of things Seam and JBoss are planning, I know we can get even closer to zeroturnaround in Java. -- Bill Burke http://bill.burkecentral.com
  48. You may be right that average Ruby developer is just as ignorant of OO as his Java counter part, but ask an old Smalltalker which language he'd rather use Ruby or Java and you'll hear Ruby every time.
    So appeal to Smalltalker authority on their ideal of OO? I'd rather use CLOS-style OO.
    Puting this all down to Rails misses the point. Sun and Microsoft IMO are covering their bets because they know that a popular Smalltalk-like language is a very compelling proposition.
    No, it's the entire point. Is IronPyton and Jython covering their bets?
    Add to this the Lisp like features of Ruby and DSL friendliness, and Rails could be the first of many well designed, extensible OO frameworks in Ruby.
    Without Macros, I question Ruby's DSL friendliness - as in a real DSL, and not some method calls sans parantheses.
    AFAIK, none of the other "scripting" languages out there have Mixins (pioneered with Smalltalk),
    Aren't mixins a vendor-specific extension? I don't believe there's anything in the Smalltalk-80 spec about mixins. Smalltalk-80 is very limiting with it's single inheritance model.
    On top of this Ruby has higher order functions similar to Lisp macros
    Want to explain that one, because I fail to see a strong connection?
    What I am saying is that these vendors are much wiser than the average mainstream programmer (like Joe Java or Joe Ruby) when it comes to understanding the potential of Ruby, and they know a potential winner when they see one.
    Do we throw Python into that mix too? I don't know about Sun, but Microsoft sees much more potential in languages like F# and Haskell, than Ruby.
    Listen to hardcore Sun people like David Geary (JSF) or Tim Bray (XML) and you will see that Sun's move into the Ruby space is more than a passing whim.
    What's Gosling saying? Not that it really matters. But the Ruby Netbeans plugin does rock.
  49. You may be right that average Ruby developer is just as ignorant of OO as his Java counter part, but ask an old Smalltalker which language he'd rather use Ruby or Java and you'll hear Ruby every time.


    So appeal to Smalltalker authority on their ideal of OO? I'd rather use CLOS-style OO.

    OK... but Smaltalk's OO is meant to be simple and intuitive (simple enough for kids), I don't think you can say the same about generic functions and CLOS :^). Incidently I found Smalltalk OO much easier to get to grips with then C++, but maybe that's just a personal thing.
    Puting this all down to Rails misses the point. Sun and Microsoft IMO are covering their bets because they know that a popular Smalltalk-like language is a very compelling proposition.


    No, it's the entire point. Is IronPyton and Jython covering their bets?
    I would say yes. All these languages mimick Smalltalk to a greater or lesser degree. I haven't done much Python, but I don't see why it couldn't become the next VB too. Ruby seems to be ahead though.

    Add to this the Lisp like features of Ruby and DSL friendliness, and Rails could be the first of many well designed, extensible OO frameworks in Ruby.


    Without Macros, I question Ruby's DSL friendliness - as in a real DSL, and not some method calls sans parantheses.
    OK.. but it's not just the quirky syntax. Take a look at Rails migrations or ActiveRecord foriegn key declarations all in Ruby (:has_many).

    AFAIK, none of the other "scripting" languages out there have Mixins (pioneered with Smalltalk),


    Aren't mixins a vendor-specific extension? I don't believe there's anything in the Smalltalk-80 spec about mixins. Smalltalk-80 is very limiting with it's single inheritance model.
    True not Smalltalk-80, but a number of Smalltalk dialects have incorporated Mixins (this is where the research into Mixins was done) and something else called Traits. Matz just picked up their good work and incorporated it into Ruby.

    On top of this Ruby has higher order functions similar to Lisp macros


    Want to explain that one, because I fail to see a strong connection?
    OK. In Ruby you can use code to write code. This is how the infamous Rails scaffolding is done. There are other more useful uses however like extending the language with new control structures. This is how Rails was extended to support REST. This technique is being used to write a bunch of DSLs for Rails. Each DSL can be used to extend the Rails framework in anyway you like, through Mixins and Open Classes. Take a look at the plug-ins available for Rails and you will see what I mean.

    What I am saying is that these vendors are much wiser than the average mainstream programmer (like Joe Java or Joe Ruby) when it comes to understanding the potential of Ruby, and they know a potential winner when they see one.


    Do we throw Python into that mix too? I don't know about Sun, but Microsoft sees much more potential in languages like F# and Haskell, than Ruby.

    You've got a point, both these companies seem to be multi-headed beasts and they both appear to be following a number of strategies at once. I don't think this is strange for large corporations. I guess they are covering all bets (either by design or just through poor coordination :^)). Sun do seem to be focusing on Ruby more then the other potential winners from what I've read.
    Listen to hardcore Sun people like David Geary (JSF) or Tim Bray (XML) and you will see that Sun's move into the Ruby space is more than a passing whim.


    What's Gosling saying? Not that it really matters. But the Ruby Netbeans plugin does rock.
    Not sure about Gosling.. I don't think he is a fan of Ruby :^)... but he did admit a while ago that perhaps constraining Java to just a few programming concepts wasn't such a good idea in the long run. It will be interesting to see how Sun manages to incorporate Closures in Java 1.7. Paul.
  50. What I am saying is that these vendors are much wiser than the average mainstream programmer (like Joe Java or Joe Ruby) when it comes to understanding the potential of Ruby, and they know a potential winner when they see one.
    You can't have it both ways. Your views insinuate that anytime a vendor pushes a language other then Ruby they are misleading the masses or pursuing a technology only for the purpose of selling it to the misinformed consumer. But when it comes to pursuing Ruby the vendors are considerably wiser. I do agree with you that Microsoft and Sun are covering their bets, same as they way they covered their bets with Python.
    Putting this all down to Rails misses the point.
    since you brought it up, I think that Ruby would still be "in the closet" if it were not for Rails.
  51. What I am saying is that these vendors are much wiser than the average mainstream programmer (like Joe Java or Joe Ruby) when it comes to understanding the potential of Ruby, and they know a potential winner when they see one.


    You can't have it both ways. Your views insinuate that anytime a vendor pushes a language other then Ruby they are misleading the masses or pursuing a technology only for the purpose of selling it to the misinformed consumer. But when it comes to pursuing Ruby the vendors are considerably wiser.
    Hi Matt, I just wanted to spell this out in case you missed my point. Sun and Microsoft are aware that a popular Smalltalk-like language could gain significant market/brain share. I think they see this as a potential threat to the current encumbent technology base (Java/J2EE and C#/.Net) and hence to themselves. As such, they want to ensure that they have a signifcant stake in "what ever comes next". From their perspective this is just sound business sense. I'm sure that both Microsoft or Sun would love to "own" mainstream software development by having everyone use C# or Java, but with the rise in popularity of open source languages I think they both realise that this now unlikely. In addition to this as pointed out by Frank and Cedric, these corporations don't speak with a single voice. Some within these organisations have wanted to promote alternative languages for years. IMO it has been the business/marketing sides of these companies that have put out the "golden hammer" message when it comes to their own "proprietary" programming languages, and have chosen to promte an interpretation of OO that places their languages in a favorable light. I don't blame them for this, after all they are in business to make money for their shareholders. I just wanted to draw attention to how we the developer community have done a poor job of maintaing any semblance of control over the types of tools we are obliged to use on a daily basis. Paul.
  52. Take a look at easygui for Python http://www.ferg.org/easygui/ Just with 1 line of code you can create a complete dialog with a list and an input. It is based on Tkinter the Tk port for Python but it is possible to make this with Python. For Ruby I was searching something similar but I don't find it yet but it is possbile to create it for Ruby with the Fox ruby toolkit. With Python or Ruby everything is possbile. Very easy languages to work with. I imagine what can also do with JRuby or Jython to create a complete Swing JFrame with toolbar and status bar and menubar in a single line of code it is very posible and easy I think.
  53. Just a question[ Go to top ]

    Maybe a bit off topic... but why the h*ll do we still create our high-level languages imperative-style? I mean, imperative-style object-oriented languages (like Java) are good for writing standardized middleware where the spec is fairly set and it's all about building a fast and robust implementation. But these are high-level, buiness logic oriented languages we're talking about, to be used in scenarios where specs change constantly and we only want to express our application specific stuff as fast as possible. How about a "bastardized" functional-style language with a touch of predicate logic, like a mix of Scheme and Prolog, where 100 lines of code could easily replace thousands of lines of Ruby-and-the-likes...? And no: I'm not talking about adding closures to an otherwise plain old imperative-style object-oriented language. While closures are certainly nice, they don't actually improve the way software is written as long as the old "object-with-fields-and-methods under a regime of explicit state manipulation" serves as the fundamental building block. Thoughts and suggestions...?
  54. funny, I am porting a VB app to Java as we speak, VB and its IDE stink from miles away
  55. funny, I am porting a VB app to Java as we speak, VB and its IDE stink from miles away
    I agree. I have years of experience with VB (MCP too). And it is great for "hello world" apps. But for complex, large and good looking apps, not so much. Even in its day, Delphi (from what I hear) was much better.
  56. funny, I am porting a VB app to Java as we speak, VB and its IDE stink from miles away

    I agree. I have years of experience with VB (MCP too). And it is great for "hello world" apps. But for complex, large and good looking apps, not so much. Even in its day, Delphi (from what I hear) was much better.
    it is. Delphi is a great environment for Windows centric client/server style solutions. I'm not too fond of the webapp building they now offer, but that's probably because I'm used to handcrafting JSPs and don't like writing Pascal (or Java) code that builds html code and spits it out.
  57. funny, I am porting a VB app to Java as we speak, VB and its IDE stink from miles away

    I agree. I have years of experience with VB (MCP too). And it is great for "hello world" apps. But for complex, large and good looking apps, not so much. Even in its day, Delphi (from what I hear) was much better.


    it is. Delphi is a great environment for Windows centric client/server style solutions.
    I'm not too fond of the webapp building they now offer, but that's probably because I'm used to handcrafting JSPs and don't like writing Pascal (or Java) code that builds html code and spits it out.
    I had different experiences with VB. You'll have to define "large" and "complex", but I built decent sized applications in the mid-90s. They weren't ugly either. No, not as sexy as some of the Flash sites you see nowadays, but way more sexy than what I could do, by myself, with a web app. -- Bill Burke http://bill.burkecentral.com
  58. funny, I am porting a VB app to Java as we speak, VB and its IDE stink from miles away

    I agree. I have years of experience with VB (MCP too). And it is great for "hello world" apps. But for complex, large and good looking apps, not so much. Even in its day, Delphi (from what I hear) was much better.


    it is. Delphi is a great environment for Windows centric client/server style solutions.
    I'm not too fond of the webapp building they now offer, but that's probably because I'm used to handcrafting JSPs and don't like writing Pascal (or Java) code that builds html code and spits it out.


    I had different experiences with VB. You'll have to define "large" and "complex", but I built decent sized applications in the mid-90s. They weren't ugly either. No, not as sexy as some of the Flash sites you see nowadays, but way more sexy than what I could do, by myself, with a web app.

    --
    Bill Burke
    http://bill.burkecentral.com
    Bill, I agree with the VB vs Web app. I was commenting on the "VB makes it easy to create apps and make them nice looking". One of the biggest pains was no auto-resizing. The other was resorting to windows APIs to do alot of things. As for easy - A form can't be a regular form and an MDI child. So you had to resort to UserControls. Yuck. In Swing - JPanel - easy. The syntax is a pain (even in VB.Net it still does very Un-OO things). As for large/complex applications, there is no "Find all references". No refactoring. There are no packages so everything was in one folder. Case Insensitivity. I could go on.