Slashdot Mirror


#Smalltalk - Open Source Smalltalk for .NET

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.)

27 comments

  1. First Mention by refactoringdr · · Score: 5, Informative

    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

  2. General #Smalltalk Questions; #Smalltalk and Mono by RevAaron · · Score: 2, Interesting

    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)

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  3. Re:General #Smalltalk Questions; #Smalltalk and Mo by refactoringdr · · Score: 4, Informative

    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

  4. sweet! by larry+bagina · · Score: 1
    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?

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

    1. Re:sweet! by refactoringdr · · Score: 2, Informative

      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

  5. Re:General #Smalltalk Questions; #Smalltalk and Mo by RevAaron · · Score: 1

    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 .NET- I'd love to have access to pretty much every library for Windows, but do it all using Smalltalk, to never have to soil myself with an inferior language. :P Some .NET implementations just seem to be a syntax wrapper around C#, but #Smalltalk sounds more like my thing. :)

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  6. Re:General #Smalltalk Questions; #Smalltalk and Mo by refactoringdr · · Score: 3, Informative

    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

  7. Objective-C? by Ster · · Score: 1

    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

    1. Re:Objective-C? by LizardKing · · Score: 1

      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

  8. Re:General #Smalltalk Questions; #Smalltalk and Mo by RevAaron · · Score: 1

    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 regular lisp library, and then have to use .NET like so:

    (call some-dotnet-object "myMethod" 1 "hello" 42.3)

    without even wrapping it all around a Scheme or CL library. Poor example perhaps, but I am just singing praise all the same. :)

    How does #Smalltalk deal with method names? That is, let's say you have a method called addTwoThenRaise(int x, int y) that would do, in Smalltalk [ :x :y | (x + 2) raisedTo: y ]. In Smalltalk, we'd name that method like MyClass>>#addTwo:thenRaise:. In #Smalltalk would one call a method defined in C# as addTwoThenRaise(int x, int y) like obj addTwoThenRaise: #(10 22) ?

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  9. Re:General #Smalltalk Questions; #Smalltalk and Mo by refactoringdr · · Score: 3, Informative

    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 DownloadFile. Contructors are similar 0-arg constructors are invoke by the "new" message (as you would expect). Multiple arg constructors are called by adding more (arbitrary keywords). For example, to create a .NET point: System.Drawing.Point new: 3 y: 5.

    hope this helps.

    don

  10. Re:General #Smalltalk Questions; #Smalltalk and Mo by RevAaron · · Score: 1

    Hrmm, definately an interesting way of doing it- with arbitrary keywords. Huh, whodathunk. :) But yes, it helps quite a bit, just what I was wondering. Thanks again!

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  11. Lots of reasons why I want .NET to fail by Anonymous Coward · · Score: 0

    This note was originally published at John Munsch weblog on January the 14th.

    Lots of reasons why I want .NET to fail and fail badly

    It's benefits a criminal organization. Not one that's been found guilty of crimes once or maybe twice, but lots and lots of times. Those crimes are many and varied, but here's just a few of them: Stac Electronics v. Microsoft, DOJ v. Microsoft, Sun v. Microsoft.
    P.S. If you want to split hairs, Stac v. Microsoft isn't a criminal action, it's doesn't stem from a criminal abuse of their monopoly like the other two cases. Instead it was just a case of a small company being driven out of business by willful patent infringement, theft of trade secrets, etc.

    Microsoft isn't just one thing anymore. It's too damn big for that. I'm sure even Bill himself knows better than to think that he truly controls the whole ship because it's become big enough that he can't possibly know all the projects, people, etc. anymore. But even a really large company still has a kind of collective personality that it exudes and a large part of the personality both internal and external to Microsoft for many years now is that of a total control freak.
    If they don't own it, if they don't control it, if they didn't create it, if it doesn't have a broad stamp from Microsoft on it, then they don't want it. Sometimes it's sufficient for the thing to merely exist and they'll refuse to acknowledge it, other times they need to actively stamp it out because they can't control it.

    When was the last time you can remember Microsoft saying they supported a standard? That is, not something they invented and submitted a RFC for, an actual, take it off the shelf and re-implement it without renaming it or "improving" it so it doesn't work with anybody else standard. C++? Basic? HTML? A video or audio codec? Java? Anything?

    I'm sure there's something, somebody will point out their excellent support for TCP/IP or something and I'm sure that's true. But if you were to look at Microsoft as a person in your life, you'd wonder what was wrong with him or her such that so much had to be controlled by that person.

    When your business is selling the operating systems that 90+% of everybody uses, software development tools should not be a profit center.
    Why should I have to plunk down a couple of thousand dollars for a "universal subscription" in order to have access to compilers and basic development information? Sun doesn't have to do that? On this point I'll quote from the .NET "rebuttal" that I linked to above, "For non-profit use VS.NET can be had pretty cheaply, especially if you know anyone that is in college somewhere." Pretty cheaply? For a non-profit (that means charities, churches, universities, the hobbiest who is going to give away his work for FREE)... pretty cheaply? Wow. That is well and truly pathetic. To try and justify it, and say, oh well, you can try to scam an educational discount so it won't be so dear, is even more pathetic.

    Marketing. Have you been "lucky" enough to catch one of the .NET commercials with William H. Gacy telling you how great it is without really ever telling you anything about it? Microsoft doesn't trust .NET to stand on its own technical merits and it knows it may go like cod-liver oil down the gullets of a lot of people who have seen how the company works behind closed doors even if it were the tech shiznit.
    So they are going to pull a page out of Intel's bum-bum-buh-bum "Intel Inside" playbook and try to sell the brand like it's sneakers and cola. Trust us, you'll look cool if you use it, and we'll keep hammering the brand on TV so somebody who doesn't have much tech savvy in your organization will ask you if you are using it, or have plans to port to it, or whatever, even if he hasn't got a clue what "it" is in this case.

    They don't trust you. They don't like what they can't control and they can't control you. They can try and they always will keep trying but

    1. Re:Lots of reasons why I want .NET to fail by Anonymous Coward · · Score: 0

      Why should I have to plunk down a couple of thousand dollars for a "universal subscription" in order to have access to compilers and basic development information?

      The SDK including compilers is available for free download - the Visual Studio .NET IDE is quite expensive but surely an expert linux user like you is happy with just emacs.

    2. Re:Lots of reasons why I want .NET to fail by Schnapple · · Score: 2, Insightful
      Not to mention the fact that the entire MSDN library is available for free at http://msdn.microsoft.com/.

      But what am I saying? This is the exact same trolling comment that gets posted wherever and whenever something, anything .NET gets posted. Probably even the same troll.

      My guess is either
      a) It's someone who hates Microsoft so very much that it wouldn't matter if Bill Gates cured Cancer and AIDS tommorow, he'd still be the antichrist
      b) It's someone who has never used anything .NET in his life and doesn't get what it is.
      c) It's someone who has been advocating "non-MS solution X" for years now and is frustrated at the fact that no one's listened yet
      d) It's the same "*BSD is Dying" guy
      e) CowboyNeal

      If you want my explanation on what .NET is, check my URL below.

  12. Non-local returns by Burb · · Score: 1
    .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.
    --

    1. Re:Non-local returns by boatboy · · Score: 1

      Seems like there'd be a sigificant performance hit too...

    2. Re:Non-local returns by Burb · · Score: 1
      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.

      --

  13. Curious by gsarff · · Score: 1

    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 platforms and is full featured now. I realize #Smalltalk is a work in progress and therefore comparing current 'features' and class libraries are not only irrelevant but also illogical at this time since it is still being worked on, but I am wondering, could not classes be made for Squeak to at least let it communicate with remote .NET objects/services? If my question above about #Smalltalk being, in some sense, tied to a compatible microsoft underlayment, what would be the advantages compared to Squeak which runs on tons of things? If I am mistaken about #Smalltalk, then I respectfully withdraw the question. I'm just curious, since I've been using Squeak and XML and SOAP etc. to do, hmm, "similar" network/services things that .NET was designed for.
    Just FYI, I'm a bit of an "oldster", having used punched cards, and languages many youngsters :) may not have even heard of, algol, snobol, PL/I, and as far as I am concerned, the "language wars" are over and were childish when they were going on. Do you see #Smalltalk and Squeak as alternatives, competitors, two sides of the same coin, satisfying different niches, essentially the same and up to personal choice, or what?
    Also, I saw on the #Smalltalk website, on one of the pages, Compiler perhaps, an example of 1 to: 1000 do: [ ] and mention of how in smalltalk we would get 1000 smalltalk objects, which it was said, were not really needed and so the objects would be done away with and you would just use 32-bit integers instead. I presume this is done transparently and backward compatible such that, for example, if the index spilled over into large integers, ( > 32 bits) things would still behave the way the would in other smalltalks such as Squeak. That is, an internal optimization, but if I wanted the object, I would get an object, and not something else?
    Thanks. It looks like you guys put in a lot of hard work on #Smalltalk and I will watch it with interest.

    1. Re:Curious by refactoringdr · · Score: 1

      #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 share of VB programming (don't laugh) and there's a lot of things that are easy in VB that are harder in other languages. .NET captures a lot of that flavor. 4) It's done by MS, so like it or not, it will probably become the next de facto standard that is shoved down everyone's throats 5) We might get consulting work writing .NET programs but doing in a language that doesn't suck.

      As for the optimization mentioned on the web page...we would envision it working like the current smalltalks (failing over to LargeIntegers). Right now we create full-blown boxed integers for each iteration (not even a tagged representation), and are pretty happy with the performance despite having to create 1000 "real" objects.

      Hope this answers your questions.

      don

    2. Re:Curious by iamriley · · Score: 1
      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

      --

      If you can read this, then I forgot to check "Post Anonymously".

    3. Re:Curious by iamriley · · Score: 1

      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.3705 will run on rotor; that is, if you compile the Calculator.sif example with #Smalltalk to produce Calculator.exe, you can run Calculator.exe on Rotor.

      Mono (http://go-mono.org) is not complete enough to even run the compiled executables. It pops up a message that says (going from memory here, so don't quote me) "EXECUTION SHOULD NOT REACH THIS POINT", whatever that means...

      With your comment about the multi-platform capabilities of Squeak, you are correct. Squeak can run on many more platforms than #Smalltalk. I'll just reiterate that #Smalltalk runs on exactly one platform, which just happens to be a virtual platform. The real advantage is interoperability with the many languages that compile to the CLR. #Smalltalk can use objects defined in any .NET assembly (called a DLL, but much more thatn a simple dynamic link library). If you are, for example, doing contract work for a company that uses .NET languages, you can program your stuff in #Smalltalk and use their classes without worrying about interoperability.

      As for your question about communicating with remote .NET objects/services, all of that communication is done using XML/SOAP, so you can theoretically communicate with these services using telnet if you're really feeling up to it.

      --Riley

      --

      If you can read this, then I forgot to check "Post Anonymously".

  14. Re:General #Smalltalk Questions; #Smalltalk and Mo by refactoringdr · · Score: 1

    Miguel,
    It turns out that your reflection might be beautiful. The actual problem is in the Mono VM. Go to the #Smalltalk download page where we have the details and a dump from the error.

    don

    P.S. You do good work. It's stupid that your post got modded down

  15. perhaps you have misread... by Anonymous Coward · · Score: 0

    ..just a thought, but maybe you have misread or misconstrued a lot (not all but a lot) of the anti microsoft and what you see as anti corporate posts on slashdot. What I see more, and I agree with, is that people are anti unethical behavior and criminality, and anti what happens once any entity has a lot of power with little or no check to what they do with that power.

    The obvious example, following the main thread focus, on microsft, where millions of people have noted that they did, in fact, abuse their position, that they got to a dominate position via some pretty questionable means, and that their security models combined with this position have put people in the "pretty much stuck" position of spending a lot of money to be abused on an ongoing basis. yes, I am aware of "don't use their stuff", well, this has been answerd over and over again by noting it's pretty hard to not be affected by "their stuff" whether you use it or not, especially if your clients and cuistomers are still using it. Catch 22 there, so we will get past that sticking point, it's been answered. We all use the net, and all of us are affected when a significant size hole appears and gets exploited, and once a pattern of many years time and of noting exactly where those holes appear and exactly who is responsible for them and how much money they continue to make by this inclusion into the internet world of this swiss cheese approach to expensive software, well.... I mean, really.... the sky IS really blue.

    As to "corporations", recent revelations over the past couple of years have proven there is a lot of outright lying, obfuscation of finances, over hyping to small investors to shill up stocks worth to absurd and reckless levels-fraud in other words, and so on. It's not a true black and white issue, it's more a pick an example (examples again, say microsoft, enron, etc) and point out data and take it from there, normal empirical analysis. the gestalt is, there sure is a lot of criminality going on, and people are beginning to wonder exactly how widespread this is, after example after example comes to light. It's endemic, and probably epidemic, if you would allow a small amount of anthromorphism to be used to describe it..

    Of course this can be called bashing, but to millions of people it's "bashing" based on the reality of an obvious need to bash. Blaming the victims for a crime committed against them is not considered to be an intellectually viable form of expression that is valid, at least not amongst rational civilized people.

    Now for me, a regular old 'murican capitalist, and a proponent of self-reliance and independence, and ALSO a proponent of above board rational and ethical business behavior, there are some corps I think do a good job, and others I can see as being..well.. crooks is the word. Serious crooks, crooks who not only need some fines, but some jail time. Want an example? any of the corporations who sold weapons of mass destruction materials to saddam back in the 80's, when he was obviously using them in warfare. any of those corpos officers, chucked in the pokey. the corporations dissolved. Well now, that would sure be an interesting set of bignames now, wouldn't it? I have more examples, that is "enough" for ocnversational purposes. And yes, I could name names, but anyone with google access can find out as well.

    And to add to the stewpot in the fines and jail list some of the more bribed politicians who behind the scenes and in collusion with other industry heads (and being conflict of industry heads themselves) and semi-faceless regulatory bureaucrats, who have allowed this sort of behavior to become a lot more of the "norm" then what people are comfortable with. Yep, fines and jail. Yep, their businesses dissolved, as being "not in the public interest". Cross the line, do the time. It's like that for joe little guy, should be the same for frederick fatcat.

    I think it's perfectly acceptable to "bash on crooks". I think it's perfectly ac

  16. my question by Anonymous Coward · · Score: 2, Interesting
    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 problem, but I want to build a server component that is persistent and doesn't ever sleep. Part of it's core functionality is managing transaction state in memory. The system has to manage those states, so that multi-request transaction don't have to start at step 1 every single time. Well so I thought, we could store those states in Sql Server, except that from our benchmarks, ADO.NET starts to reach a performance limit around 40 concurrent queries. This is due to the fact the each atomic process has to complete within 400ms averaged over several thousand processes. Each process may consist of 2-3 dozen requests.

    Obviously there are serious issues with synchronization, thread scheduling, blocking, asynchronis calls, call backs and interaction with messaging systems like MSMQ for this type of application. In your work with #smalltalk, how have you address these thread issues? did you end up writing your own threading scheduler, and strong monitoring using semiphores? Or did you decide to stay within .NET's pre-emptive threading model? Another option is to use system level scheduler (ie unsafe code) to schedule the thread, monitoring and synch? Some other possible approaches is to use SQL server in a database driven manner, but again the limitation with ADO.NET rules that out because of the high number of concurrent processes. What are your impressions of .NET threading, it's pros/cons for high performance applications where stateful application and high availability are in the requirements?