Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

New S# Language - Smalltalk for .Net 47

Posted by michael from the old-wine-in-new-bottles dept.
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!"
This discussion has been archived. No new comments can be posted.

New S# Language - Smalltalk for .Net More

New S# Language - Smalltalk for .Net

Comments Filter:
  • .....Bring it on :-)

  • My question is this... (Score:3, Funny)

    by MonTemplar ( 174120 ) <slashdot@alanralph.fastmail.uk> on Friday February 14, 2003 @10:02AM (#5301336) Journal
    How much does SmallScript have to pay Microsoft for the use of the # in S#? :)

  • Good for Smalltalk users (Score:5, Insightful)

    by SteveX ( 5640 ) on Friday February 14, 2003 @10:17AM (#5301430) Homepage
    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
    • It's certainly cool, but what is so scary about it? That there will suddenly be more diversity in programming languages used? So someone who is very good with a certain language can really leverage that advantage since they don't have to code their own library bindings as well as the program.

    • Interface Neutrality, not Langauge (Score:4, Interesting)

      by DrSkwid ( 118965 ) on Friday February 14, 2003 @11:46AM (#5302107) Journal
      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 [proweb.co.uk]

      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 [proweb.co.uk]

      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.

      • Let's Make Unix Not Suck (Score:1, Interesting)

        by Anonymous Coward
        http://primates.helixcode.com/~miguel/bongo-bong.h tml

        Miguel argues that piping is not a very good compenent model to build applications or systems.

        In short:
        Binary interfaces can have event interfaces.
        Binary interfaces allow for strongly typed return codes, or can throw exceptions.

        How do you do things like this with text/piping?
        • Miguel argues that piping is not a very good compenent model to build applications or systems.

          Miguel or Dennis Ritchie ?

          I think Dennis gets my vote
        • The 9p protocol is designed to be simple and robust. No piping required and all the things mentioned are possible.

          You did forget something :

          Binary interfaces cannot be [easily] interpreted by humans.

          Which is a curse when you are debugging.

          The only real difference between the binary and textual is that binary encoding is unreadable, eveything else is implementation dependent. Binary interfaces in and of themselves don't guarantee events or exceptions.

          Which would you rather have
          %cat /dev/mouse
          801 600

          or
          %cat /dev/mouse
          ^C^U ^BZ

          [that was the best I could manage for the binary output i took it from what vi reported, in hex it would be 0x0321 0x0258 and ASCII 0x03, 0x02 & 0x21 are somewhat difficult to represent in HTML]
      • I have seen people talking about Plan 9 before, and the way all communication is handled via pipes, but I still don't see the advantage...

        First of all, I suspect that handling all interaction over pipes like this might be rather slower than binary interfaces, but I can ignore that for now.

        The other concern is that it doesn't really matter that everything can be talked to as if it were a socket/file. Looking at your example:

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

        First of all, being brand new to Plan 9, I wouldn't know that I have to access /net/tcp/$n/ctl for a new socket (I am assuming $n means "allocate a new one"?).

        Secondly, not knowing how to use Plan 9 at all, I wouldn't know that the magic command is "connect slashdot.org!80" to open my connection. I would have to have a reference open to see which commands make sense.

        So, what is the benefit?

        As for programs compiled *before* you wrote yours, that is a standard concept for years now, interface-driven programming... In Linux, you can write your own filesystem driver, and then anything can use it just like any other filesystem, as long as you conform to the correct interface. You can do user-level filesystems in Linux, with the same results.

        In Java and SmallTalk, I can use reflection capabilities to talk to everything as if it were an object. I can enumerate fields and methods, and invoke them dynamically.

        Why is it better to talk to everything as a socket?

        • better than a new VM (Score:4, Interesting)

          by DrSkwid ( 118965 ) on Friday February 14, 2003 @01:43PM (#5303277) Journal
          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 [bell-labs.com]

          I can particularly recommend the plumber [bell-labs.com]. 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.

          • Re:better than a new VM (Score:1, Funny)

            by Anonymous Coward
            "Plan9 talks via a published protocol [9p] implementable on any platform."

            Sure. Let us know when it's available for the timex-sinclair, Atari 400, and commodore 64.

    • Re:Good for Smalltalk users (Score:1, Insightful)

      by Anonymous Coward
      It's language neutral so long as your language is a garbage collected, single inheritance, single dispatch 00 language. Otherwise, your language becomes "C# with a thin veneer of another languages syntax".

      Common Lisp on .NET, for example, while possible, would be heinously inefficient, not properly integrable with the crippled Object model (compared to CLOS's multi-dispatch, multi-inheritance model), and all in all pretty pointless.

    • One of the cool things about the .NET framework is that being language neutral

      ... as long as your language of choice has a dialect that conforms to the CLS. That's why Visual Studio.NET's C++ compiler has a ton of "features" you need to use in order to be "managed" by the CLR.

  • What's next (Score:5, Funny)

    by ajw1976 ( 542188 ) <ajw1976@yaTIGERhoo.com minus cat> on Friday February 14, 2003 @11:53AM (#5302163)
    Logo.net


    • > Logo.net

      Lego.net

    • As long as it has turtle graphics, I'm there.
    • lol, ironically java has had logo for an age, with several different implementations:

      (from a list of 160 different languages for the jvm here:
      http://grunge.cs.tu-berlin.de/~tolk/vmlangu ages.ht ml
      )

      "StarLogo
      StarLogo is a programmable modeling environment for exploring the workings of decentralized systems -- systems that are organized without an organizer, coordinated without a coordinator. With StarLogo, you can model (and gain insights into) many real-life phenomena, such as bird flocks, traffic jams, ant colonies, and market economies. StarLogo is a specialized version of the Logo programming language. With traditional versions of Logo, you can create drawings and animations by giving commands to graphic "turtles" on the computer screen. StarLogo extends this idea by allowing you to control thousands of graphic turtles in parallel. In addition, StarLogo makes the turtles' world computationally active: you can write programs for thousands of "patches" that make up the turtles' environment. Turtles and patches can interact with one another -- for example, you can program the turtles to "sniff" around the world, and change their behaviors based on what they sense in the patches below.
      AJLogo
      AJLogo is an implementation of Logo written in Java with about 400 primitives.
      Turtle Tracks
      Turtle Tracks is a modern Logo interpreter and runtime environment written entirely in Java. It is not a direct port of an existing interpreter, but written from the ground up specifically for Java, and designed to take advantage of the strengths of Java as a platform. Turtle Tracks is platform-independent and Internet-ready, and supports numerous advanced features such as multithreading and networking. Unlike some similar Java-based projects, Turtle Tracks is a complete implementation of true Logo, supporting the same basic language syntax and semantics and most of the same primitives as other common Logo implementations such as Berkeley Logo. It also supports plug-in primitive sets and can be integrated with outside Java code as a scripting language.
      rLogo
      rLogo is an easy to learn programming language designed for the World Wide Web. It is based on the Logo programming language.
      Yoyo
      Yoyo is a programming language loosely based on Logo. Since it integrates Java, however, many of the more advanced features require knowledge of Java and how its APIs work. (Was formely called Bongo)"

    • It's called MonoLOGO. [sourceforge.net]:


      An implementation of LOGO for the .NET platform.

      MonoLOGO provides access to all .NET constructs from within LOGO. Its goal to be 99% compliant with ObjectLOGO (there are a few Macintosh APIs that won't make sense to support). A Berkeley LOGO compatibility layer is also planned.

      Runs on Linux and has a Gtk# console interface.

  • Smalltalk with Multiple Inheritance? (Score:3, Insightful)

    by werdna ( 39029 ) on Friday February 14, 2003 @05:36PM (#5305498) Journal
    Seems like an ideological shift to me, more closely related to C++ than to Smalltalk

  • Null handling (Score:3, Funny)

    by Ed Avis ( 5917 ) <ed@membled.com> on Monday February 17, 2003 @06:39AM (#5318251) Homepage
    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!

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close