Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming Announcements IT Technology

The Slate Programming Language 244

Posted by CowboyNeal from the languages-named-after-microsoft-sites dept.
An anonymous reader writes "I know that we have had an influx of new programming languages of late, but I feel that this one merits special attention. Theoretical computer scientists and long-time Squeak and LISP contributors Brian Rice and Lee Salzman have been rapidly developing a language called Slate. It draws on the various strengths of the Self, Smalltalk, and LISP languages. To quote from the website: 'Slate is a prototype-based object-oriented programming language based on Self, CLOS, and Smalltalk. Slate syntax is intended to be as familiar as possible to a Smalltalker, rather than engaging in divergent experiments in that respect.' The beta release is currently being written in Common LISP."
This discussion has been archived. No new comments can be posted.

The Slate Programming Language More

The Slate Programming Language

Comments Filter:

  • It works! (Score:3, Funny)

    by Timesprout ( 579035 ) on Saturday March 27, 2004 @12:36PM (#8689527)
    I prototyped this mail using it

  • Ah, great, Smalltalk (Score:4, Funny)

    by Deraj DeZine ( 726641 ) on Saturday March 27, 2004 @12:39PM (#8689546)
    Slate syntax is intended to be as familiar as possible to a Smalltalker

    And for the rest of the world? Oh wait, sorry, Smalltalkers are gods among programmers. So foolish of me to think of myself before the Smalltalkers.

    • Re:Ah, great, Smalltalk (Score:3, Insightful)

      by hding ( 309275 )
      I suppose the rest of the world can take the five or ten minutes that it takes to understand Smalltalk syntax.
      • I suppose the rest of the world can take the five or ten minutes that it takes to understand Smalltalk syntax.

        It would be nice if it only took five or ten minutes to integrate Smalltalk syntax into your intuitive understanding of program flow. Since it doesn't, though, it'll probably take a few days to a few weeks (depending on the programmer) to get used to it enough to program in it with any kind of efficiency.

    • well, (Score:3, Funny)

      by bsDaemon ( 87307 )
      at least you admit it. that's the first step to recovery.
    • Slate syntax is intended to be as familiar as possible to a Smalltalker

      So it is definitively not going to be very popular in Finland [scantours.com]. The Finns are known as the worst small talkers in the world.
      Oh, wait...

    • Re:Ah, great, Smalltalk (Score:2, Interesting)

      by Anonymous Coward
      Great, indeed. I'm always amazed by comments like this. How on Earth a language designed to be easily used by small children ever acquired this lofty "ivory tower" connotation I doubt I will ever know. I've been a professional Smalltalk programmer for the last ten years. The language is literally child's play, working with it is easy and enjoyable, building large complex systems with it is trivial, maintaining them is also rather painless, the tools that are typically bundled with it are incredibly powe
      • In grad school our compiler class had to write a basic C compiler (standard fare I know). Was a good learning experience and all that (actually I wrote mine in Macintosh Pascal just to freak the professor!) Then in a course in OOP the class did a group project to create Smalltalk (only got about half of what we wanted done... that's the nature of groups I think) Was my first exposure to Smalltalk and to OOP and really liked Smalltalk. Have always thought that students getting their first exposure to OOP wo

    • Oh wait, sorry, Smalltalkers are gods among programmers.

      Indeed. They are mentioned frequently on the literature, but no one has actually seen one living and breathing. :)

    • Smalltalkers are gods among programmers. So foolish of me to think of myself before the Smalltalkers.
      Hmmm, I knew there was a reason beyond supporting legacy code for taking that two week Smalltalk course. Divinity here I come.
    • And for the rest of the world? Oh wait, sorry, Smalltalkers are gods among programmers. So foolish of me to think of myself before the Smalltalkers.

      Oh, please, spare us the cynicism. Smalltalk syntax is pretty straightforward. Yes, you, too, could learn it in a couple of hours, which is more than can be said for Java or C/C++ syntax. Does everything have to come down to braces and semicolons nowadays?

  • Obligatory. (Score:3, Insightful)

    by hot_Karls_bad_cavern ( 759797 ) on Saturday March 27, 2004 @12:42PM (#8689568) Journal
    If the new language doesn't support your needs, shut up and don't use it.

    Use what is best for the situation and don't whine.
    • Negative comments about a new language are whining.

      Negative comments about the negative comments are insightful.

  • Too obscure (Score:3, Insightful)

    by Animats ( 122034 ) on Saturday March 27, 2004 @12:43PM (#8689578) Homepage
    By paragraph 2 of the manual, we're here:
    • Block closures

      A block closure is an object representing an encapsulable context of execution, containing local variables, input variables, the capability to execute expressions sequentially, and finally returns a value to its point of invocation. The default return value for a block is the last expression's value; an early return can override this.

    This is a language for people who like obscure semantics.

    Yes, closures are useful. I've used them in LISP. I even used one once in production code in Perl, to do some error handling cleanly. But when the manual starts out with closures, it's clear that somebody is getting too cute.

    This is a language for "l33t haxxors", of the old MIT AI Lab persuasion. Check out "instance specific dispatch". Now that's designed to totally confuse maintainers.

    • Re:Too obscure (Score:3, Interesting)

      by Anonymous Coward
      In Smalltalk, closures are fundamental. Without them you can't do if statements or whiles or anything else.. Smalltalk closures are very simple.. in Lisp their are a bit more intimidating to the unitiated.

    • Re:Too obscure (Score:3, Insightful)

      by quigonn ( 80360 )
      No, it's not obscure. Please have a look at Ruby, where closures are the natural way of doing most things. For example, there is no for-loop, but it is implemented as method for Integer objects (literals are also objects in Ruby):

      14.upto(19) do |i|
      # do ... end is the closure
      end

      so, the closure is executed 6 times, the first time with i = 14, the next time with i = 15, the third time with i = 16, up to i = 19.

      Just have a closer look at Ruby, and you will see that the whole standard library is built on t

    • Re:Too obscure (Score:4, Insightful)

      by be-fan ( 61476 ) on Saturday March 27, 2004 @03:03PM (#8690399)
      Closures are everything! All the crap that modern languages do with special-purpose features, like generators, iterators, etc, can be done with closures. Hell, OOP can be done on top of closures.
    • But when the manual starts out with closures, it's clear that somebody is getting too cute. This is a language for "l33t haxxors", of the old MIT AI Lab persuasion.

      No, they are just following the Smalltalk tradition. Smalltalk is a language that people generally find easy to learn. The use of blocks in Smalltalk just makes things consistent and simple, and it lets you write your own control structures.

      Check out "instance specific dispatch". Now that's designed to totally confuse maintainers.

      That's

  • right! (Score:2, Funny)

    by Anonymous Coward
    I C sea Slates on the C Shore!

  • The first thought that came to my mind... (Score:3, Funny)

    by Rahga ( 13479 ) on Saturday March 27, 2004 @12:45PM (#8689595) Journal
    Even though, admittedly, this looks is a joke post, I couldn't help but think this the moment I noticed the article: "I don't really need a programming language that hates Catholic, can't grasp the realities of free-market economics, and is determined to write-in Howard Dean on the 2004 elections ballots..."

  • why slate (Score:5, Informative)

    by larry bagina ( 561269 ) on Saturday March 27, 2004 @12:48PM (#8689609) Journal
    From the faq: Why did we decide on a new programming language?
    • Smalltalk-80 is over 20 years old. We don't think the original team intended for the model to last this long (well, from discussions on the Squeak [slashdot.org] mailing list, they've said so).
    • Smalltalk [slashdot.org] doesn't adequately express many design possibilities that show up often in good complex programs. Requiring classes, not allowing multiple dispatch, and not including some form of multiple inheritance is limiting for a lot of interesting cases.
    • The Common Lisp [slashdot.org] and Dylan [slashdot.org] communities have created some powerful interface toolkits which Smalltalk cannot easily take advantage of.
    • Cecil [slashdot.org] is statically-typed and not very dynamic. Dylan [slashdot.org] suffers from a case of too much syntax, and not enough emphasis on live environments.
    • Common Lisp [slashdot.org] is not object-centered or generic enough with its functions.
    • Goo [slashdot.org] uses the unfriendly Lisp syntax, and isn't quite suited to object-centered thinking.
    • Self [slashdot.org] turned out to be too strange an environment for Smalltalkers, and never had a decent implementation. Strongtalk [ucsb.edu] was bought up.
    • Bytecode virtual machines and chunk format are old hat. It'd be worth at least trying some different run-time setup.
    • The Squeak [slashdot.org] system is very powerful in terms of some experimental libraries and user interface ideas, but is based on an aging architecture and a license that is partly troublesome.

    i think smalltalk++ would be a better approach than inventing a new language. Look at C++: it's backwards compatable with C, so a C coder is already a C++ coder and can slowly start making use of new C++ features.

    • I think Smalltalk++ would be in wrong direction. Maybe OBjective-Smalltalk, or Smalltalk#.

    • Re:why slate (Score:4, Insightful)

      by Anonymous Coward on Saturday March 27, 2004 @01:04PM (#8689724)
      "i think smalltalk++ would be a better approach than inventing a new language. Look at C++: it's backwards compatable with C, so a C coder is already a C++ coder and can slowly start making use of new C++ features."

      Or maybe, just maybe for once we could acknowledge that programmers are smart people and can learn new things. Lets get off trying to bend over backwards and make a broken language better -and- backwards compatible. This is exactly why C++ is the horror that it is today. Write a new clean language and just make sure that it links well with others. Then you can call functions from your old programs written in whatever the hell language you want, nobody knows and the code slowly moves over to a codebase that doesn't rape the programmer (like trying to use exceptions in a C++ program without the exception killing you!).
      • And yet, whenever there's an article about C#, a bunch of Slashdotters come on pissing and moaning about "Why switch away from C++?" thereby completely missing the point of moving to C# (which, by the way, is an amazing and simple language).
    • New language? We seem to get a new language every time someone completes a course in compiler construction...

  • Deja vu (Score:5, Interesting)

    by spellraiser ( 764337 ) on Saturday March 27, 2004 @12:49PM (#8689616) Journal

    Slate is a prototype-based object-oriented programming language based on Self, CLOS, and Smalltalk.

    From a recent [slashdot.org] post:

    Prothon is a new industrial-strength, interpreted, prototype-based, object-oriented language that gets rid of classes altogether in the way that the Self language does.

    Does this point to a trend in language design?

    • Perhaps they used the buzzword generator [elfqrin.com]

    • Does this point to a trend in language design?

      Yep: if you want publicity, send an article on a brand new language that isn't finished yet to Slashdot and wait. :-)

      At least we're improving, though. The last one was "pre-alpha" (or vapourware, as it's technically known). This one is "beta" (or get-everyone-else-to-test-it-for-you, as it's technically known). One of these days, someone will write an article about a genuinely innovative language that really exists in usable form, and the eds will reject i

    • Ok, I'll ask. What's a "prototype-based object-oriented" language and how does it differ from C++ and Java?

      • prototype based languages (Score:5, Informative)

        by Jecel Assumpcao Jr ( 5602 ) on Saturday March 27, 2004 @01:40PM (#8689938) Homepage
        When running a program, it is very likely that you will want to create new objects as you go along. You have some alternatives:
        • call a magic constructor fucntion (C++ and friends)
        • send a message like "new" to a factory object (like a class in Smalltalk)
        • send a message like "copy" or "clone" to an object that is like the one you want to create

        In the third case you might find out that you can get by with a set of "prototype" objects to copy from and you don't need classes at all. But to actually eliminate classes you will have to find solutions to the other things they do for you like hold the behaviors for the objects (you can put them in the objects themselves, for example) and reflection (Self uses special "mirror objects" for that).

        There are several different styles of prototype based languages [dekorte.com].

        • Re:prototype based languages (Score:4, Interesting)

          by Piquan ( 49943 ) on Saturday March 27, 2004 @04:40PM (#8691002)

          Being a Lisp programmer, I'm always looking for new ideas to bring into my Lisp programs. It looks like Lisp-- possibly even CLOS-- could support prototype-based programming without extensive pain.

          One thing that I'm wondering about in prototype-based OOP is redefining stuff. In Smalltalk and CLOS (I don't know Self), you can redefine methods over classes on the fly, or change member variable definitions, or whatever. I take advantage of this to have a production server running for months while I make improvements.

          But in a prototype language, this looks, well, difficult. If your methods are associated with prototype objects, then if you have existing non-prototype objects and change a method, then would the non-prototype objects get the method def passed down, or what?

          It seems like a prototype language would also have problems with multiple inheritance and multiple dispatch, but it looks like they've licked those too. Interesting.

          • If your methods are associated with prototype objects, then if you have existing non-prototype objects and change a method, then would the non-prototype objects get the method def passed down, or what?

            Your use of the term "(non)-prototype object" is a bit confusing since every object is a "prototype" which can be cloned... but I think I understand your question.

            In prototype-based languages, creation of new objects occurs by copying (cloning) existing objects. After copying, the clone is independent from t

      • Re:Deja vu (Score:4, Informative)

        by angel'o'sphere ( 80593 ) <angelo.schneider ... e minus math_god> on Saturday March 27, 2004 @03:23PM (#8690506) Journal

        What's a "prototype-based object-oriented" language and how does it differ from C++ and Java?

        In Java and C++ you have classes. In a prototyped language usually not, there you only have objects.

        To make it simple, lets look at the java.util.Hashtable.

        Suppose if you write this:

        class MyClass {} the compiler would do this:
        Object MyClass = new HashTable();

        So, instead of defining a class, you just created an empty object ... I used a Hashtable, because that makes the later explanations more easy, it could have been simply an object of course.

        So far your class has no properties ... no data and no methods.

        So you likely would write something like this:
        class MyClass {
        Object start;
        Obejct end;
        }

        As prototyped languages are usually typeless you would only need to write this:
        class MyClass {
        start;
        end;
        }

        Our hypotetical compiler makes this from your typed code:
        Object MyClass = new Hashtable(); // define a "new class"
        MyClass.add("start", null);
        MyClass.add("end", null);

        So, instead of "defining" a class, like you did in Java or C++, you only created an object in the most global namespace. That object is called "MyClass" just as your class would have been called.

        That object has two "slots" with the names "start" and "stop", just like a class would have two attributes of type Object.

        So: the concept is called prototyping, because you would usually initialize the MyClass object more properly, so that "start" and "end" would have a value and would not be empty.

        Now comes the interesting point: we know how to make classes now. How to make objects from them?

        Well, all Objects have a method called "new".

        In java you would write new MyClass(). But you could of course asume a class had a static method called NEW().

        So MyClass.NEW() would create a new object of type MyClass. That method is usualy build into the language and every "class" has it. So, what does NEW() do? It "clones" the object MyClass.

        In Java we have a class MyClass, and with new we create objects. The objects have some kind of poitner to their class.

        In a prototyped language you only have objects. If you say new to them, they simply create a clone from themselves. The original object is called "prototype" or "traits". Instead of calling a constructor to initialize such a new created object it is fully initialized with default values during teh cloning.

        Why did I use a Hashtable as example? Well, you simply can tell a Hashtable to clone itself ... if the Hashtable describes a prototype. The slots in a Hashtable are similar to teh slots in an object of an prototyped language. Suich a slot usualy has a name and can hold any object ... methods are objects as well :D

        You can merge objects ... and so you do not only get a new object but also a new "class". Thats one way how inheritance could be implemented. But usualy you use nested Hashtables for inheritance, as yoou most often want single inheritance only .. and merging is used for mixins .... another term wixh would need an explanaition as long as this one.

        Regards,
        angel'o'sphere
    • Does this point to a trend in language design?

      No, just in a trend (of 2) in slashdot stories. No one really uses these languages.

    • In search of an appropriate unit of abstraction... (Score:4, Informative)

      by alienmole ( 15522 ) on Saturday March 27, 2004 @05:33PM (#8691353)
      There does seem to be a fair amount of interest in prototype-based languages lately. Javascript's object system is also prototype-based, also inspired in part by Self, as well as Lisp/Scheme. Javascript may have helped trigger the current wave of interest in this subject.

      Purely prototype-based languages don't really compete with their more structured (class-based) cousins, though. One of the main benefits of prototype-based langauges is that they give a lightweight way to create an abstraction - you don't necessarily have to create a class first. This isn't necessarily a pure win. The structure provided by classes can be useful, too. A good language should provide both capabilities, no matter what mechanisms it uses to do that. It's possible Slate does this, I haven't looked.

      Another good candidate mechanism for lightweight abstraction is first class anonymous functions, i.e. lambda, as found in Scheme, Lisp, Javascript, Perl (Python got it wrong, unfortunately). Having real lambdas tends to eliminate a lot of the problems which other languages find themselves trying to solve. Although it helps to also have macros, which limits the list to Scheme and Lisp.

      • I've heard before that python got anonymous functions wrong, and it was argued that the problem is that they don't see the scope in the correct way. Could you please elaborate?

        Yesterday I wrote a small python script (to learn some of it) and it included this (quicksort):

        def sort(l):
        if len(l) <= 1:
        return l
        pivot = l[len(l)/2]
        i = 0
        ll = filter(lambda e: e < pivot, l)
        le = filter(lambda e: e == pivot, l)
        lg = filter(lambda e: e > pivot, l)
        l = sort(ll)
        l.extend(le)
        l.extend(sort(lg))

        • I've heard before that python got anonymous functions wrong, and it was argued that the problem is that they don't see the scope in the correct way. Could you please elaborate? ... Here the anonymous functions do see their scope (pivot). However, unlike Perl for example, these "functions" really can be only expressions so in that sense they're more limited as. Just out of curiosity, is that what you meant with "python got it wrong"?

          Anonymous functions should really be called anonymous subroutines - afte

        • Voodoo1man's reply linked to a thread [google.com] which hashes out some the issues with lambda in Python.

          The brief summary is that there are currently two problems, that I know of offhand, with lambda in Python:

          • Statements are not allowed, only expressions.
          • Modifying the value of a variable in an enclosing scope is not allowed.

          These are both quite severe restrictions that limit the ability to use lambda effectively, i.e. in ways that it is common to use them in languages which support lambda correctly.

          In languag

      • If you have prototypes classes are not needed. They give no further possible abstraction. If you have only classes prototypes are not needed either, but they provide a lot of power you lose otherwise.

        What you likely want to say is static typing versus dynamic typing. Most prototype bases languages are dynamic typed ... so the method dispatch etc. is very much done during runtime.

        In case you want to "design" a larger system with a prototyped language, you of course "design" traits objects. They are just th

        • If you have prototypes classes are not needed. They give no further possible abstraction. If you have only classes prototypes are not needed either, but they provide a lot of power you lose otherwise.

          What you likely want to say is static typing versus dynamic typing. Most prototype bases languages are dynamic typed ... so the method dispatch etc. is very much done during runtime.

          No, I stand by what I said. Prototype-based languages typically allow the structure of instances to be modified arbitrari

  • April fools..I hope (Score:4, Interesting)

    by rufusdufus ( 450462 ) on Saturday March 27, 2004 @01:15PM (#8689781)
    Confusing things like:

    3 + 4 * 5 " ==> 35 (not 23) "

    and

    (3 / 4) == ( 3 / 4) "==> false"

    give pause for concern.

    But the example code snippet for the curious @ dispatch operator uncommented and unexplained takes the cake:

    "
    oc@(OrderedCollection traits) copyFrom: start to: end
    [| newOC |
    end start ifTrue: [^ oc newEmpty].
    newOC: (oc traits newSize: end + 1 - start).
    start to: end do: [| :index | newOC addLast: (oc at: index)].
    newOC
    ].
    "

    How could someone argue with a straight face that this gobblygook is progress in programming languages?

    • Amazing. (Score:5, Funny)

      by warrax_666 ( 144623 ) on Saturday March 27, 2004 @01:31PM (#8689881)
      And they say its syntax is easier to understand than LISP? I wonder what they're smoking...

    • Re:April fools..I hope (Score:5, Informative)

      by Chinju ( 662523 ) on Saturday March 27, 2004 @02:20PM (#8690160)
      I don't know much about Slate, or Smalltalk, or anything, for that matter, but a quick look at the article shows that both of your "confusing" examples are not that confusing...

      As someone else already pointed out, "3 + 4 * 5" ==> 35 (not 23) because Slate has no differences in binary operator precedence and therefore always associates to the left.

      And as for "(3/4) == (3/4)" ==> false, this is because "==" tests for _object_ equality, and the two different instances of "(3/4)", while representing the same numerical value, are distinct objects. It appears that "=" tests for numerical equality.
      • untested, but I'd assume that in java

        (new Integer(4) == new Integer(4))

        would also return false.
    • I was about to say the same thing but I hesitated because I've put the 'crap' label in many new programming languages. But I am glad someone agrees with me.

      What happened to simplicity ?

      • What happened to simplicity ?

        The point is that languages like SmallTalk Self and this those new beasts: ARE SIMPLE.

        Look at it from a different point of view! Suppose you may use your favorite language and you are requested to implement a runtime system and compiler for such a language.

        Agree full heartly: SmallTalk has a shitty syntax. So has LISP. Why do I say that? Because most people believe you can learn any syntax. But: a lot of people believe SmallTalk is the BEST language ... and wonder why it i
        • Although I pretty much agree with what you say I want to add this the conversation.

          In the end when choosing a programming language the programmer asks themselves a few questions. Namely.

          1) How does this programming language make me more pructive. How hard or easy is it attach to a database, pull some records out and display them in a GUI. How hard is it to create a simple server and client. How much effort does it take to express my ideas into a product.?

          2) How does my program perform once it's done? Is
      • Assuming that a language has no major design mistakes, there is generally a tradeoff between simplicity of the language and simplicity for the programmer.

        Lisp is beautifully, terribly simple, but it may not be simple to write a useful program in Lisp.

        C is "simple" with its mere 31 keywords, but the flip side is typing if(!strncmp(input_name, name, strlen(name))) when you really mean "if input_name = name".

        Perl and Python are simpler for the programmer, at the cost of great complexity under the covers.
    • Sometimes I get the feeling a language is using different syntax just to be different. That and buzzwords are real turn-offs.

    • Re:April fools..I hope (Score:3, Insightful)

      by scrytch ( 9198 )
      > 3 + 4 * 5 " ==> 35 (not 23) "

      As it has always been in the smalltalk family of languages (which includes basically Smalltalk and Self). This was once considered a necessity as smalltalk was interpreted strictly as a stream of instructions (much like forth is now), but now that it's always compiled, I rather wonder whether this isn't legacy baggage. Certainly flexible overloadable operators aren't inimical to the notions of operator precedence, as the ML language family shows.

      I certainly don't get
    • It may still be progress, but you are right: any programming language that doesn't look like pseudo-code is lacking, since pseudo-code is what we use when we want to express an idea most clearly.
    • That's pretty standard Smalltalk stuff. C/C++/Java syntax isn't any simpler--you just have gotten more used to it.

  • Wait a minute....... (Score:5, Funny)

    by MasterSLATE ( 638125 ) on Saturday March 27, 2004 @01:29PM (#8689862) Homepage Journal
    Thats MY nick..... So, they're saying I'm a smalltalker with a lisp?

    Shhhtop it! :(

  • ain't nothin' wrong with prototype OO (Score:4, Interesting)

    by Laxitive ( 10360 ) on Saturday March 27, 2004 @01:53PM (#8690019) Journal
    Man, and here I am writing my own little VM for a prototype OO system.. seems to be all the rage nowadays :D. I'm liking the recent trends of languages evolving to use simpler and simpler higher level semantics. I am a fan of smalltalk and self, but not their syntax. Their language environment and semantics, though, are worth pursuing.

    One of the reasons I like prototype OO (specifically, delegation-based prototype OO, as opposed to languages that use embedding), is that a lot of _other_ dynamic language models fit well on top of it. For example, it would be very simple to make a Python -> Self compiler, because constructs that self exposes can be used directly to implement more specific class-oriented pythonic constructs. It leads me to beleive that a prototype-oo oriented base-vm can serve as a good abstract platform environment for several dynamic 'scripting' languages.

    I'm not sure about the multiple dispatch though. I think multi-dispatch can be confusing.. especially in languages like these where the notion of runtime types is muddled quite a bit of the time.

    -Laxitive

  • I'm going to create the Stale programming language (Score:2, Funny)

    by Anonymous Coward
    It's going to be based on COBOL, but will add the most annoying features of all of the other programming languges, and will leak memory like a firehose through a collander.

  • NewtonScript? (Score:4, Informative)

    by Archibald Buttle ( 536586 ) <steve_sims7 AT yahoo DOT co DOT uk> on Saturday March 27, 2004 @03:20PM (#8690489)
    Yet another language turns up that claims its virtual parents are SmallTalk, Lisp, and Self...

    It would seem that Apple may have had it right ten years ago when they made NewtonScript, the native language of their Newton computers, since that language too claimed SmalllTalk, Lisp and Self as its antecedents.

    Having had a brief look though at the documentation for Slate, and yesterdays Prothon, I can't help but feel that Apple did a much better job with NewtonScript and the Newton environment. NewtonScript seems to me to be much more mature and better thought out than these two examples.

    As for comments that I read here about prototype-based languages not being suitable for application development and are effectively only the domain of accademics, I say bullshit. Class-based programming really isn't the only method of OO development, and prototypes can be equally effective. Many thousands of applications were written for the Newton, and they all used NewtonScript and its prototype-based object model. Prototypes can usually be used in a very similar way to classes, and most class-like behaviour can easily be simulated.

    If you're interested in finding out more about how NewtonScript worked and functioned there reference manual can be found here:
    http://www.unna.org/unna/development/docume ntation /NewtonScriptProgramLanguage.pdf
    For a discussion of prototype vs. class based programming consult Appendix C of the NewtonScript reference manual.
    • Isn't javascript prototype based? It's ironic that one of most widely used languages is prototype based and most people consider it a "toy" language.

  • A better smalltalk-like language (Score:5, Interesting)

    by cryptoluddite ( 658517 ) on Saturday March 27, 2004 @03:25PM (#8690514)
    There are other Smalltalk-based languages that are far better than this, for example SmallScript [smallscript.org]. The guy behind it, David Simmons, is trying to learn from Smalltalk's mistakes:
    • Isolated, all-in-one environment creates a with-us or against-us situation. Smallscript can plug into .NET, and you can embed C++ or other language code directly into the program and link to external code.
    • Slow performance. Smallscript is targeted more at scripting, where performance is less critical. Even the best Smalltalks average about 1/10th the speed of C on common codes. All Smalltalks are significantly slower than Java.
    • Complete lack of security. Smalltalks allow dynamically loading and running code (there are even smalltalk-lets like applets), but have no provisions for Java-like sandbox security. Smallscript has some provisions for security and can leverage .NET's security.
    • Unnatural language syntax for programming. Smalltalkers claim their language is more like English, but most programmers just don't like it. Smallscript has added a few C-like keywords and syntax.
    • Lack of solid, stable core. One of Java's strengths is a huge core library that is unmodifiable by applications. This means that everybody knows what the core does and what is available in it. Smalltalk core is flexibly, where developers add methods to objects on a whim and re-writing the actual code for the core objects. This means that apps are not portable to future language runtime versions and can't co-exist with other applications.

    This new Slate language looks just like Smalltalk only with new features that nobody actually wants, such as prototypes instead of classes. AFAICT, it hasn't improved on any of the above problems and has actually made some of them worse. IOW, it's doomed.

    Scallscript is a start. It's definitely the best of the breed. Personally, I think the greatest barrier to acceptance of Slate / Smalltalk / Smallscript / Squeak / Whatever is the language syntax. Programmers just don't yoda talking like, and a slightly-off Germanic style of grammar just doesn't fit well with an activity like programming that is more mathematical and logical than like communication.

  • UI (Score:2)

    by Piquan ( 49943 )
    The article says they're merging Morphic and CLIM... two of the coolest UIs I've ever used. If they pull that off, the UI at least will have definate win potential.

  • Corrections from one of the language authors (Score:5, Informative)

    by water451 ( 200460 ) on Saturday March 27, 2004 @06:30PM (#8691666) Homepage

    This took me by surprise, and I'm not a usual poster here, so I don't have the energy to reply to each person in turn. So I'll summarize some points I've seen:

    This post is entirely misleading; we are not researchers, and we do intend to do business based on this language. However, what the language itself is is entirely mis-represented. Note: the original submitter is not affiliated with our project in any way, and in fact does not actually know or use the language.

    First, we are not in a project mode of self-promotion or public representation at all. Nothing on that site claims to be a real tutorial, and the current efforts have mostly been about experimentation. We are still preparing the really usable implementation, and have a huge set of ideas and environment enhancements in backlog waiting for this. What's mentioned on the front page is actually a mere fraction of what we're working on.

    The project name, "Slate", is short for "Clean Slate Smalltalk". If you don't know Smalltalk, very little of it will make sense; what's at issue is that we mean what Alan Kay would say in that Smalltalk currently means Smalltalk-80, just a certain quirky snapshot of a whole range of ideas that he and others were working on. We're interested in that whole range.

    Slate is only about prototypes insofar as this was an initial language stage that was simple to play with and powerful enough to explore without too many limitations. Further revisions of the language will feature higher-level facilities for more type-safe programming and more declarative consistency (declarative in the sense of (re-)defining a class and having its instances track that consistently).

    Slate's environment is about 0.001% of completion of what we intend, and we have a huge body of experience and code and ideas to draw upon which are already largely mapped-out. What you see on the site is not representative of what we want in those terms.

    The syntax is definitely odd. At issue is the fact that we kept a minimal Smalltalk syntax core and optimized it for "phrase value" and added various annotation mechanisms, which wind up being very hard to understand until you crack open the 40-page programmers' manual which explains this all. Although it is no tutorial, everything is explained there, and improved with feedback from early users.

    Slate is eventually going to be a full environment, and be very flexible at a large scale, so that questions of prejudice about design choices will not matter, because we actively take part in designing the system so that users can make the choices: whether image-style live interaction or C-embeddable, highly-optimized, low-overhead, no-IDE deployment. And make it so you can make these choices independently; current Smalltalks, Lisps, Dylan, and hundreds of other languages (especially the more common ones) don't have this.

    There are a number of issues brought up here which are addressed but not advertised on the front page; for example, Slate will handle security at the language level, using capability analysis and the subjective programming feature mentioned. Our project has no marketting team (see Smallscript), and has actively avoided public claims until we have the demonstration at-hand. I am giving a presentation and demonstration of the next major release, featuring a self-hosting (C-friendly) setup in Seattle at Smalltalk Solutions 2004 [smalltalksolutions.com] in May.

  • Most often used prototype based language is... (Score:3, Informative)

    by jeti ( 105266 ) on Saturday March 27, 2004 @08:21PM (#8692330)
    JavaScript

    You read right. JavaScript has a prototype based system for objects. I seldom see this mentioned in language design discussions.
    Actually I like JavaScript and it's prototype system quite a lot. It's a nice and powerful little language.
    But that's likely only the case because I never needed to implement any cross-browser stuff in it.
  • A language in which one programs entirely in paradigm shifts, and "sea_change" is a reserved word. Any reference to descendant classes are referred to as frere; their parent classes as pere. I would go on, but Slate isn't as much fun as the other new programming language, Salon.

  • RE: Theoretical computer scientists... (Score:3, Funny)

    by Ignominious Cow Herd ( 540061 ) on Sunday March 28, 2004 @12:00AM (#8693687) Journal
    I wonder what Real computer scientists have been working on.

  • GNU Smalltalk (Score:3, Informative)

    by hak1du ( 761835 ) on Sunday March 28, 2004 @05:59AM (#8694857) Journal
    If you are looking for a Smalltalk-like language for scripting applications without the Smalltalk GUI, check out GNU Smalltalk [gnu.org]. It's a pretty faithful implementation of Smalltalk, and it even has a JIT.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close