The Slate Programming Language 244
Posted by CowboyNeal
from the languages-named-after-microsoft-sites dept.
from the languages-named-after-microsoft-sites de:5, Informative)
Not all the world is a desktop application with a GUI. Lisp and the other languages aren't going away in this space anytime soon. It's just too cumbersome to do many of these things in C++, and too slow to do them in Java (Common Lisp is usually native compiled).)
Too obscure (Score:3, Insightful)
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)
Re:Too obscure (Score:4, Interesting)
Re:Too obscure (Score:3, Insightful)
14.upto(19) do |i|
# do
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)
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.
Re:why slate (Score:2)
Re:why slate (Score:2)
Re:why slate (Score:4, Insightful)
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!).
Re:5, Informative)
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].)
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
So far your class has no properties
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();
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
You can merge objects
Regards,
angel'o'sphere
Re:Deja vu (Score:2)
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)
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 L)
Re:April fools..I hope (Score:5, Informative)
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., Insightful)
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:2)
Re:April fools..I hope (Score:3, Insightful)
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:4, Informative)
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:
For a discussion of prototype vs. class based programming consult Appendix C of the NewtonScript reference manual.
Re)
Corrections from one of the language authors (Score:5, Informative)
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)
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)
Re:Prototyping OO is not a great paradigm (Score:3, Insightful)
"Object and inheritance management" is only an issue for those who don't bother to analyze the problem and architect a solution. Slapping together code without understanding the problem is not "prototyping" -- it's wasting time.
Prototypes are for understanding the application requirements, not for "scripting." If you compare prototyping tools to production applications, you are completely and thoroughly missing the point for their existance.
Re
Dylan was hardly successful (Score:2, Insightful)
As elegant and admired as Lisp and Smalltalk are, they aren't exactly the most heavily used programming languages available (and I say that even though I love Smalltalk). Just because a language appeals to language designers, doesn't mean it's going to be embraced by the masses of programmers out there in the trenches. And the more of a mindshift necessary)