Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Software

#Smalltalk - Open Source Smalltalk for .NET 27

Posted by timothy from the cognitive-dissonance dept.
David Buck writes "John Brant and Don Roberts have released an Open Source Smalltalk compiler and library for .NET called #Smalltalk. This is the first widely available Smalltalk for the .NET platform. #Smalltalk is ANSI compliant and programs written in it compile to DLL's or Windows executables. The compiler is still early in its development, but it looks interesting." (You may recall this earlier mention as well.)
This discussion has been archived. No new comments can be posted.

#Smalltalk - Open Source Smalltalk for .NET More

#Smalltalk - Open Source Smalltalk for .NET

Comments Filter:

  • First Mention (Score:5, Informative)

    by refactoringdr ( 163991 ) on Tuesday April 22, 2003 @08:14PM (#5785922)
    Actually, the previous mention was for our competitor's language, S#. Our's is #Smalltalk.

    Don Roberts
    roberts@refactory.com
    The Simplest Consultant That Could Possibly Work
  • Whoops- at first I thought this was for the #Smalltalk channel over at irc2.parcplace.net. :)

    Since it looks like Don is reading this thread, I'll go ahead and ask here-

    1. What are the chances we'll see this running on Mono or dotGNU? Or on WinCE using the WinCE .NET runtime?

    I'm running OS X myself, with a Dell Axim and a Sharp Zaurus for the development and testing of Dynapad (a PDA OE in Squeak Smalltalk), and I'd love to be able to develop in Smalltalk using .NET for the Axim and using Mono for both my iBook and Zaurus!

    2. How much different is this from the regular Smalltalk we all know and love? Does it come with a Smalltalk IDE like we see in Squeak, St-80 or VW, or do you develop #Smalltalk code in VisualStudio? Even though it is compiled to a DLL, can you do all the great runtime tricks Smalltalk is known for?

    Can I still develop using the traditional image method and then compile when I want to deploy?

    3. How does this differ from #S or SmallScript?

    I will be trying this as soon as I can tommorow at work, where my only Windows machine is. I have a lot of hope for .NET, and think that version of Smalltalk for .NET could be a very wonderful thing, as long as it doesn't sacrifice some of Smalltalk's better features to run on the .NET runtime.

    Thanks to the #Smalltalk team for an awesome contribution!

    (rev in #squeak on irc.freenode.net and irc2.parcplace.net)

    • Re:General #Smalltalk Questions; #Smalltalk and Mo (Score:4, Informative)

      by refactoringdr ( 163991 ) on Tuesday April 22, 2003 @08:34PM (#5786028)
      1. That's up to the Mono or dotGNU people. We use the Reflection API A LOT and the current implementation on those platforms isn't quite up to snuff.

      2. This differs almost none. We love smalltalk tried to recreate the experience as much as possible. It does not currently come with an IDE (that's the next step). We've been using other Smalltalk's to edit the applications that we then export as .sif files and then compile. (Heck...people have been bugging us for years to make the RB more like emacs...they got their wish :) ). You can debug it using the standard CLRDBG program from M$. This gives you single stepping, inspecting, and even code evaluation (as long as you express the code in C#'esque syntax). You can override DNU and it works. I don't think that you can do all the really ugly tricks that ST'ers abuse.

      3. It differs from S# (same thing as SmallScript since Dave took the name) in the following ways. 1) As true as possible to st80 2) Open Source 3) Free (as in beer)

      The beauty of it all is that you can program in real, honest to goodness Smalltalk, and when you decide you need to call other .NET objects, you can still use ST syntax. For example, to use the .NET MessageBox class, in C# you would write System.Windows.Forms.MessageBox.Show("Hello World"); in #Smalltalk you write System.Windows.Forms.MessageBox Show: 'Hello World'.

      Thanks and Enjoy

      don
      • Thanks for the reply!

        1. What about the .NET mobile runtime for WinCE 3 and 4? I suppose it is up to how much is or isn't supported/provided in the WinCE .NET runtime, but it'd be great to have that combo!

        2/3. that is really good to hear! It sounds like SmallScript diverges quite a bit from regular Smalltalk in that it adds a bunch of new syntax and looses some other Smalltalk features to work better with the .NET runtime.

        Your last paragraph is exactly why I'm interested in real Smalltalk running on .NE
        • To be fair...we implement most of the Smalltalk collections by wrapping a smalltalk object around a .NET object. But we aren't a Smalltalk->C# translator, we generate "native" msil :).

          don
          • Naturally #Smalltalk is a wrapper around the .NET object system- and I didn't say to imply that SmallScript or other languages on .NET merely compile/convert to C#. However, I meant that some .NET implementations merely take the syntax of the language in question and one-to-one it with the regular .NET API. In Smalltalk, with a library many of us are quite used to that would suck. For something like a C.NET, that'd be fine. However, I've seen lisp implementations where you have a very-very barebones reg
            • The first keyword is the original .Net method name. Additional keywords can be anything you want. For example, WebClient in .net has a method named DownloadFile that takes the url and the filename to download to. In C# you would say webclient.DownloadFile("http://slashdot.org","foo . txt"). The equivalent call in #Smalltalk is webclient DownloadFile: 'http://slashdot.org' to: 'foo.txt'. The to: keyword is arbitrary, I could have called it foo: and the call would still work so long as the first keyword was
  • i *love* smalltalk! Having a .net implementation (or two!) should help the visibility (and my consulting fees :).

    I assume it will work on FreeBSD/rotor?

    • Re:sweet! (Score:2, Informative)

      by refactoringdr ( 163991 )
      I believe that it's been tested on rotor and doesn't quite work. Rumor is that the Reflection API isn't quite up to snuff. Feel free to experiment with it and help us get it working on that platform too.

      don
  • I know that Objective-C is derived from SmallTalk (or is otherwise closely related). Could these SmallTalk-on-CLR projects be leveraged to bring Objective-C to the CLR?

    I haven't done much programming in either Cocoa or .NET, but the more cross-platform APIs and languages (especially open ones), the better.

    -Ster

    • I know that Objective-C is derived from SmallTalk

      I wouldn't go as far as saying that Objective-C is "derived" from SmallTalk, but it was heavily influenced by it. The additional syntax that was added to C in order that it could become an OO language is very similar to SmallTalk. As to whether efforts to bring SmallTalk to the .NET platform could benefit Objective-C, I doubt it. The Objective-C runtime is completely different from a SmallTalk implementation.

      Chris

  • .NET has no support for non-local returns so #Smalltalk uses exceptions to simulate non-local returns.
    Hmmm. Would it not be better to convert the blocks to auto-name-generated subroutines. Using exceptions to generate non-local returns will certainly make it fun to debug under VS.NET or something, if you can't tell what's really an exception and what isn't.
    • Seems like there'd be a sigificant performance hit too...
    • Actually, jscript.net manages to do non-local code blocks:

      var answer2 = function(q) {return (-q); }(-42);
      print(answer2);

      Save to anonf.js. Compile from command line with jsc anonf.js, then run anonf.exe. Prints "42".

      A quick look at the ILDASM output suggests it's compiling the anonymous block on the fly using the Microsoft.JScript.FunctionExpression class.

  • Am I mistaken in thinking that #Smalltalk is not totally portable to platforms that are not microsoft variants because of the mention on the site that it produces dll's? I use Squeak now and have not been terribly interested in all the mutated # language variants being created to work with microsoft .NET. The mention of .dll and the statement that (paraphrased) "you can use the microsoft dbgclr debugger to debug" make it sound tied to the microsoft platform to me, while Squeak runs on all kinds of platfor
    • #Smalltalk should run on any MS-compatible .NET implementation. (which right now is exactly 1). It generates .EXE files, which can run on any .NET platform (if it is compatible). Under windoze it can also generate .DLL's, but doesn't have to.

      We see #Smalltalk and Squeak as alternatives. #Smalltalk exists because 1) We always wanted to write our own st 2) .NET provided a VM, garbage collector, class library, GUI and all the nastyness that we weren't interested in but makes a system useful 3) We've done our
      • Under windoze it can also generate .DLL's, but doesn't have to.

        The DLLs that it generates are not DLLs in the traditional Windows sense, but they are .NET assemblies meaning that any .NET platform can use them. DLL is a bit of a misnomer, but it's the standard the MS has adopted for naming assemblies.

        --Riley

    • I think that maybe you are not completely clear about this project. #Smalltalk runs on one particular MS platform: the Common Language Runtime. Currently, the only full CLR comes with the MS .NET Framework for Windows. Rotor (http://msdn.microsoft.com) is a CLR implementation that runs on BSD and Mac OS X, but it is not a complete implementation, and #Smalltalk will not currently compile programs on Rotor.

      Interestingly enough, programs that have been compiled with #Smalltalk on MS .NET Framework 1.0.370

  • my question (Score:2, Interesting)

    by Anonymous Coward
    It looks some of the #smalltalk developers are following the thread, so I'm hoping my question will be answered. This question isn't meant to be a troll, so if you don't agree with it, don't mod it down. My question to the #smalltalk developers is this.

    I've been dealing with multi-threading in C# for .NET lately and encountered some serious issues. The situation is this. While looking at the threading API in C#, I discovered that ThreadPool is limited to 25 threads. That in itself isn't necessarily a probl

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close