Slashdot Mirror


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!"

28 of 47 comments (clear)

  1. Another Language :-( by lyoz · · Score: 1

    .....Bring it on :-)

    --
    ... hee2 is stuck under the bed.
  2. My question is this... by MonTemplar · · Score: 2, Funny

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

    --
    -MT.
  3. Good for Smalltalk users by SteveX · · Score: 4, Insightful

    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

    1. Re:Good for Smalltalk users by jorleif · · Score: 1

      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.

    2. Re:Good for Smalltalk users by Anonymous Coward · · Score: 1, Insightful

      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.

    3. Re:Good for Smalltalk users by chrisseaton · · Score: 1

      Multiple interface inheritance is allowed in managed. I think multiple code inheritance is only not allowed in C#, but if you did it in ILASM you could.

    4. Re:Good for Smalltalk users by toriver · · Score: 1
      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.

  4. Interface Neutrality, not Langauge by DrSkwid · · Score: 3, Interesting

    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.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:Interface Neutrality, not Langauge by dustman · · Score: 1

      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?

  5. What's next by ajw1976 · · Score: 5, Funny

    Logo.net

    --
    1. Bad signature
    2. ?????
    3. Profit
    1. Re: What's next by Black+Parrot · · Score: 1


      > Logo.net

      Lego.net

      --
      Sheesh, evil *and* a jerk. -- Jade
    2. Re:What's next by ericski · · Score: 1

      As long as it has turtle graphics, I'm there.

    3. Re:What's next by rhyd · · Score: 1

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

      --
      'Be the change you want to see in the world' - Al Gore
    4. Re:What's next by AirLace · · Score: 1

      It's called MonoLOGO.:


      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.

  6. Re:Nothing to flame by Khalidz0r · · Score: 2, Funny

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

    --
    "What you 'seek' is what you get!"
  7. Let's Make Unix Not Suck by Anonymous Coward · · Score: 1, Interesting

    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?

  8. better than a new VM by DrSkwid · · Score: 3, Interesting

    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.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:better than a new VM by Anonymous Coward · · Score: 1, Funny

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

  9. Smalltalk with Multiple Inheritance? by werdna · · Score: 2, Insightful

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

  10. Re:Nothing to flame by Raiford · · Score: 1
    actually J#

    --
    "player 4 hit player 1 with 0 stroms"
  11. Re:Nothing to flame by Raiford · · Score: 3, Insightful
    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.

    --
    "player 4 hit player 1 with 0 stroms"
  12. Re:Nothing to flame by insecuritiez · · Score: 1

    Why wouldn't anyone write a device driver in VB? Maybe not in VB 6.0 but the whole idea of .net is that no matter what language you use, VB.net, C#, S#.... It all compiles to the same M$ Intermediary code. And since this is a managed code and not native code it takes a performance hit (Microsoft really plays this down, trust me, I've asked all the questions and gotten not a single strait answer). What you should have said is that no one is going to write a device driver for the .net framework period. The .net framework is primarily for web services. It has other advantages and features but none of them include high-performance mission critical applications and drivers. That's for ANSI C and other languages that compile to native binaries. Good memory management skills and code optimization skills will never be replaced by fancy frameworks. What the .net framework does is put training wheels on programming and lowers the overall quality of code produced as well as the median skill and knowledge of the programmer pool.

  13. Re:Nothing to flame by toriver · · Score: 1

    J# is little more than a tool to convert existing J++ apps (read JDK 1.1 plus Microsoft alterations and libraries) to .NET.

    C# is closer to being the language part of the Java clone that .Net is.

  14. Re:Nothing to flame by mnmn · · Score: 1


    Well said. Applies equally to J2EE. I asked some techies a while ago how cant ANSI C/C++ code, if programmed skillfully, be better than J2EE. Use standard portable libs and you have portable code.

    However J2EE is based on a huge pool of Compsci grads weaned on Java in their second year. J2EE is also quite mature and compliant with other companies and plays well with opensourced projects. .NET isnt. Players like IBM and Oracle are working to optimise their J2EE platforms, Microsoft alone couldnt compete there, least due to their software quality.

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
  15. Null handling by Ed+Avis · · Score: 2, Funny
    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!

    --
    -- Ed Avis ed@membled.com
  16. Who you gonna call by DrSkwid · · Score: 1

    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

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  17. Re:Nothing to flame by Viol8 · · Score: 1

    Really? Perhaps you'd like to talk to Linus about why C++ can't be used to develop the linux kernel and why it (and all driver code) must be written in C. But obviously people who write operating systems arn't the best and brightest , no , they'd be the people that write yet-another-dbms-frontend. Right?

  18. 9p != pipes by DrSkwid · · Score: 1

    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]

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter