Crap and Double Crap

Post #193,110 by tuberculosis 2/5/05 12:00:27 AM Reply	Crap and Double Crap "Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein "This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
Post #193,136 by johnu 2/5/05 10:12:02 AM Reply	Interesting thing is... My boss's boss is a former Smalltalk developer. He keeps asking me if there is a viable Smalltalk we could use. We need to be able to develop up to date Windows UIs that can be embedded in a PowerBuilder window and we can't have a license that requires us to pay a percent of our earnings (i.e. Cincom). I've found nothing. Any ideas?
Post #193,140 by folkert 2/5/05 10:31:49 AM Reply	Umm... Squeak? -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* [link\|http://it.slashdot.org/comments.pl?sid=134485&cid=11233230\|"Microsoft Security" is an even better oxymoron than "Miltary Intelligence"] No matter how much Microsoft supporters whine about how Linux and other operating systems have just as many bugs as their operating systems do, the bottom line is that the serious, gut-wrenching problems happen on Windows, not on Linux, not on Mac OS. -- [link\|http://www.eweek.com/article2/0,1759,1622086,00.asp\|source]
Post #193,160 by altmann 2/5/05 4:13:54 PM Reply	Re: Umm... "up to date Windows UIs" -- Chris Altmann
Post #193,189 by tuberculosis 2/6/05 12:02:26 AM Reply	Looked at Dolphin? What I know about Windows you could stick through the eye of a needle but I think that [link\|http://www.object-arts.com/DolphinSmalltalk.htm\|Dolphin] is aimed at Windows (uses native widget set). There's also [link\|http://www.objectconnect.com\|Smalltalk MT] You could check out IBM's[link\|http://www-306.ibm.com/software/awdtools/smalltalk/\|Visual Age Smalltalk]. Or, since MS claims you can host other languages on top of MSIL, there is [link\|http://www.smallscript.com/\|Smallscript/S#]. Its not a true smalltalk but it has some of the benefits. [link\|http://www.instantiations.com/sts/links.htm\|http://www.instantia...com/sts/links.htm] is worth a look. You can always approach Cincom if the license is a problem - they can be quite flexible these days (not like when PARCPlace had it). The hosting in a PowerBuilder window bit - that's a bit weird though. I don't know if any of them can do that kind of integration. "Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein "This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
Post #193,192 by ben_tilly 2/6/05 1:21:06 AM Reply	Going farther afield Look at Ruby. It shares some features of Smalltalk (notably its object model), can be used with up to date windows widgets, is open source, and if there isn't a way to plug into Powerbuilder, you might be able to add that. There are major differences as well, but some of those may work to your benefit. For instance the syntax is more C-like, and it is file-based. Both of those make it easier for mainstream developers to come up to speed with it. Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #193,657 by tuberculosis 2/8/05 1:28:51 PM Reply	You lose a lot of power though Avi talks about this on his blog this week. [link\|http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3284695382\|http://www.cincomsma...&entry=3284695382] The Ruby distribution comes with a large amount of C code implementing the underlying language and library semantics: a parser, an interpreter, regular expressions, arrays, hash tables, a numeric tower, and so on. In some cases, like the parser, this code is kept hidden from the Ruby layer: there's no way with a stock Ruby interpreter to get at a Ruby parse tree from Ruby code. This makes certain tools much harder to write - the RDoc documentation generator, for example, has to include its own lexer because it can't access the one that comes with Ruby. It also makes the language much harder to extend, since any change to the way the parser works has to be done in C, and any code that relied on these changes wouldn't run on anybody else's Ruby installation. ... This may sound like an academic quibble, like a desire for purity for its own sake, but the fact is that the tools available on a Smalltalk system, like the Refactoring Browser, the Debugger (which takes "edit-and-continue" farther than many people can imagine), the various inspectors and explorers and profilers are much, much better than those available for the "scripting" languages like Ruby. I would argue that a large part of the reason for this is the open, accessible, and extensible nature of the system: nobody wants to write those tools in C, and in Smalltalk, you don't have to. Note that I'm necessarily talking about implementations here, not language specs: clearly in JRuby, the implementation is in Java instead of C, and clearly you could implement the Ruby language with a Smalltalk-style VM (hopefully one with a Smalltalk-style JIT as well, which would bring a 20x or so speed increase to the current Ruby interpreter). But really what I'm talking about is a philosophical difference, not a technical one: to Smalltalkers, it's essential that as much of a system as possible be implemented in Smalltalk, whereas this simply isn't a priority for the scripting language community, and it's the priorities rather than the individual implementations that draw me to Smalltalk. "Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein "This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
Post #193,746 by JimWeirich 2/8/05 11:08:43 PM Reply	Re: You lose a lot of power though Quoting Avi: there's no way with a stock Ruby interpreter to get at a Ruby parse tree from Ruby code. Using a stock Ruby interpreter and the ParseTree library (downloaded and installed with the single command "gem install ParseTree"), I can do this ... require 'parse_tree'\nclass Example\n def example(arg1)\n return "Blah: " + arg1.to_s\n end\nend\np ParseTree.new.parse_tree_for_method(Example, "example")\n With the output (slightly formatted): [:defn, :example, \n [:scope, \n [:block, [:args, :arg1], \n [:return, \n [:call, [:str, "Blah: "], \n :+, \n [:array, [:call, [:lvar, :arg1], :to_s]]]]]]] The above is pretty cutting edge stuff coming from Ryan Davis. Ryan is building a compiler that will take a simplified version of Ruby and compile it directly to C. The goal is to do something pretty close to what Squeak does with its implementation language. Combine this with the MetaRuby project and you get pretty close to what Avi is talking about. We're not there yet, but I definitely see movement in that direction. Again quoting Avi: the Refactoring Browser, the Debugger [...], the various inspectors and explorers and profilers [...] nobody wants to write those tools in C I'm not sure why he thinks C is required for those projects. One of my first projects in Ruby was a simple class browser, Rails has an embedded interactive debugger where you can communicate with your web deployed code, all in just plain Ruby. And now that Ryan has made it easy to reify the Ruby parse information, a refactoring browser becomes a real possibility. Grant, none of this stuff is comparable to what Smalltalk offers now, but I think real reason the two language cultures are so different is not because of the need for C, but because Smalltalk is image based and Ruby is not. -- -- Jim Weirich jim@weirichhouse.org [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #193,781 by tuberculosis 2/9/05 12:48:20 PM Reply	Is the parser written in Ruby? Just curious. It does sound like Ruby is headed in the right direction in terms of having more and more of itself written in itself. "Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein "This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
Post #193,808 by mmoffitt 2/9/05 2:26:55 PM Reply	Just like C# and .Net </runs for cover> bcnu, Mikem Eine Leute. Eine Welt. Ein F\ufffdhrer. (Just trying to be accepted in the New America)
Post #193,831 by JimWeirich 2/9/05 5:55:31 PM Reply	Re: Is the parser written in Ruby? Ryan's ParseTree library uses the current Ruby interpreter parser that is written in C. In fact, he doesn't actually parse the data, but just pulls out the parse tree that Ruby has already parsed. It just reifies that parse data as as Ruby objects so they can be accessed and processed by Ruby code. This is enough to do refactoring browser type of stuff. Not enough to play syntax god with the language itself. I believe that Ruby 2.0 will have a full Ruby invocable parser (but I'm don't know how much will be C code and how much will be Ruby code). AFAICT, Matz himself is not too interested in the MetaRuby stuff, but he has always been willing to "take what works well" and incorporate it into Ruby. I'm hoping that Ryan's work will eventually make it into the core. Ryan's goal is to be able to write the Ruby libraries (and perhaps the VM) in a simple subset of Ruby that can easily be compiled to C code. My understanding is this is that same approach Squeak uses. Ryan has some great examples where he dynamically grabs a method object and calls both "to_c" (producing C code) and "to_ruby" (reproducing the original ruby source ... sans comments). It's pretty cool. -- -- Jim Weirich jim@weirichhouse.org [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Welcome to IWETHEY!