Table: Ruby versus Smalltalk, Objective-C, C++, Java;
Armin Roehrl
I tried to compiled an objective table to compare these OO languages.
(typing, inheritance, garbage collection, ..)
http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
All mistakes are my mistakes :-), so don't flame me about mistakes;
I will simply updated the table.
bye
Armin.
-----------------------------------------------
Armin Roehrl, http://www.approximity.com
Albert Wagner
1) Smalltalk is dynamically typed
2) The Portable Object Compiler(Obj-C) by David Stes offers 2 methods of GC
Armin Roehrl
Thanks a lot for the fast reply. I corrected 2) already;
Should I correct 1, too?
>
> 1) Smalltalk is dynamically typed
I typed dynamic/static here as in GNU Objective-C I think
I can assign a variable a different type than id. Then the compiler
can do a check as in C++.
> 2) The Portable Object Compiler(Obj-C) by David Stes offers 2 methods of GC
I must have used POC too long ago when that feature was not yet suppored.
>
> On Friday 23 November 2001 06:05 pm, you wrote:
> > Hi,
> >
> > I tried to compiled an objective table to compare these OO languages.
> > (typing, inheritance, garbage collection, ..)
> >
> > http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
> >
> > All mistakes are my mistakes :-), so don't flame me about mistakes;
> > I will simply updated the table.
> >
> > bye
> > Armin.
> >
> > -----------------------------------------------
> > Armin Roehrl, http://www.approximity.com
--
James Britt (rubydev)
;)
James
Armin Roehrl
> What? No Python?!! Oh, the natives will be restless ...
(or any other language; Common- Lisp?)
Armin
--
Paul Prescod
>
> On Saturday 24 November 2001 02:01, James Britt (rubydev) wrote:
> > What? No Python?!! Oh, the natives will be restless ...
> Email me the entries for Python and I add it at once :-)
> (or any other language; Common- Lisp?)
Python is the same as Ruby according to your list except:
Inheritance: multiple
Access to super method (Python 2.1 syntax): super(MyClass,
self).methodName
root class: None
Super is not a keyword so you need to tell it what method it is
syntactically contained in (but then you can use it anywhere you want
without worrying about syntactic contex)
But there are things you could argue about like private data/methods --
you can get at them but you need to do extra work to do so(as in most
other languages). Garbage collection: yes, except in very rare
situations involving deterministic finalizers in a cyclic loop (which
finalizers do you run in what order?).
Paul Prescod
Armin Roehrl
Luc
> All mistakes are my mistakes :-), so don't flame me about mistakes;
> I will simply updated the table.
You can replace the question marks by a 'yes' for the Java column on the
'Runtime access to instance variable names' line.
--
Luc - luc...@mac.com
Robert Feldt
FYI: Some additional aspects when comparing Ruby and Smalltalk can be
found at
http://www.ce.chalmers.se/~feldt/ruby/summaries/comparing_ruby_and_smalltalk.html
Don't know if its suitable for your table though...
/Robert
Michael Neumann
Also have a look at:
http://www.s-direktnet.de/homepages/neumann/langcomp.de.html
It covers the languages BETA, C#, C++, C-Talk, Eiffel, Java, ObjPascal,
Ruby, Sather and Smalltalk.
Regards,
Michael
--
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de
Armin Roehrl
john%john...@pop.business.earthlink.net
Is CLOS (common lisp object system) an actor in this world still? Or is there some other scheme or lisp or guile version that deserves to be included? I am just asking I don't have the knowledge to contribute.
John
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Stefan Schmiedl
http://www.paulgraham.com/avg.html
s.
john%johnkni...@pop.business.earthlink.net (2001-11-25 00:31):
--
Stefan Schmiedl
EDV-Beratung, Programmierung, Schulung
Loreleystr. 5, 94315 Straubing, Germany
Tel. (0 94 21) 74 01 06
Public Key: http://xss.de/stefan.public
shhhh ... I can't hear my code!
David Simmons
"Armin Roehrl" <ar...@approximity.com> wrote in message
news:01112414341623.28105@linus...
Hi Armin,
As previously posted, you inspired me blatantly build on your idea and write
a similar chart for our website.
See http://www.smallscript.org/Language%20Comparison%20Chart.asp
Thanks,
-- Dave S. [www.smallscript.org]
Pixel
> As previously posted, you inspired me blatantly build on your idea and write
> a similar chart for our website.
>
> See http://www.smallscript.org/Language%20Comparison%20Chart.asp
some remarks:
- what do you mean with "multi-methods". AFAIK it's multiple dispatch, aka
using runtime type of arguments for dispatching. Few languages have this, C++
doesn't nor C# (CLOS, dylan do have it).
- "Calltime Dispatch Binding": not in C++? weird
- what do you mean with "Tail Calling"? IMO it's an optimisation which depend on
the implementation. AFAIK many C++ implementations handle tail recursion (gcc
does it nicely since 2.96)
- "templates" is the specific C++ terminology. generics is a more common term
for this
John Knight
John
Stefan Schmiedl
> Thank you. That is the best article I have read in a very long time. I hope to be able to substitute ruby for lisp throughout the article. Do you think that is possible?
> John
hopefully, it will be.
but ruby has the disadvantage of becoming mainstream, hence
will not much longer be a secret weapon ...
and I don't think that yahoo will shell out 49,000,000 USD again
for an online shop system ;>
s.
>
> Stefan Schmiedl wrote:
>
> > you might want to consult with Paul Graham on this topic :-)
> >
> > http://www.paulgraham.com/avg.html
> >
--
Jakub Travnik
> Thank you. That is the best article I have read in a very long time. I hope to be able to substitute ruby for lisp throughout the article. Do you think that is possible?
> John
I have read that some time ago.
Ruby does not have any macros and lisp macros are the main point in the
article.
However block structures can be used usually instead.
Jakub Travnik
jabber://jt...@jabber.com
ICQ: 66770334
John Knight
I am not sure I understand how block structures replace macros.
They may replace closuress but macros?
Actually I am in over my head at the moment.
John
David Simmons
news:lypu677...@leia.mandrakesoft.com...
> "David Simmons" <david....@smallscript.net> writes:
>
> > As previously posted, you inspired me blatantly build on your idea and
write
> > a similar chart for our website.
> >
> > See http://www.smallscript.org/Language%20Comparison%20Chart.asp
>
> some remarks:
> - what do you mean with "multi-methods". AFAIK it's multiple dispatch, aka
> using runtime type of arguments for dispatching. Few languages have this,
C++
> doesn't nor C# (CLOS, dylan do have it).
Overloading is the static-binding (language) name. Multi-methods is the
dynamic-binding (language) name. Some authors prefer to write it as
"multimethods" e.g., Art of the Metaobject Protocol and various other
excellent lisp references.
Given that multi-methods are the dynamic-language name, only those languages
which are "dynamic" would be on the short list of multi-method
implementators [i.e., the lisp family of languages and those languages built
on top of lisp facilities; and SmallScript built on a general dynamic
language execution architecture].
However, be they statically or dynamically bound, the principle of the
facility is the same: in statically typed and analyzed/compiled languages
the binding (based on argument types) takes place at compile-time; in
dynamically typed languages the binding (based on argument types) takes
place at runtime. That principle being the use of all the argument types as
predicates in the binding process, rather than just using the
method/function name (and possibly the receiver's type).
This requires significantly more precise explanation to present the issues
properly for languages that have static typing and limited dynamic typing
facilities [which leads to type-case expressions that are runtime checked
rather than using modern-adaptive-dynamic binding-techniques developed in
the mid-80's].
This is "closely" related to my comments on C++ lacking "Calltime Dispatch
Binding". I.e., C++ has static-overloading but lacks
calltime-dispatch-binding facilities to be able to provide runtime/calltime
overloading. If it had such facilities then it could, at runtime, truly
dispatch on one or more parameters to a function (including <this> as a
parameter).
> - "Calltime Dispatch Binding": not in C++? weird
Strictly speaking, vtable dispatch is not a binding process at all. It is
just a vectored indirection that is invariant with respect to methods being
added, removed, calling context restrictions etc. Whereas a calltime
dispatch binding facility actually performs the binding at call-time based
on various runtime alterable characteristics.
> - what do you mean with "Tail Calling"? IMO it's an optimisation which
depend on
> the implementation. AFAIK many C++ implementations handle tail recursion
(gcc
> does it nicely since 2.96)
I did not know gcc had this; I've never tried it. However it is not part of
the C++ standard. By that measure. there are many different C++ extensions
that exist (incompatibly) across implementations for providing very useful
features.
w.r.t. tail-calls, (if you say that gcc implementation supports
tail-recursion calls, I certainly am interested in verifying that because I
could use it for some VM build work). However, I'm not really sure I see how
it (c++) could be doing this for anything other than calls to the current
method/function. Which is not general tail-recursion calling [otherwise one
could loosely claim that any language with a goto had tail-calling].
> - "templates" is the specific C++ terminology. generics is a more common
term
> for this
This item was provided by the original chart producer (Armin Roehrl -
http://www.approximity.com/ruby/Comparison_rb_st_m_java.html). I didn't
change it. However the C++ standard refers to them as templates [which we
all know fall under the general category of generic programming -- which
itself falls under the category of a macro system (in the true lisp/scheme
sense)].
P.S., the updated table is now maintained at:
http://www.smallscript.org/Language%20Comparison%20Chart.asp
-- Dave S. [www.smallscript.org]
Mark Hahn
I compiled ruby-fltk in microsoft visual C++ 5.0 and installed the resulting
rubyfltk.dll in C:\cygwin\usr\local\lib\ruby\1.6\i386-cygwin and removed the
old rubyfltk.so file.
When I do "require 'rubyfltk.dll'" I get this error:
in `require': dlopen: Win32 error 126 -
/usr/local/lib/ruby/1.6/i386-cygwin/rubyfltk.dll (LoadError)
What could cause this error? Is the cygwin compiled version of Ruby
compatible with DLL files?
Jakub Travnik
> After I sent my comment out, I started to think about the lack of macros in ruby.
> I am not sure I understand how block structures replace macros.
> They may replace closuress but macros?
> Actually I am in over my head at the moment.
> John
Hope you didn't forget link on that web site to more details:
http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt
"One way we used macros was to generate Html. There is a very
natural fit between macros and Html, because Html is a prefix
notation like Lisp, and Html is recursive like Lisp. So we had
macro calls within macro calls, generating the most complicated
Html, and it was all still very manageable."
--quote from link above
(A side note: function call regarding to parameters is in ruby
prefix notation too, just like in any other common language :-))
This can be done in dynamic object oriented language too,
with ruby blocks it is quite easy and pretty too.
look at cgi ruby library
some examples are at:
http://www.pragmaticprogrammer.com/ruby/articles/cgi.html
exmaple from the link above:
require "cgi"
cgi = CGI.new("html3") # add HTML generation methods
cgi.out{
cgi.html{
cgi.head{ "\n"+cgi.title{"This Is a Test"} } +
cgi.body{ "\n"+
cgi.form{"\n"+
cgi.hr +
cgi.h1 { "A Form: " } + "\n"+
cgi.textarea("get_text") +"\n"+
cgi.br +
cgi.submit
}
}
}
}
This is very nice code.
Do you think that the macros could be better
at generation of html? I don't.
Jakub Travnik
jabber://jt...@jabber.com
ICQ: 66770334 (deprecated)
Pixel
[...]
> Overloading is the static-binding (language) name. Multi-methods is the
> dynamic-binding (language) name. Some authors prefer to write it as
> "multimethods" e.g., Art of the Metaobject Protocol and various other
> excellent lisp references.
[...]
> However, be they statically or dynamically bound, the principle of the
> facility is the same: in statically typed and analyzed/compiled languages
> the binding (based on argument types) takes place at compile-time; in
> dynamically typed languages the binding (based on argument types) takes
> place at runtime. That principle being the use of all the argument types as
> predicates in the binding process, rather than just using the
> method/function name (and possibly the receiver's type).
beurk, i don't like this.
multiple dispatch is very seldom present in dynamic languages since the only
typed parameter is the object. dynamic languages with optional type annotation
can have multiple dispatch (dylan, CLOS).
>
> This requires significantly more precise explanation to present the issues
> properly for languages that have static typing and limited dynamic typing
> facilities [which leads to type-case expressions that are runtime checked
> rather than using modern-adaptive-dynamic binding-techniques developed in
> the mid-80's].
>
> This is "closely" related to my comments on C++ lacking "Calltime Dispatch
> Binding". I.e., C++ has static-overloading but lacks
> calltime-dispatch-binding facilities to be able to provide runtime/calltime
> overloading.
like nearly every OO languages, C++ has runtime dispatch only based on the
type of the object, not on the argument types. Dispatch on argument types is
decided at compile time. This is not multiple dispatch (also called
multi-methods)
cf the Castagna's nice paper http://citeseer.nj.nec.com/castagna95covariance.html
> If it had such facilities then it could, at runtime, truly
> dispatch on one or more parameters to a function (including <this> as a
> parameter).
Java, C#... are in the same category
http://people.mandrakesoft.com/~prigaux/overloading2.java
>
> > - "Calltime Dispatch Binding": not in C++? weird
>
> Strictly speaking, vtable dispatch is not a binding process at all. It is
> just a vectored indirection that is invariant with respect to methods being
> added, removed, calling context restrictions etc. Whereas a calltime
> dispatch binding facility actually performs the binding at call-time based
> on various runtime alterable characteristics.
i don't think the implementation of C++ should distinguish it from Java. Many
OO languages do not allow adding methods at runtime and have the same
behaviour as C++. Of course, in Ruby you can add methods at runtime and the
vtable trick is not possible.
>
> > - what do you mean with "Tail Calling"? IMO it's an optimisation which
> depend on
> > the implementation. AFAIK many C++ implementations handle tail recursion
> (gcc
> > does it nicely since 2.96)
>
> I did not know gcc had this; I've never tried it. However it is not part of
> the C++ standard. By that measure. there are many different C++ extensions
> that exist (incompatibly) across implementations for providing very useful
> features.
do optimisations have to be in a standard ??? the use of tail-recursion or not
does not alter the behaviour of a program until you reach stack overflow. But
you can say the same for many optimisations.
>
> w.r.t. tail-calls, (if you say that gcc implementation supports
> tail-recursion calls, I certainly am interested in verifying that because I
> could use it for some VM build work).
well, it works on
http://people.mandrakesoft.com/~prigaux/47.c
http://people.mandrakesoft.com/~prigaux/48.c
http://people.mandrakesoft.com/~prigaux/50.c
http://people.mandrakesoft.com/~prigaux/53.c
> However, I'm not really sure I see how
> it (c++) could be doing this for anything other than calls to the current
> method/function. Which is not general tail-recursion calling [otherwise one
> could loosely claim that any language with a goto had tail-calling].
i don't know what you call "general tail-recursion". Of course the poor C
compiler has hard time analysing things to proove the tail-recursion
optimisation is safe.
Stefan Schmiedl
> After I sent my comment out, I started to think about the lack of macros in ruby.
> I am not sure I understand how block structures replace macros.
> They may replace closuress but macros?
blocks and closures go along fine.
IMHO, you can emulate the lisp macro stuff with the various
.._eval methods quite well.
take a look at net/http.rb and try to find the definition for get &co.
define_http_method_interface :Get, true, false
define_http_method_interface :Head, false, false
define_http_method_interface :Post, true, true
define_http_method_interface :Put, false, true
looks just like the stuff I did with macros in lisp.
s.
David Simmons
> "David Simmons" <david....@smallscript.net> writes:
>
> [...]
>
> > Overloading is the static-binding (language) name. Multi-methods is
> > the dynamic-binding (language) name. Some authors prefer to write it
> > as "multimethods" e.g., Art of the Metaobject Protocol and various
> > other excellent lisp references.
> [...]
> > However, be they statically or dynamically bound, the principle of
> > the facility is the same: in statically typed and analyzed/compiled
> languages
> > the binding (based on argument types) takes place at compile-time;
> > in dynamically typed languages the binding (based on argument types)
> > takes place at runtime. That principle being the use of all the
> > argument types
> as
> > predicates in the binding process, rather than just using the
> > method/function name (and possibly the receiver's type).
>
> beurk, i don't like this.
Yes, but if you follow this principle it leads to much clearer understanding
of the problems one finds in most statically typed languages w.r.t.
covariance and overloading. There is only one correct set of semantics, and
it is broken in most static type language implementations.
>
> multiple dispatch is very seldom present in dynamic languages since
> the only typed parameter is the object. dynamic languages with
> optional type annotation
> can have multiple dispatch (dylan, CLOS).
That statement is a bit circular. Most dynamic languages do not support
multi-method binding/dispatch. Ergo, all the arguments to their methods are
of type <Object/any>.
For those languages which do provide multi-method dispatch there is often
quite heavy use of the facility for some problem domains and hence you must
look at particular code bases. Within core language libraries, the most
obvious examples of the use of multi-methods show up in numerics and to a
lesser degree in iterators and collections.
In dynamic languages which lack multi-methods, we see "double-dispatching"
(a poor-man's workaround) for receiver+1arg cases where all the types are
known up front at design time [i.e., no 3rd party development or late
deployment time integration issues].
I am not sure why you mentioned these generally well understood facts [at
least they are generally well understood within the dynamic language
implementation community].
>
> >
> > This requires significantly more precise explanation to present the
> issues
> > properly for languages that have static typing and limited dynamic
> typing
> > facilities [which leads to type-case expressions that are runtime
> checked
> > rather than using modern-adaptive-dynamic binding-techniques
> > developed
> in
> > the mid-80's].
> >
> > This is "closely" related to my comments on C++ lacking "Calltime
> Dispatch
> > Binding". I.e., C++ has static-overloading but lacks
> > calltime-dispatch-binding facilities to be able to provide
> runtime/calltime
> > overloading.
>
> like nearly every OO languages, C++ has runtime dispatch only based on
> the type of the object, not on the argument types. Dispatch on
> argument types is decided at compile time. This is not multiple
> dispatch (also called
> multi-methods)
>
> cf the Castagna's nice paper
> http://citeseer.nj.nec.com/castagna95covariance.html
Sorry, I could not access the paper on that site without an ACM online
library membership. Feel free to send me a PDF if available.
>
>
> > If it had such facilities then it could, at runtime, truly dispatch
> > on one or more parameters to a function (including <this> as a
> > parameter).
>
> Java, C#... are in the same category
I agree, they are broken. But <g> you are preaching to the choir; I am a
dynamic language advocate, it is where I have spent my time over the last
ten years pioneering new facilities and advancing the state of the art.
Note: I include scripting languages into the dynamic language category.
That's one reason why Microsoft asked me to get involved with the .NET
architecture and its support for dynamic languages. It is an activity that I
will be continuing to interact with Microsoft in evolving over the coming
years.
All the "crap" regarding genericity in Java [and C#] would never have been
an issue if they did away with (or offered alternatives to) the VTable
dispatch mechanism -- which is something I appear to be influencing the
thinking on at Microsoft. It would also be trivial to inherently provide
proper AOP if true predicate based calltime binding and dispatch was
performed. NOTE: I am being very careful to stay away from the potentially
dodgy term "dynamic binding" because, like the broad use [and now relatively
meaningless] term object-oriented, it has become rather polluted.
Similar issues occur with static language notions of sealed and final as
well as interfaces. And closely related is the need for selector
namespaces, which I invented in 1996. Which, to my great satisfaction, are
now going to be a part of the ECMAScript (JavaScript 2.0) standard. The
ECMAScript selector namespace design, as far as I known, is unrelated to my
work -- which is what makes it so satisfying because it means that
independent parties trying to solve similar problems came to the same
fundamental conclusions about its importance.
>
> http://people.mandrakesoft.com/~prigaux/overloading2.java
Sure, the example is clearly illustrating the problem. Static type binding
of dynamic type information does not work. I.e., languages which only have
static binding cannot provide proper semantics for method-implementation
selection based on argument types.
Dynamically typed languages with static language optimization features and
adaptive compilation can provide these features and do so at speeds that are
competitive with or better than C++. But, it is a much harder problem if
there is little or no declared type information; because general adaptive
compilation optimizations are hard.
Ideally, one wants a common language architecture that provides full dynamic
behavior, with optional declarative typing, solid type inferencing, static
compilation capabilities, and adaptive dynamic jitting facilities (which can
feedback to augment static compilation/pre-jitting). This is the focus of
the AOS Platform, the Microsoft .NET Platform, and others.
>
> >
> > > - "Calltime Dispatch Binding": not in C++? weird
> >
> > Strictly speaking, vtable dispatch is not a binding process at all.
> > It
> is
> > just a vectored indirection that is invariant with respect to
> > methods
> being
> > added, removed, calling context restrictions etc. Whereas a calltime
> > dispatch binding facility actually performs the binding at call-time
> based
> > on various runtime alterable characteristics.
>
> i don't think the implementation of C++ should distinguish it from
> Java. Many OO languages do not allow adding methods at runtime and
> have the same behaviour as C++. Of course, in Ruby you can add methods
> at runtime and the
> vtable trick is not possible.
It is worse than just describing C++ like mechanism as "the vtable-trick".
VTables are actually (demonstrably) slower than "true" (receiver only)
dynamic-binding-dispatch mechanisms. This fact is (reasonably well)
understood today. It is a reality that will increasingly be the case as long
as the gap between processor core speeds and L2 cache and memory speeds
continues to widen.
It is fairly easy to illustrate on the Intel processor family. I've posted
(on comp.lang.smalltalk within the last 12 months) at least two detailed
explanations showing the machine instructions, cycle-times, and benchmarks.
The originally published technique was developed by David Ungar and
published in OOPSLA papers in the mid-80's. It has been a standard part of
most jit-based Smalltalk implementations for the last ten years or so.
However, I intentionally have not published information on techniques I have
developed (on the AOS Platform VM) for hi-performance predicate based
(incl - multi-method) dispatching. Especially with regard to implementation
on the .NET platform, where I am still exploring with Microsoft [who needs
this technology as much as Sun/Java does].
NOTE: The AOS Platform VM is unrelated to the .NET technology. I have been
evolving the AOS Platform design for the last decade; and it is now in its
4th generation.
>
> >
> > > - what do you mean with "Tail Calling"? IMO it's an optimisation
> > > which
> > depend on
> > > the implementation. AFAIK many C++ implementations handle tail
> recursion
> > (gcc
> > > does it nicely since 2.96)
> >
> > I did not know gcc had this; I've never tried it. However it is not
> > part
> of
> > the C++ standard. By that measure. there are many different C++
> extensions
> > that exist (incompatibly) across implementations for providing very
> useful
> > features.
>
> do optimisations have to be in a standard ???
Of course not [but the chart was listing features of "languages" not
particular implementations]. I.e., to characterize them as a feature of the
"language" then they need to be offered in all "standard" implementations.
Otherwise, they are just a feature of a given implementation or dialect.
> the use of tail-recursion or not
> does not alter the behaviour of a program until you reach stack
> overflow. But you can say the same for many optimisations.
It also has significant impact on debugging, etc. However, that is beside
the point. What you are saying here does not address my comments back to you
on tail-recursion optimization in the "c++" language.
>
> >
> > w.r.t. tail-calls, (if you say that gcc implementation supports
> > tail-recursion calls, I certainly am interested in verifying that
> because I
> > could use it for some VM build work).
>
> well, it works on
>
> http://people.mandrakesoft.com/~prigaux/47.c
> http://people.mandrakesoft.com/~prigaux/48.c
> http://people.mandrakesoft.com/~prigaux/50.c
> http://people.mandrakesoft.com/~prigaux/53.c
>
> > However, I'm not really sure I see how
> > it (c++) could be doing this for anything other than calls to the
> current
> > method/function. Which is not general tail-recursion calling
> > [otherwise
> one
> > could loosely claim that any language with a goto had tail-calling].
>
> i don't know what you call "general tail-recursion". Of course the
> poor C compiler has hard time analysing things to proove the
> tail-recursion optimisation is safe.
I think we might be speaking about something without our having the same
definition of terms. Can you cook up a simple example (or some pseudo-code)
to illustrate what gcc can do?
Robert Feldt
> > cf the Castagna's nice paper
> > http://citeseer.nj.nec.com/castagna95covariance.html
>
> Sorry, I could not access the paper on that site without an ACM online
> library membership. Feel free to send me a PDF if available.
>
I get a link up in the right corner to a cached PDF. The link is long so
may not come out right but anyway:
Regards,
/Robert
Avi Bryant
> After I sent my comment out, I started to think about the lack of macros in ruby.
> I am not sure I understand how block structures replace macros.
> They may replace closuress but macros?
One common use of macros in Lisp and Dylan is to hide the use of
closures. For example, there's an idiom for resources such as files
that lets
(open-resource x)
(do-some-stuff...)
(close-resource x)
be expressed as
(with-resource x (do-some-stuff...))
If this were written as a function rather than a macro, it would have
to be
(with-resource x (lambda () (do-some-stuff...))
In ruby, the equivalent idiom uses a block, which is lighterweight
syntax than lambda and so doesn't seem as useful to wrap.
However, not all cases where closures are wrapped by macros in lisp
are as easily replicated in Ruby. For example, assuming Ruby blocks
introduced a new lexical scope (which they unfortunately don't, but
never mind), the expansion of a lisp let statement in ruby looks like:
proc{|x, y| do_something() }.call(a,b)
This can be improved to:
let(a,b){|x, y| do_something() }
but it still ain't as pretty as lisp.
And of course there are scores of uses for macros that have nothing to
do with closures. A classic one is embedding domain-specific
dialects, such as lispified HTML - the ruby cgi library is nice, but
it's not as clean or as general as the typical
(with-html
(html
(form :action 'foo'
(input :name 'bar')))
etc.
Avi
Pixel
[...]
> In dynamic languages which lack multi-methods, we see "double-dispatching"
> (a poor-man's workaround) for receiver+1arg cases where all the types are
> known up front at design time [i.e., no 3rd party development or late
> deployment time integration issues].
same in statical typing: http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html
> I am not sure why you mentioned these generally well understood facts [at
> least they are generally well understood within the dynamic language
> implementation community].
because your chart has a "yes" for multi-methods in C#/C++ !
[...]
> > cf the Castagna's nice paper
> > http://citeseer.nj.nec.com/castagna95covariance.html
>
> Sorry, I could not access the paper on that site without an ACM online
> library membership. Feel free to send me a PDF if available.
click on "Cached: PDF" (hail CiteSeer!)
>
> >
> >
> > > If it had such facilities then it could, at runtime, truly dispatch
> > > on one or more parameters to a function (including <this> as a
> > > parameter).
> >
> > Java, C#... are in the same category
>
> I agree, they are broken. But <g> you are preaching to the choir; I am a
> dynamic language advocate,
but the problem is not being dynamic or not: a statically typed language *can*
have multiple dispatch!
eg: Cecil, MultiJava (http://www.cs.washington.edu/homes/todd/papers/oopsla00.html)
adding multiple dispatch to java: http://citeseer.nj.nec.com/dutchyn01multidispatch.html
[...]
> All the "crap" regarding genericity in Java [and C#] would never have been
> an issue if they did away with (or offered alternatives to) the VTable
> dispatch mechanism
C++ has vtable and genericity (parametric polymorphism, aka templates).
I don't see the limitation that makes Java and C# not having genericity.
(AFAIK Java 1.4 will have generics)
>-- which is something I appear to be influencing the
> thinking on at Microsoft. It would also be trivial to inherently provide
> proper AOP if true predicate based calltime binding and dispatch was
> performed. NOTE: I am being very careful to stay away from the potentially
> dodgy term "dynamic binding" because, like the broad use [and now relatively
> meaningless] term object-oriented, it has become rather polluted.
>
> Similar issues occur with static language notions of sealed and final as
> well as interfaces. And closely related is the need for selector
> namespaces, which I invented in 1996. Which, to my great satisfaction, are
> now going to be a part of the ECMAScript (JavaScript 2.0) standard. The
> ECMAScript selector namespace design, as far as I known, is unrelated to my
> work -- which is what makes it so satisfying because it means that
> independent parties trying to solve similar problems came to the same
> fundamental conclusions about its importance.
apropos could you add some "alt=" to http://www.smallscript.net/ (is nicer for
links/lynx users)
it seems like SmallScript description is missing or??? All i can find is ugly
words (pricing, Microsoft, .asp's, Technology Preview...)
i couldn't find info about this "selector namespace", any link?
>
> >
> > http://people.mandrakesoft.com/~prigaux/overloading2.java
>
> Sure, the example is clearly illustrating the problem. Static type binding
> of dynamic type information does not work. I.e., languages which only have
> static binding cannot provide proper semantics for method-implementation
> selection based on argument types.
hum. C++ and Java do not have "only static binding".
[...]
> It is worse than just describing C++ like mechanism as "the vtable-trick".
> VTables are actually (demonstrably) slower than "true" (receiver only)
> dynamic-binding-dispatch mechanisms. This fact is (reasonably well)
> understood today. It is a reality that will increasingly be the case as long
> as the gap between processor core speeds and L2 cache and memory speeds
> continues to widen.
>
> It is fairly easy to illustrate on the Intel processor family. I've posted
> (on comp.lang.smalltalk within the last 12 months) at least two detailed
> explanations showing the machine instructions, cycle-times, and benchmarks.
> The originally published technique was developed by David Ungar and
> published in OOPSLA papers in the mid-80's. It has been a standard part of
> most jit-based Smalltalk implementations for the last ten years or so.
are you talking about http://www.sun.com/research/self/papers/type-feedback.html ?
the idea is quite simple: specialize for a given type of object to allow
inlining. In that case, to know which specialization to have, run-time
feedback is used. This applies well to JITs of course.
I don't see why it prooves that vtable is bad/slower. vtable can also benefit
from specialization. This is also why the default in C++ in no "virtual"
methods, so that performance is the best.
This is a well known, no?
In the ML family, the same happens when going from polymorphic functions
(needing boxing) to monomorphic functions (with unboxed data)
see for example:
- the SPECIALIZE pragma in ghc http://www.haskell.org/ghc/docs/4.04/users_guide/users_guide-5.html)
- type-based unboxing (Leroy) http://citeseer.nj.nec.com/88305.html
>
> However, I intentionally have not published information on techniques I have
> developed (on the AOS Platform VM) for hi-performance predicate based
> (incl - multi-method) dispatching. Especially with regard to implementation
> on the .NET platform, where I am still exploring with Microsoft [who needs
> this technology as much as Sun/Java does].
"Where Do You Want To Go Today?" ;p
Microsoft has a *lot* of people working on languages. Hopefully many are
allowed to publish their work (and even release GPL apps)
[...]
> > i don't know what you call "general tail-recursion". Of course the
> > poor C compiler has hard time analysing things to proove the
> > tail-recursion optimisation is safe.
>
> I think we might be speaking about something without our having the same
> definition of terms. Can you cook up a simple example (or some pseudo-code)
> to illustrate what gcc can do?
once again:
Mathieu Bouchard
> I tried to compiled an objective table to compare these OO languages.
> (typing, inheritance, garbage collection, ..)
> http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
> All mistakes are my mistakes :-), so don't flame me about mistakes;
> I will simply updated the table.
You write that Ruby is single-inheritance and CLOS is
multiple-inheritance, but both are actually mixin-inheritance, which is a
separate thing from both SI and MI. It shares many characteristics with
MI, but because of the different method-lookup algorithm, there are things
you can only do with MxI and some only with MI. (Ruby's "super" is
actually closer to "call-next-method" than to other languages' "super")
I don't know much about CLOS but I'd say "t" is the "root class" of CLOS
regarding method specialization. "t" is the type that includes everything
and "nil" is the type that includes nothing.
Regarding templates: you make a special note regarding Ruby, but that note
applies to more than just Ruby. Also change "you can create dynamic
classes" by "you can create classes at runtime" or "you can create classes
dynamically". And even though you can, there's a gap to be filled between
that and parametrized classes/types. (I do that in RubyX11)
Add a column for Perl 5:
Typing: mostly dynamic
R.a. to method names: yes
R.a. to class names: yes
R.a. to instance variable names: yes
Forwarding: yes
Metaclasses: no
Inheritance: multiple
access to super method: SUPER::methodName
root class: "UNIVERSAL" package
receiver name: $_[0]
private data: no
private methods: no
class variables: no (but what qualifies as a class var anyway?)
templates: no
garbage collection: reference counting
perl 6 is supposed to have both multiple and mixin inheritance. perl 6 is
still mostly vapourware, but i think there's an experimental version
("perl 5+i") that has that feature.
________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju
David Simmons
Hi Pixel,
In reading your reply I am frustrated by the sense that you are drilling [as
if I did not understand them] into the very issues I was presenting in broad
strokes, and which were too lengthy for me to explain [given my time and
activities] in the context of a newsgroup post. But, I will try to clarify
your items point by point.
>
> > In dynamic languages which lack multi-methods, we see
"double-dispatching"
> > (a poor-man's workaround) for receiver+1arg cases where all the types
are
> > known up front at design time [i.e., no 3rd party development or late
> > deployment time integration issues].
>
> same in statical typing:
http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html
I was not aware that someone was "bothering" to use RTTI (or templates
[macros]) to address this issue in C++. Given the importance of C++ I should
hardly be surprised. However (in broad terms), this is the problem with
implementing genericity in languages which only support static typing [as I
alluded to in my previous post regarding the languages Java and C#].
As I said in my previous post, the ideal is a language which has both static
and dynamic typing with overloading/multi-methods -- lacking that numerous
issues crop up. This is just a "facet" of that generics issue.
>
> > I am not sure why you mentioned these generally well understood facts
[at
> > least they are generally well understood within the dynamic language
> > implementation community].
>
> because your chart has a "yes" for multi-methods in C#/C++ !
You are leaving out key annotation information.
The chart says "yes (but restricted facilities)".
Now you could readily argue that it should have provided different wording
or more explanation [although this is intended to be an informal chart --
not a writeup comparing languages feature by feature]. But it would have
been "wrong" to say that it "did not" support "(overloading)" as taken from
the row-heading on the chart.
>
> [...]
>
> > > cf the Castagna's nice paper
> > > http://citeseer.nj.nec.com/castagna95covariance.html
> >
> > Sorry, I could not access the paper on that site without an ACM online
> > library membership. Feel free to send me a PDF if available.
>
> click on "Cached: PDF" (hail CiteSeer!)
Thanks (3 or 4 other people also clued me in on that :), I have the paper
now.
>
> >
> > >
> > >
> > > > If it had such facilities then it could, at runtime, truly dispatch
> > > > on one or more parameters to a function (including <this> as a
> > > > parameter).
> > >
> > > Java, C#... are in the same category
> >
> > I agree, they are broken. But <g> you are preaching to the choir; I am a
> > dynamic language advocate,
>
> but the problem is not being dynamic or not: a statically typed language
*can*
> have multiple dispatch!
> eg: Cecil, MultiJava
(http://www.cs.washington.edu/homes/todd/papers/oopsla00.html)
>
I never debated that; quite the opposite I alluded that some statically
typed languages exist with support for type-cases and dynamic typing [and I
well aware of Cecil language and Vortex compiler technologies -- Cecil and a
number of other languages are mentioned on the web page chart at
http://www.smallscript.org/Language%20Comparison%20Chart.asp].
But you've switched the example away from the only-statically-typed
languages we had under discussion [Java, C#, C++]. Again, the point is that
ideally one wants a language that unified its world-type-object-view with
both static and dynamic typing and supports execution-engine/compilation
optimization to select/choose (static) overloading/(and dynamic)
multi-method invocation mechanics as appropriate, and thereby enables
efficient correct genericity.
This is one unified idea, that crops up with many variant names [and
solution efforts] because so many languages exist with (differing) partial
capabilities [thus spawning many unique workarounds with provisos] -- rather
than having a generalized object model view [semantics] to address
types-in-the-face-of-objects uniformly [which is where my interest has been
focused].
Good idea; I was lamenting I did not put an explicit link regarding
SmallScript into the original post. OTOH QKS Smalltalk [(www.qks.com --
SmalltalkAgents-IDE) which I designed and was the chief architect for] is
basically defunct and is no longer downloadable/purchasable. So you can't
play with it to see the ideas and concepts in action. SmallScript is my
personal evolution in thought within this space and SmallScript is still
very much a work in progress. I've been deeply involved in both business
issues and design and implementation of virtual-machines, language design,
frameworks, and tools which has left me little or no time to focus on
publishing papers [let alone writing a book or contributing to the
documentation -- until I recently began forcing myself to].
>
> it seems like SmallScript description is missing or??? All i can find is
ugly
> words (pricing, Microsoft, .asp's, Technology Preview...)
>
> i couldn't find info about this "selector namespace", any link?
You won't find a link on the SmallScript site at this time. However, I just
made an fairly detailed post on this topic area. The post can be found on
comp.lang.ruby as "Selector Namespaces: A Standard Feature For Smalltalk?".
>
> >
> > >
> > > http://people.mandrakesoft.com/~prigaux/overloading2.java
> >
> > Sure, the example is clearly illustrating the problem. Static type
binding
> > of dynamic type information does not work. I.e., languages which only
have
> > static binding cannot provide proper semantics for method-implementation
> > selection based on argument types.
>
> hum. C++ and Java do not have "only static binding".
I think we both understand the issue. The problem here is that the
"semantics" of the term dynamic-binding have been polluted/overloaded. So,
as with many topics in comparing languages with regard to "static" and
"dynamic" subjects, we quickly get bogged down in terminology as we try to
use that terminology to explain/discuss concepts. If all parties don't have
a clear concensus on the definitions of the terminology the discussions
rapidly digress into areas that are the result of that lack of concensus.
So, ignoring the terminology:
C++ and Java "typically" (but not always) implement virtual functions using
vtables. Where a vtable is an array of function pointers to virtual methods
associated with a given type.
These languages are not only statically typed, they are based on the concept
of static binding of type information as well. In an effort to be "object
oriented" [whatever that means] they attempt to provide [OO] polymorphism
using vtables which are a weak/limited solution to providing polymorphism
over one-type (the message receiver).
For static binding based on type information, this means that at compile
time the decision is made as to what method to invoke based on the types of
the arguments. The partial-polymorphic-solution exception is built by
assuming that all types are known at compile time. And that, therefore,
tables can be constructed containing common methods for type-trees based on
the "type of the receiver <this>".
So one gets a binary-deployment-system that cannot break those compile-time
rule of all types known at runtime [it is not dynamic/extensible at runtime
and so is brittle], and which also cannot address the problem of
polymorphism over the arguments to methods [which leads problems in
implementing/supporting genericity, etc because the model is based entirely
on static knowledge]. Some languages, like ML, have taken great strides to
addressing this problem and ensuring correct behavior but I (currently)
think it requires supporting both a static and dynamic type and binding
model.
So, back to exploring issues in the vtable approach. As mentioned before it
is based/built-upon static knowledge of the available set of types. It's
indirection mechanism is therefore based on static knowledge, which makes it
a static (lookup table) binding mechanism. I.e., the vtable-index [a
first-degree binding abstraction approach -- as opposed to a selector-object
in dynamic language which is a second-degree binding abstraction] is
statically bound into source and thus [among other things] precludes
handling dynamic [binding impact] changes to the classes and methods. I.e.,
vtables are limited in two semantic ways and additionally in one technical
way.
1. Semantically it only works for whole-cloth programs where no schema
changes [in the binary/compiled-form] will occur to class, namespace, or
methods available within the program [that's what makes them static
languages]. Why? Because if such changes occur the vtable layouts may need
to be changed, the call-sites that use indexed-lookup will have to have the
indices changed [not even considering the issues of the methods themselves
which have optimized-away/unfolded encapsulation of object structure, etc].
None of which is possible because all the necessary meta-information was
thrown away at compile-time [many things are not objects, most things have
no self-describing information (i.e., nominal to no reflection
facilities) -- RTTI being C++'s only facility].
2. In a unified OO view, there are no "pure-functions", because classes [or
prototypes], namespaces, etc are all objects and functions are just methods
on those classes [or prototypes] and namespaces. All operations semantically
become about the messages that objects can understand (perform). The
concerns about physical-layout/structure of a type vanish leaving us
[humans] only concerned [in general] with the message vocabulary [i.e.,
behavior/interfaces].
The compilers are where the optimization and knowledge about physical
representation become paramount for performance and external inter-op [and
humans only care when they are meshing with the boundary points -- usually
to create optimized small algorithms; an act which requires greater
attention and focus than one would normally want to have to put into
describing a problem to the computer via a programming language -- generally
we want our programming language to be capable of being as transparent as
possible so we can focus on the problem domain itself rather than the
problem of describing the problem to the computer].
Parameterized types in object definitions are relevant to humans in terms of
contractual (behavioral) adherance. To the compiler(s) they allow
optimizations to be achieved for better performance and resource utilization
[potentially as guided by a human author]. Which gets us back to genericity
and best efforts at being informed "statically" about design time
behavior-binding (type) errors in our use of contracts as opposed to runtime
contractual behavior-binding (type) errors that can always be detected in a
well designed language execution architecture. Which leads us into the
discussion of genericity in-static-only-binding-type systems [which have the
potential to yield optimum performance at a price in terms of correct
behavior and/or expressiveness], in-dynamic-only-binding-type systems [which
have the potential to yield correct at a price in terms of performance], and
in systems that offer both forms of binding [which has the potential to
yield both correct behavior and optimum performance].
Proponents of static-typing and correctness argue the virtues of design-time
detection. Proponents of dynamic-typing argue the virtues of unit-testing
and the dangers of reliance on static-checking of type-bindings as a
substitute for verifying interop relations semantics inherent in any system
of basic complexity. Both parties have valid and good points and neither are
wrong in my view. Both are addressing the same problem space with different
techniques; and both have been shown to eliminate the large proportion of
defects [albeit leaving different types of defects undetected]. But, in my
view, the significance is in the human "level of effort" factor in
expressing an original problem, coming later to understand such a design,
and later still working with an existing design to maintain or extend it.
** sigh, I seriously digressed [and now I will be in a deep rathole as
people beat me up for errors and/or disagreements with my assertions] **
#2 is principally that given that it is desireable to discriminate a
function's implementation based on the types of the arguments, vtable as a
polymorphic solution offer no mechanism of support for dispatching to a
type-specific implementation based on polymorphism amongst the arguments to
a function/method. The general approach is to use hand-crafted secondary
dispatch [which for arity-1/1-arg methods is called double-dispatch].
3. The technical issue is that vtables are slower (on current hardware
technology) than using adaptive jitting techniques with self-modifying code.
Primarily due to the cost of indirectly accessing memory to obtain an
address from a vtable which precludes processors from using eager/optimistic
prediction; where accessing the memory also results in bouncing from
L1-cache to L2-cache to primary memory [and that is increasingly expensive
as the timing gap between those forms of memory increases -- similar in
nature to the impact on design that one observed in algorithms designed
based on the 50's-70's problem of tape, disk, ram gaps].
*. In a just-in-time binding approach pioneered in Smalltalk during the mid
80's, one uses self-modifying code and assumes that most call sites are not
polymorphic [which is generally true]. If they are polymorphic, then that
breaks down into the case of having a low-degree of polymorphism [say 2-10
types] and the case of having a large degree of polymorphism which
literature in this area popularly terms mega-morphism. See OOPSLA papers
from the mid-80's to early 90's. This technique was the basis for the design
of the self-language, which in turn led to the design of the Animorphic
HotSpot VM/Execution-Engine/Runtime technology for Smalltalk; which in turn
was acquired by Sun to try and speed Java [JVM] up.
What has not, to my knowledge, been applied is a more generalized solution
of the same technique multiple-dispatch (overloading/mult-methods). I have
done it for both my own general-purpose dynamic-language virtual machine
(AOS Platform), and the Microsoft .NET platform (less-optimally through IL).
I must presume that someone must have implemented my technique before;
almost certainly someone in the lisp family community. However, it is
unlikely that it has also been optimized for hi-performance execution with
important newer binding predicates including sandboxing and selector
namespaces.
Providing hi-performance dynamically-dispatched-multi-methods has
significant impact on scripting languages and their ability to evolve into
full fledged languages that compete in features and performance with
mainstream languages today such as C, C++, Java, [C# will soon be in this
group if it is not already], Pascal-derivatives, etc. This is especially
important because there are, by most accounts, 10-20 times more people and
programs using scripting languages and techniques and that number is likely
increasing as cost factors and training/experience come into play.
I think, based on your comments, that you are not aware of what I have been
doing for the last ten years or so. One of my professional areas of
specialty is the design of virtual machines. Your comments sound like the
kind of things I would have written as responses to you <g>.
As to the bad/slower, in the last 12 months, I wrote two different threads
of discussion on this topic [in comp.lang.smalltalk] describing the
instructions, cycles, and benchmark information. I also made reference to
that fact somewhere in this current thread of discussion. Where I also
mentioned that I had not published information on the much more general
techniques (which I suspect I have pioneered) for hi-performance dynamic
dispatch of common/important predicates with extensibility for general
predicate dispatch through Dynamic-AOP/Managed-Object facilities in the
object-model of the AOS Platform [the VM architecture I designed and have
been evolving for the last ten years] as well as its related peer/work, an
enabler for the Microsoft .NET platform.
>
> In the ML family, the same happens when going from polymorphic functions
> (needing boxing) to monomorphic functions (with unboxed data)
> see for example:
> - the SPECIALIZE pragma in ghc
http://www.haskell.org/ghc/docs/4.04/users_guide/users_guide-5.html)
> - type-based unboxing (Leroy) http://citeseer.nj.nec.com/88305.html
>
> >
> > However, I intentionally have not published information on techniques I
have
> > developed (on the AOS Platform VM) for hi-performance predicate based
> > (incl - multi-method) dispatching. Especially with regard to
implementation
> > on the .NET platform, where I am still exploring with Microsoft [who
needs
> > this technology as much as Sun/Java does].
>
> "Where Do You Want To Go Today?" ;p
>
> Microsoft has a *lot* of people working on languages. Hopefully many are
> allowed to publish their work (and even release GPL apps)
<g> I know.
As a 3rd party, I and others have been been fortunate to have the
opportunity to interact [and influence] quite a few of them [it would be
nice to be able to observe the same attitude and opportunity to have an
influence on Sun folks]. Of course, Microsoft has a clear business
objective, and I both hope and greatly fear they will be very successful in
achieving based on their approach [the word trepidation has constantly been
in my thoughts since I first got involved with Microsoft on the .NET project
in 1999].
The real challenge for scripting and dynamic languages lies in the
predominance and momentum of ideas and beliefs regarding type-theory and
statically-typed languages; and the relative/disproproportionate lack
thereof for dynamic languages (especially OO languages like Smalltalk, as
opposed to functional dynamic languages like scheme).
>
> [...]
>
> > > i don't know what you call "general tail-recursion". Of course the
> > > poor C compiler has hard time analysing things to proove the
> > > tail-recursion optimisation is safe.
> >
> > I think we might be speaking about something without our having the same
> > definition of terms. Can you cook up a simple example (or some
pseudo-code)
> > to illustrate what gcc can do?
>
> once again:
>
> http://people.mandrakesoft.com/~prigaux/47.c
> http://people.mandrakesoft.com/~prigaux/48.c
> http://people.mandrakesoft.com/~prigaux/50.c
> http://people.mandrakesoft.com/~prigaux/53.c
>
Ooops, my goof. I (missed) did not notice that reference in my effort to
respond to your previous post. [arghh, sorry about that -- I have a nack for
writing posts now and again that spur a very large number of conversations
and I get sloppy trying to respond to them and keep myself on a time
budget].
Now I've seen the gcc example :). It is optimizing calls from within a
function to itself [nice syntactic sugar for goto that I was alluding to in
my previous post].
By the way, that is a kind of wack example, that assumes knowledge of the
stack frame layouts [which are processor dependent -- especially in light of
differing register allocations].
Assuming all variables (args and locals) are allocated on the stack. And
that they are allocated linearly. And that f() does not use any stack space
itself for variables and arranges for the return-address to be "protected"
then:
n t->
---- ----
10 t1[0]
9 ? o "presumably"
8 ? n
7 ? m
6 ? l
5 ? k
4 ? j
3 ? i
2 ? g "presumably if no other stack use in f()"
1 ? f
0 ? e "not touched"
However the "reset()" code which is "decrementing" <t> via "t--" seems like
very broken (dangerous) way to test the recursion. I.e., it seems more like
this example tests assumptions about GCC variable allocation and stack usage
than it does anything to do with tail-recursion optimization.
In theory, t[2] is either walked over or is actually pointing at the
return-address not <g> unless the compiler did some special mangling to
move/protect the return address on the stack [like keeping it in a
register].
---
Why not a simple recursion test like:
int n=0x7FFFFFFF; char *p=0;
void recurse()
{
char c;
if (&c != p) {
printf("Stack Consumed At <n>: %d [%lx vs %lx]\n",n, &c, &p);
p = c;
}
if (--n > 0) recurse();
// Extra here to prevent compiler optimizing
// <c> away before calling recurse()...
p = c;
}
main()
{
recurse();
}
Am I correct in assuming that gcc has no global/module optimizer mechanism
for addressing the general tail-recursion case of "a calls b" with "b calls
a", etc?
-- Dave S. [www.smallscript.com]
Joel VanderWerf
> However, not all cases where closures are wrapped by macros in lisp
> are as easily replicated in Ruby. For example, assuming Ruby blocks
> introduced a new lexical scope (which they unfortunately don't, but
> never mind), the expansion of a lisp let statement in ruby looks like:
>
> proc{|x, y| do_something() }.call(a,b)
>
> This can be improved to:
>
> let(a,b){|x, y| do_something() }
>
> but it still ain't as pretty as lisp.
There is also
for x,y in [["a","b"]] do z=x+y end
Syntax is prettier, but this example reinforces your point about lexical
scope and blocks--'z' stays in scope.
> And of course there are scores of uses for macros that have nothing to
> do with closures. A classic one is embedding domain-specific
> dialects, such as lispified HTML - the ruby cgi library is nice, but
> it's not as clean or as general as the typical
I'd vote for some kind of hygienic macro in Ruby, so we could create
embedded languages with clean, idiomatic syntax.
--
Joel VanderWerf California PATH, UC Berkeley
mailto:vj...@path.berkeley.edu Ph. (510) 231-9446
http://www.path.berkeley.edu FAX (510) 231-9512
Thomas Gagne
Native Threads - isn't this an implementation issue? Doesn't Smalltalk MT use
native threads? I personally believe this is a ding against VW.
Foreign Function Interface - ST/X does a nice job of this. Heck, you can
write C code inside methods! Is it necessary for a language to define how it
interacts with the stacks of other languages and their runtime environments?
Is it C's responsibility to know how to interface with Fortran, or is the fact
that some vendor's implementations of both languages' runtime environments
share common stack rules?
Where is support for blocks? How many languages support that? It's certainly
a useful language feature.
Should Value Types be a native language feature? ST/X creates structs quite
nicely using ByteArray with great accessors code. I've done a similar thing
in VW. Does it have to be a language feature? Must a language define every
stinking thing a programmer might do, or should that be the responsibility of
standard library features? C doesn't define a GUI interface, and neither
should *any* language if you ask me. GUIs exist only in an environment that
includes them, and languages must exist without them. All they need is a
compiler/interpreter. Access to GUIs, relational databases, HTTP, SMTP, etc.
are library problems, not language problems.
Certificate and Security mechanisms - I guess I need an explanation on that.
On my computer (at least) security is the responsibility of the operating
system. It's responsbile for making sure people only have access to what
they're supposed to regardless what language a program was written in. In the
database world my database keeps track of who's allowed to do what regardless
of what language is used. Why should this be a language feature? How would
such a language features be useful if not supported/implemented by other other
languages used on the same machine/environment?
Isn't RegEX supported in a VW parcel? Why would that be a language feature?
How big a book do you want to write to teach people how to use a language?
Would a student need to read a chapter that includes discussion on
startup/compile/execute/shutdown speed? How about a chapter on the language's
deployment footprint? Should .net languages include the entirety of Windows
as part of their footprint?
I appreciate everything you've done for Smalltalk, but your table is more
propaganda than anything. Maybe you'd rather build a chart comparing
Smallscript to specific language environments from specific vendors. If you
want to include the features vendors choose to include/exclude then your chart
would make more sense.
--
.tom
Ned Konz
> David, your table seems to mix language features with library features.
>
> Native Threads - isn't this an implementation issue? Doesn't Smalltalk MT
> use native threads? I personally believe this is a ding against VW.
MT uses native threads, but only works on Win32 systems, which have their own
threading model.
Cross-platform systems (like Ruby) do better when they provide their own
threading (since the target system may not provide a threading model at all,
or it may be substantially different than what is needed).
--
Ned Konz
currently: Stanwood, WA
email: n...@bike-nomad.com
homepage: http://bike-nomad.com
David Simmons
news:3C024CC3...@ameritech.net...
> David, your table seems to mix language features with library features.
>
> Native Threads - isn't this an implementation issue? Doesn't Smalltalk MT
use
> native threads? I personally believe this is a ding against VW.
Keep in mind that I extended a chart I obtained from the Ruby comunity.
Second, and perhaps more importantly, the Smalltalk column is for
"Smalltalk-80" [you know, the way the language was 20 years ago when many of
these other languages did not exist or were mere shadows of their
capabilities today].
The chart does not [by intention] have a column for the ANSI Standard
"Smalltalk-98", which to my view, was less of a standard than one would have
liked in terms of unifying and strengthening the language. Which is another
way of saying that, like scheme and its many dialects, Smalltalk dialects
are individually very strong in some (but not all) key areas and they have
great [mature] facilities, but the language itself cannot claim many of
those elements as being "standard".
In the world of components, scripting, and server systems built on them, the
ability to run the entire execution architecture as plug-in component and
integrate with native threading models is very important. It is a challenge
that classic Smalltalk-80 does not adequately address; various dialects
including VW have made great strides in this area but we're still not on the
leading edge of this curve.
>
> Foreign Function Interface - ST/X does a nice job of this. Heck, you can
> write C code inside methods! Is it necessary for a language to define how
it
> interacts with the stacks of other languages and their runtime
environments?
> Is it C's responsibility to know how to interface with Fortran, or is the
fact
> that some vendor's implementations of both languages' runtime environments
> share common stack rules?
Don't confuse the Smalltalk-80 chart capabilities. Again, various dialects
do this to a lesser or greater degree. QKS Smalltalk had this feature from
day-1 when it went into the first users hands 1992. Smalltalk MT has pretty
transparent facilities for COM-ActiveX, Dolphin looks to have even better
facilities. The problem is that these things are dialect specific; which is
why I did not add a Smalltalk-98 column -- I could not say much about how it
is different from Smalltalk-80 so it is better to stick with leaving the
Smalltalk-80 column -- and let SmallScript (a dialect of Smalltalk-98)
stand-in as the placeholder promoting Smalltalk today since it can answer
almost every question with a solid/good response.
SmallScript's Smalltalk facilities provide inline C/C++/Assembly directly
with no special locking, dereferencing, etc. And it also allows direct cut
and paste of enums, #defines, and VB/JScript/C++ function/method
invocations; as well as direct access to all functions in a DLL merely for
dynamically declaring the dll name in a class/namespace. It doesn't really
get much better than that.
>
> Where is support for blocks? How many languages support that? It's
certainly
> a useful language feature.
Blocks are a form [the Smalltalk name for the general concepts] of "closures
and continuations".
>
> Should Value Types be a native language feature? ST/X creates structs
quite
> nicely using ByteArray with great accessors code. I've done a similar
thing
> in VW. Does it have to be a language feature? Must a language define
every
> stinking thing a programmer might do, or should that be the responsibility
of
> standard library features? C doesn't define a GUI interface, and neither
> should *any* language if you ask me. GUIs exist only in an environment
that
> includes them, and languages must exist without them. All they need is a
> compiler/interpreter. Access to GUIs, relational databases, HTTP, SMTP,
etc.
> are library problems, not language problems.
Again, don't confuse Smalltalk-80 with current dialects. I put SmallScript
in as the "stand-in" for modern Smalltalks because none of these things is
covered "standardly/uniformly" in Smalltalk today.
Dealing with structs is obviously important and it should be easy to do.
This area is essential for broad/general interop within a multi-language
platform like .NET. It is an area that most scripting languages (and dynamic
languages) handle quite poorly because they typically lack notions of
declarative (optional) typing.
>
> Certificate and Security mechanisms - I guess I need an explanation on
that.
> On my computer (at least) security is the responsibility of the operating
> system. It's responsbile for making sure people only have access to what
> they're supposed to regardless what language a program was written in. In
the
> database world my database keeps track of who's allowed to do what
regardless
> of what language is used. Why should this be a language feature? How
would
> such a language features be useful if not supported/implemented by other
other
> languages used on the same machine/environment?
I'm sorry to punt but there are plenty of resources on the web and elsewhere
to learn and read about the rationale for and intent behind
certificates/digital-signatures.
>
> Isn't RegEX supported in a VW parcel? Why would that be a language
feature?
> How big a book do you want to write to teach people how to use a language?
> Would a student need to read a chapter that includes discussion on
> startup/compile/execute/shutdown speed? How about a chapter on the
language's
> deployment footprint? Should .net languages include the entirety of
Windows
> as part of their footprint?
Hmm. Scripting languages (Perl, Python, Ruby, to name a few) have an
enormous user base [and each is individually much more successful and
growing than Smalltalk or say Scheme had been in recent years]. Those
languages have, perhaps, four or five major characteristics (almost all of
which classic Smalltalk lacks). One of those characteristics is their
specific capabilities for processing text and that is largely tied to their
integration of RegEx facilities into the language. I suggest you look at
some of these languages, how they are being used, and their level of success
and popularity. I think that you'll find answers to the kind of questions
you are raising here.
>
> I appreciate everything you've done for Smalltalk, but your table is more
> propaganda than anything. Maybe you'd rather build a chart comparing
> Smallscript to specific language environments from specific vendors. If
you
> want to include the features vendors choose to include/exclude then your
chart
> would make more sense.
>
I'm sorry you feel that way. I think you are focusing, on me, your
frustration with Smalltalk-80 and the negative legacy it has cast over
smalltalk implementations today. However, I can assure you that the
frustration and pain I've felt about that legacy is far, far greater than
yours -- it played significant role in hurting business opportunities for
QKS/SmalltalkAgents and has consistently guided my professional focus over
the last ten years -- ultimately it is what led me to start over and build
SmallScript from scratch. My chart is, honestly, a mere shadow of the weak
items said about Smalltalk-80 in almost every other chart I've seen on the
web, or published in books and magazines.
The problem here is that we cannot make a chart with the title
"Smalltalk-98" and put all this stuff down as "standard"; in that light we
are better off leaving a column on what we had 20 years ago [when most of
the other languages didn't exist or were mere shadows of where they are
today]; and then skirting the issue by hiliting what an implementation of
Smalltalk-2001 can do today [especially since, in comparison to other
scripting languages, it has excellent answers to the requisite feature
comparison items -- since addressing those items were a fundamental part of
its design goals]. This also makes more sense, because SmallScript is not
just a Smalltalk implementation; it is also a new language and includes an
execution architecture that was designed to support (compile/run) multiple
dynamic (incl scripting) languages.
Somehow you sound like your suggesting that I should load the chart up with
each of the Smalltalk dialects, or I should remove the Smalltalk-80 column.
Loading a chart with all the current dialects would be innapropriate since
that is not done for the other languages. Removing Smalltalk-80 would also
have negative ramifications since it would: (a) not stand to correct the
fairly grievous wrongs in other Smalltalk-80 charts; (b) it would
underscore/mislead readers into thinking that SmallScript represented the
entire category of "Smalltalk" when it is in fact, merely a dialect which
has numerous features not found in other dialects.
Before you beat SmallScript up and tout the capabilities of Smalltalk by
telling me that dialect-a has feature-1 and dialect-b has feature-2; take a
look at SmallScript which as a single dialect has each of those features
[which is really the point]. AND, I want to be very clear, the chart came
from the scripting language world where programmers were comparing features
relevant to the scripting and component based software development process.
There are many "development process" features, which are common to most
Smalltalk implementations, which SmallScript in its basic/core form
(currently) does not provide [by intention]. Which is another way of saying
that SmallScript is by no means the best full featured Smalltalk [actually
it is far from it -- and it is a work in progress]; I would have said the
strongest players in this space on a user-base, feature-set,
commercial-level were Cincom VW, IBM VA, Dolphin ST, etc.
OTOH, rather than criticizing my efforts to "correct" and "update" the world
on where Smalltalk (collectively) stands, you could create a chart comparing
all the Smalltalk dialects using my suggested rows [and add your own]. I
would be more than happy to either put the chart on my site or to make a
link to it.
If you want to criticize, I encourage it. But at least sign up to explore
the SmallScript seed so that the criticism will be focused and hit home in
places that are under my control [I am not responsible for the larger world
view of Smalltalk-80 (and the muddled view it casts over Smalltalk today)].
Alternatively, you could sit down and write a book on Smalltalk-98 or
Smalltalk-2001 which would finally result in the academics and other
language folks revising all their books and charts to get rid of the bloody
irritating smalltalk-80 comparisons. I've wanted to do that for a long time
now, but since I cannot write a good collective work about a Smalltalk
standard [other than ANSI-98 which as I've alluded to, would probably do
more harm than good since its been 18 years since the 80 standard and based
on the ANSI standard vis-a-vis what is relevant in these other modern net
enabled languages we could not say competively strong things], I'm settling
for the much harder process of creating a new language which is a superset
of Smalltalk, and then working to make it freely available and looking
forward to publishing a definitive book called SmallScript-2002.
-- Dave S.
>
> --
> .tom
>
David Simmons
news:200111261625...@helium.ruby-lang.org...
> On Monday 26 November 2001 06:46 am, Thomas Gagne wrote:
> > David, your table seems to mix language features with library features.
> >
> > Native Threads - isn't this an implementation issue? Doesn't Smalltalk
MT
> > use native threads? I personally believe this is a ding against VW.
>
> MT uses native threads, but only works on Win32 systems, which have their
own
> threading model.
And, significantly predating Smalltalk MT, QKS Smalltalk [aka
SmalltalkAgents] (1991-1998) had portable pre-emptive multi-threading across
both its Mac [green-threads (native threads appeared later on the Mac)] and
Win32 [native-threads] platforms.
The column's question(s) are ("standard" implementations language [not just
one dialect]): first, there is "portable" threading model; second, do the
portable facilities integrate-with/layer-on-top-of "native" threads?
====
As to library features, as I have been so recently told (of late) in
SmallScript feedback, quite a number of people take the strong [and, in my
opinion, partially correct] view that libraries and tools are a key part of
the collective elements that form a (dynamic) language. I.e., historically
in most dynamic language systems the frameworks and IDE were an integral
element and play a key role in the development process and thereby define
the language and its capabilities/productivity for its users.
>
> Cross-platform systems (like Ruby) do better when they provide their own
> threading (since the target system may not provide a threading model at
all,
> or it may be substantially different than what is needed).
Classic Smalltalk-80 has had cross-platform fully portable threading for
some 20 years. Unfortunately, as a pioneering language in many areas, one
often finds that it created terminology and syntax forms before the rest of
the world did [as such, Smalltalk's terminology is often different from what
are now popularly accepted terms for the same concepts] which frequently
adds to the confusion/errors-made in comparing it with other languages.
In Smalltalk-80, what we call "green-threads" today, are what it has always
called "processes". Over the years, various implementations over the years
have made them "safely-pre-emptive" although most have not because it
results in the class-library (frameworks) being non-thread-safe [noting that
the language does not intrinsically support notions of pre-emptive
multi-threading and so its libraries are not designed accordingly --
although at least one dialect was -- QKS Smalltalk from which SmallScript
draws its heritage].
-- Dave S. [www.smallscript.org]
David Simmons
As to library features, as I have been so recently told (of late) in
SmallScript feedback, quite a number of people take the strong [and, in my
opinion, partially correct] view that libraries and tools are a key part of
the collective elements that form a (dynamic) language. I.e., historically
in most dynamic language systems the frameworks and IDE were an integral
element and play a key role in the development process and thereby define
the language and its capabilities/productivity for its users.
>
> Native Threads - isn't this an implementation issue? Doesn't Smalltalk MT
use
> native threads? I personally believe this is a ding against VW.
Keep in mind that I extended a chart I obtained from the Ruby comunity.
Second, and perhaps more importantly, the Smalltalk column is for
"Smalltalk-80" [you know, the way the language was 20 years ago when many of
these other languages did not exist or were mere shadows of their
capabilities today].
The chart does not [by intention] have a column for the ANSI Standard
"Smalltalk-98", which to my view, was less of a standard than one would have
liked in terms of unifying and strengthening the language. Which is another
way of saying that, like scheme and its many dialects, Smalltalk dialects
are individually very strong in some (but not all) key areas and they have
great [mature] facilities, but the language itself cannot claim many of
those elements as being "standard".
In the world of components, scripting, and server systems built on them, the
ability to run the entire execution architecture as plug-in component and
integrate with native threading models is very important. It is a challenge
that classic Smalltalk-80 does not adequately address; various dialects
including VW have made great strides in this area but we're still not on the
leading edge of this curve.
>
> Foreign Function Interface - ST/X does a nice job of this. Heck, you can
> write C code inside methods! Is it necessary for a language to define how
it
> interacts with the stacks of other languages and their runtime
environments?
> Is it C's responsibility to know how to interface with Fortran, or is the
fact
> that some vendor's implementations of both languages' runtime environments
> share common stack rules?
Don't confuse the Smalltalk-80 chart capabilities. Again, various dialects
do this to a lesser or greater degree. QKS Smalltalk had this feature from
day-1 when it went into the first users hands 1992. Smalltalk MT has pretty
transparent facilities for COM-ActiveX, Dolphin looks to have even better
facilities. The problem is that these things are dialect specific; which is
why I did not add a Smalltalk-98 column -- I could not say much about how it
is different from Smalltalk-80 so it is better to stick with leaving the
Smalltalk-80 column -- and let SmallScript (a dialect of Smalltalk-98)
stand-in as the placeholder promoting Smalltalk today since it can answer
almost every question with a solid/good response.
SmallScript's Smalltalk facilities provide inline C/C++/Assembly directly
with no special locking, dereferencing, etc. And it also allows direct cut
and paste of enums, #defines, and VB/JScript/C++ function/method
invocations; as well as direct access to all functions in a DLL merely for
dynamically declaring the dll name in a class/namespace. It doesn't really
get much better than that.
>
> Where is support for blocks? How many languages support that? It's
certainly
> a useful language feature.
Blocks are a form [the Smalltalk name for the general concepts] of "closures
and continuations".
>
> Should Value Types be a native language feature? ST/X creates structs
quite
> nicely using ByteArray with great accessors code. I've done a similar
thing
> in VW. Does it have to be a language feature? Must a language define
every
> stinking thing a programmer might do, or should that be the responsibility
of
> standard library features? C doesn't define a GUI interface, and neither
> should *any* language if you ask me. GUIs exist only in an environment
that
> includes them, and languages must exist without them. All they need is a
> compiler/interpreter. Access to GUIs, relational databases, HTTP, SMTP,
etc.
> are library problems, not language problems.
Again, don't confuse Smalltalk-80 with current dialects. I put SmallScript
in as the "stand-in" for modern Smalltalks because none of these things is
covered "standardly/uniformly" in Smalltalk today.
Dealing with structs is obviously important and it should be easy to do.
This area is essential for broad/general interop within a multi-language
platform like .NET. It is an area that most scripting languages (and dynamic
languages) handle quite poorly because they typically lack notions of
declarative (optional) typing.
>
> Certificate and Security mechanisms - I guess I need an explanation on
that.
> On my computer (at least) security is the responsibility of the operating
> system. It's responsbile for making sure people only have access to what
> they're supposed to regardless what language a program was written in. In
the
> database world my database keeps track of who's allowed to do what
regardless
> of what language is used. Why should this be a language feature? How
would
> such a language features be useful if not supported/implemented by other
other
> languages used on the same machine/environment?
I'm sorry to punt but there are plenty of resources on the web and elsewhere
to learn and read about the rationale for and intent behind
certificates/digital-signatures.
>
> Isn't RegEX supported in a VW parcel? Why would that be a language
feature?
> How big a book do you want to write to teach people how to use a language?
> Would a student need to read a chapter that includes discussion on
> startup/compile/execute/shutdown speed? How about a chapter on the
language's
> deployment footprint? Should .net languages include the entirety of
Windows
> as part of their footprint?
Hmm. Scripting languages (Perl, Python, Ruby, to name a few) have an
enormous user base [and each is individually much more successful and
growing than Smalltalk or say Scheme had been in recent years]. Those
languages have, perhaps, four or five major characteristics (almost all of
which classic Smalltalk lacks). One of those characteristics is their
specific capabilities for processing text and that is largely tied to their
integration of RegEx facilities into the language. I suggest you look at
some of these languages, how they are being used, and their level of success
and popularity. I think that you'll find answers to the kind of questions
you are raising here.
>
> I appreciate everything you've done for Smalltalk, but your table is more
> propaganda than anything. Maybe you'd rather build a chart comparing
> Smallscript to specific language environments from specific vendors. If
you
> want to include the features vendors choose to include/exclude then your
chart
> would make more sense.
>
I'm sorry you feel that way. I think you are focusing, on me, your
Doug Way
> > A couple of corrections:
> Thanks a lot for the fast reply. I corrected 2) already;
> Should I correct 1, too?
> >
> > 1) Smalltalk is dynamically typed
> Is this wrong?
> I typed dynamic/static here as in GNU Objective-C I think
> I can assign a variable a different type than id. Then the compiler
> can do a check as in C++.
No. Smalltalk is most definitely purely DYNAMICALLY typed, just like
Ruby and Python. Please correct this rather glaring error in your
table.
You cannot add type declarations in standard Smalltalk-80 code and
have the compiler statically check it, etc.
If this post is not sufficient proof for you, you'll note that the
various other tables mentioned in this thread all list Smalltalk as
being dynamically typed.
On another note, it might be good to put different values in the
Templates row for the dynamically-typed languages (Ruby, Smalltalk,
Python, CLOS). Basically, templates are not necessary/irrelevant in
these languages because they already support genericity just by being
dynamically typed. So I would change each of those to say "not
needed" or similar in the Templates row.
On the other hand, templates (or similar support for genericity) not
existing in a statically-typed language like Java *is* a problem, so I
would leave that one as "no".
- Doug Way
dew_d...@hotmail.com
Whisker -- The stacking O-O browser for Squeak/Smalltalk:
http://www.mindspring.com/~dway/smalltalk/whisker.html
Thomas Gagne
think I'd still prefer another one ;-)
--
.tom
Mathieu Bouchard
On Sun, 25 Nov 2001, john%johnkni...@pop.business.earthlink.net wrote:
> Is CLOS (common lisp object system) an actor in this world still? Or
> is there some other scheme or lisp or guile version that deserves to
> be included? I am just asking I don't have the knowledge to
> contribute.
CLOS is still relevant. It's still used. It's the most known object system
for any flavour of LISP with parentheses. There are more books about CLOS
than about Ruby, and probably it will stay that way in 2002.
CLOS is also worth including just because it's very different from others,
and represents a particular point of view. In that light, Self is also a
language that would be worthy of inclusion. However, Self does not run on
many machines, although its has close relatives which do (JavaScript,
SmallScript, Brain).
If I want to classify OO languages, one way to do it is like this:
object-centric: Self, JavaScript, ...
class-centric: SmallTalk, C++, Java, ...
method-centric: CLOS, Dylan, ...
Another reason why CLOS is relevant is that it had two-thirds of the
features of Aspect-Oriented Programming for about ten years before it
became a buzzword. (and buzzword is relative: it is on ruby-talk...)
Avi Bryant
> Another reason why CLOS is relevant is that it had two-thirds of the
> features of Aspect-Oriented Programming for about ten years before it
> became a buzzword.
Not surprising, given that the author of The Art of the Metaobject
Protocol (the definitive book on CLOS) is also the leader of the
AspectJ project (the definitive implementation of AOP). I'd always
assumed that AspectJ was in large part an attempt to bring some of the
ideas of CLOS into a more mainstream arena*, although I've never heard
Gregor say that in so many words.
Avi
*Indeed, an upsettingly large part of academia right now seems to be
working on bringing Java into the 1980s... sigh.
Dave Thomas
> *Indeed, an upsettingly large part of academia right now seems to be
> working on bringing Java into the 1980s... sigh.
That is a .sig to cherish!
Dave
Pixel
[...]
> If I want to classify OO languages, one way to do it is like this:
>
> object-centric: Self, JavaScript, ...
> class-centric: SmallTalk, C++, Java, ...
> method-centric: CLOS, Dylan, ...
in which category would you have ruby? between class and object centric,
singleton being the object-centric part?
and what about python, OCaml?
do you have some docs which explain the differences between those categories?
thanks.
--
Pixel
programming languages addict http://merd.net/pixel/language-study/
Mathieu Bouchard
On Fri, 30 Nov 2001, Pixel wrote:
> Mathieu Bouchard <ma...@sympatico.ca> writes:
> > If I want to classify OO languages, one way to do it is like this:
> > object-centric: Self, JavaScript, ...
> > class-centric: SmallTalk, C++, Java, ...
> > method-centric: CLOS, Dylan, ...
> in which category would you have ruby? between class and object centric,
> singleton being the object-centric part?
Exactly that.
> and what about python, OCaml?
I don't know OCaml, and Python has changed alot recently... Does Python
have singletons, or do you still have to use "ordinary functions" instead?
> do you have some docs which explain the differences between those
> categories?
no, I just made them up. Let me give it a try:
in object-centric, the objects come first, you put methods in them, and
then the classes are a way to share the methods;
in class-centric, the class comes first, you put methods in it, and then
you instantiate the class, to be able to use those methods;
in method-centric, the methods come first, and they just happen to be
parameter-specialized on elements of a type-hierarchy.
Conrad Schneiker
"David Simmons" <david....@smallscript.com> wrote:
> "Pixel" <pi...@mandrakesoft.com> wrote:
[Lots of stuff snipped.]
> > Java, C#... are in the same category
>
> I agree, they are broken. But <g> you are preaching to the choir; I am a
> dynamic language advocate, it is where I have spent my time over the last
> ten years pioneering new facilities and advancing the state of the art.
> Note: I include scripting languages into the dynamic language category.
>
> That's one reason why Microsoft asked me to get involved with the .NET
> architecture and its support for dynamic languages. It is an activity that
I
> will be continuing to interact with Microsoft in evolving over the coming
> years.
Hey, this guy really deserves mention on the "Ruby Who's Who" page
(http://www.ruby-lang.org/en/whos.html), not to mention a BIG THANKS! for
steering the .NET VM in the direction needed for good support of Ruby (and
Python and Smalltalk and so on, and maybe even Perl6).
Even though the .NET VM is obviously not there yet dynamically speaking,
AFAIK it's still a significant step beyon the Java VM in that respect, and I
think 5 years from now lots of us will be very grateful to David for
forthcoming improvements in .NET VM dynamic language support.
[Lots of stuff snipped.]
> Similar issues occur with static language notions of sealed and final as
> well as interfaces. And closely related is the need for selector
> namespaces, which I invented in 1996. Which, to my great satisfaction, are
> now going to be a part of the ECMAScript (JavaScript 2.0) standard. The
> ECMAScript selector namespace design, as far as I known, is unrelated to
my
> work -- which is what makes it so satisfying because it means that
> independent parties trying to solve similar problems came to the same
> fundamental conclusions about its importance.
Well, since no one else seems to be able to bring themselves to say it, yet
someone should, Congratulations.
Conrad