New S# Language - Smalltalk for .Net

curador writes "In an interview with David Simmons, CTO of SmallScript Corp., we learned about a new .NET language about to debut...." I was surfing around and found this article and had not noticed it on /. yet so start your flame engines please!"

Comments

My question is this...

[MonTemplar]

How much does SmallScript have to pay Microsoft for the use of the # in S#? :)

Good for Smalltalk users

[SteveX]

I never really "got" Smalltalk but the folks that do love it. One of the cool things about the .NET framework is that being language neutral, your choice of language doesn't have to be based on what toolkits and libraries and whatnot are available to it.

So Smalltalk programmers, through S#, will be able to talk to DirectX or Gtk# or MySQL or whatever without someone having to come up with bindings or libraries or whatever they might otherwise need. Scary. :)

- Steve

Interface Neutrality, not Langauge

[DrSkwid]

It's not the language neutrality that's required it's the interfaces that need opening.

TK & Plan9 get this right by using character and not binary interfaces [Unicode in Plan9s case].

In Plan 9's once you've written a program and exposed it in the Plan 9 way you don't even need libraries & whatnot.

take a look at my IRC bot written in shell script

http://www.proweb.co.uk/~matt/chugly.rc

making a network connection, pah, who needs a socket library

echo 'connect slashdot.org!80' > /net/tcp/$n/ctl

Writing a user level file system to implement such things is a bit more complicated but again, once written *any* program can utilise them with the simple commands we all know and love : echo cat grep ls awk etc. etc.

Here's one I wrote to do google searches

Now every program on my system can do a google search using simple file operations. Even programs compiled *before* I wrote mine, such as awk.

What's next

[ajw1976]

Logo.net

Re:Nothing to flame

[Khalidz0r]

Java.NET already exists, under the beautiful name of C#

better than a new VM

[DrSkwid]

the better I was refering to in my post was speciifally that a new VM is required. Plan9 talks via a published protocol [9p] implementable on any platform. I guess .NET is potentially available everywhere but we know it won't be.

You are right that some knowledge is required up front to know what commands to issue.

One of the main advatages is the standardisation.
I presume you already know how to use cat, ls, grep, echo, > | & friends.

The use of familiair tools and a textual interface is to go with the "everything is a file" paradigm.

what to know where the mouse pointer is
%cat /dev/mouse

play some audio

cat audio.pcm > /dev/audio

want to play it on another machine's soundcard ?

import -a machine /dev/audio /n/machine_audio
cat audio.pcm > /n/machine_audio

(permissions permitting of course)

Plan 9 has more to offer than just a few file semantics.

If you really are interested than a set of papers & all the manual pages are available. Installation is fairly straight-forward [hardware permitting] and there is a VMWare image also available.

Plan 9 isn't trying to be on everyone's desktop, it's more a market of ideas.

http://plan9.bell-labs.com/plan9

I can particularly recommend the plumber. File associations are pretty limiting. Imagine a system where regular expressions and a few shell scripts do the work. I wrote a class browser for my PHP code so that right clicking $foo->bar(); would bring up the definition of ->bar from my PHP source code [which sits on a FreeBSD machine] and it took me about 15 minutes.

Smalltalk with Multiple Inheritance?

[werdna]

Seems like an ideological shift to me, more closely related to C++ than to Smalltalk

Re:Nothing to flame

[Raiford]

The best and the brightest will use the language and the environment that is best suited for the task. Nobody is going to write a device driver in VB and no one should waste time is going to writing some simple gui front in for an ODBC connection to an Acess DB in ANSI C.

Null handling

[Ed Avis]

From the article:

S# helps solve some relatively intractable problems. For example, you may declare a parameter of a public method as an object of type String. Within your method, you call the String.IndexOf method. So far so good--but you have to plan for errors. Another programmer is perfectly free to call your method and pass a Null (Nothing, in VB.NET). Despite the fact that Null is not a String, the .NET framework will happily make the call. That means that your method code needs to check for the possibility that someone did in fact pass a Null, and react accordingly. In contrast, in S#, Null is a true object, meaning you can simplify your code by dynamically adding a Null.IndexOf method, and doing nothing. At one fell swoop, you've eliminated both the possibility of an error and all the "if (var == null)" checks you have to write in other languages.

Oh yeah, sure, you've really eliminated the possibility of error. Why not add every method to the 'null' object while you're about it, then your program could _never_ have null-related bugs!