E
ES
on for Ruby.Le 29/5/2005 said:
Er, Lisp is a procedural language?
Er, Lisp is a procedural language?
G
gabriele renzi
ES ha scritto:
I think what Lothar is saying is that you use prefix syntax in lisp,
where you don't expect completion to behave based on the type of an
object, even if you're using CLOS.
Typing
f<tab> obj
is different than typing
obj.f<tab>
since in the former case you don't expect that the completion is done
based on the type of the arguments, which you have not inserted yet.
I think what Lothar is saying is that you use prefix syntax in lisp,
where you don't expect completion to behave based on the type of an
object, even if you're using CLOS.
Typing
f<tab> obj
is different than typing
obj.f<tab>
since in the former case you don't expect that the completion is done
based on the type of the arguments, which you have not inserted yet.
L
Lothar Scholz
Hello ES,
E> Er, Lisp is a procedural language?
At least Lisp is not a functional language. Lisp is Lisp.
With all the possible side effects etc. it has much more in common
with procedural languages then with true functional languages. And as
gabriele renzi already pointed out the point was that you simply want
prefix auto completition. I don't know of any autocomplete that works
with CLOS in a way like Java/C++.
E> Er, Lisp is a procedural language?
At least Lisp is not a functional language. Lisp is Lisp.
With all the possible side effects etc. it has much more in common
with procedural languages then with true functional languages. And as
gabriele renzi already pointed out the point was that you simply want
prefix auto completition. I don't know of any autocomplete that works
with CLOS in a way like Java/C++.
R
Richard Cole
Lothar said:
Me too. Ruby is a great language and it has given birth to a really
great collection of libraries, but I think that a little type
information goes a long way; both in helping people who are reading the
code (perhaps in the form of facilitating IDE annotations), and helping
the compiler. Some RubyDocs seem to have type declairations, e.g.
RMagick, does anyone know off hand how these come about?
In this thread someone mentioned an example of some code containing a
function that takes either an int, or a hash of strings to ints. That
sounds like a case for function overloading to me, aka
def do_something(a: Int): String
...
def do_something(a: (String, Int) Hash): Int
...
Of course everyones favorite trick it to stick Ints and Strings into the
same array, which, in my book, leaves you with an Unknown Array, Unknown
being the type of your good old dynamic language object on which you can
call any method (possibly getting a method not defined exception). Yes,
type systems and type inference is a can of worms.
One argument against a little type information is that: Oh, it's too
restrictive, I wrote that function to work on Ints or Strings or
whatever has a plus. But beware, just because the function has
apparently correct behaviour for Ints and Strings doesn't mean that it
correct (or expected) behaviour for Matricies's or Hash Tables or
Proxies. That's where interfaces that embody some notion of semantics
come in. An interface for example might be able to make explicit what it
is that is in common between a String and an Int.
Crystaline program structures can take a while to form and so an
advantage of allowing part of the program to go untyped is that it makes
the type system more fluid in that the interfaces are implicit, and they
don't get locked in due to the man hours required to create them. The
other advantage of implicit interfaces is that, since they're an
automatic product of what you and others have constructed, you don't
miss out on them just cause they're not explicit as you would in a
language like Java --- If the join of Integer and String in Java is
Object, too bad, no amount of wishing is going to make it
ObjectWithPlus, or if the join of HashSet and TreeSet is Set then you
can't come along later and say, hey it should be CloneableSet, where as
in Ruby you get all these joins (most specific generalisations) for free
because they are implicit. No-one had to write them, and no-ones failure
to write them makes them disappear.
An example of an implicit interface is that String and Array both
provide an "each" function, but there is no explicit interface in Ruby
that defines this shared property. Just some documentation (and a few
language shortcuts the like the for loop).
On to my second point: a little type information helps the compiler.
When skimming articles about optimising compilers for smalltalk I keep
seeing comments like: such and such an optimiser couldn't infer that the
inner loop operates over floats, so it ran 10 times slower than the
equivalent C program.
There are times when you want to restrict the types to make the program
run faster, e.g. programming an FFT, but who wants to leave the nice
Ruby landscape and muck about in the C/C++ or Java dirt?
regards,
Richard.
PS: Are there any Ruby to Common Lisp bridges? Just out of curiosity.
A
Austin Ziegler
These are probably noted by hand.
No, thank you. This is Not Ruby. This is precisely why I don't
*want* type declarations in Ruby; it's ugly and stupid.
Type *hints* are something else, but should be applied indepenently
of the method declaration.
Sorry, but that's no better than Java's horrid hack of casting to
Object. If you have to cast, you're not dealing with a real dynamic
language. Sorry, but you don't want Ruby if you want this.
No, that's why I document what the method is supposed to do, and
what the user is to expect. The rest of the paragraph is nonsense
once you get to the point where you understand that this is the
responsibility of documentation, not excessively strict type
notations. If I have type notations, then I run into the problem
that I have restricted users of my class and methods. If someone
else makes something that acts just the way that I want it to, why
shouldn't they be able to use my methods just because I was arrogant
(stupid?) enough to restrict the method in the first place.
[...]
And who needs that explicit interface? I sure as hell don't need to
say:
class Foo implements EnumerableInterface
...
end
Sorry, but that's not Ruby.
When were these articles written? Frankly, modern compiler
technology -- and type inferencing -- will help far more than type
specification.
Those who want to make the program run faster.
-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
T
Timothy Hunter
Richard said:
In RMagick's case, they were painstakingly inserted by hand by the
library writer, i.e. me.
R
Richard Cole
Timothy said:
And are very much appeciated by me, a user of your library.
regards,
Richard.
L
Lothar Scholz
Hello Austin,
AZ> These are probably noted by hand.
Yes and a standart how these are annotated by hand is missing, so no
tool can get help from it. By the way FXRuby also has type hints, but
also with its own notation.
AZ> No, thank you. This is Not Ruby. This is precisely why I don't
AZ> *want* type declarations in Ruby; it's ugly and stupid.
AZ> Type *hints* are something else, but should be applied indepenently
AZ> of the method declaration.
In lisp you can put a (the 'Integer 'method-argument-one) whereever
you want. Also in Python you give type hints with statements
independent of the method declaration.
AZ> No, that's why I document what the method is supposed to do, and
AZ> what the user is to expect. The rest of the paragraph is nonsense
AZ> once you get to the point where you understand that this is the
AZ> responsibility of documentation, not excessively strict type
AZ> notations. If I have type notations, then I run into the problem
AZ> that I have restricted users of my class and methods. If someone
AZ> else makes something that acts just the way that I want it to, why
AZ> shouldn't they be able to use my methods just because I was arrogant
AZ> (stupid?) enough to restrict the method in the first place.
Because you want to keep a garantee about what works with with what
types. Sorry but i don't see restriction as a bad thing.
AZ> And who needs that explicit interface? I sure as hell don't need to
AZ> say:
AZ> class Foo implements EnumerableInterface
AZ> ...
AZ> end
AZ> Sorry, but that's not Ruby.
Yes thats not ruby 1.X, not sure if it shouldn't be ruby 2.0
If benefits outweight the problems we should try this. But i also
would like to support another syntax and something optional like
the protocol notation from SmallTalk. Then we use tools to verify that
the implements relationships are right.
AZ> When were these articles written? Frankly, modern compiler
AZ> technology -- and type inferencing -- will help far more than type
AZ> specification.
Type Inferencing is still almost impossible for far to many situations
and this will not change because it is fundamental problem.
AZ> Those who want to make the program run faster.
I've never seen any ruby program where i didn't wished that it would
run faster.
AZ> These are probably noted by hand.
Yes and a standart how these are annotated by hand is missing, so no
tool can get help from it. By the way FXRuby also has type hints, but
also with its own notation.
AZ> No, thank you. This is Not Ruby. This is precisely why I don't
AZ> *want* type declarations in Ruby; it's ugly and stupid.
AZ> Type *hints* are something else, but should be applied indepenently
AZ> of the method declaration.
In lisp you can put a (the 'Integer 'method-argument-one) whereever
you want. Also in Python you give type hints with statements
independent of the method declaration.
AZ> No, that's why I document what the method is supposed to do, and
AZ> what the user is to expect. The rest of the paragraph is nonsense
AZ> once you get to the point where you understand that this is the
AZ> responsibility of documentation, not excessively strict type
AZ> notations. If I have type notations, then I run into the problem
AZ> that I have restricted users of my class and methods. If someone
AZ> else makes something that acts just the way that I want it to, why
AZ> shouldn't they be able to use my methods just because I was arrogant
AZ> (stupid?) enough to restrict the method in the first place.
Because you want to keep a garantee about what works with with what
types. Sorry but i don't see restriction as a bad thing.
AZ> And who needs that explicit interface? I sure as hell don't need to
AZ> say:
AZ> class Foo implements EnumerableInterface
AZ> ...
AZ> end
AZ> Sorry, but that's not Ruby.
Yes thats not ruby 1.X, not sure if it shouldn't be ruby 2.0
If benefits outweight the problems we should try this. But i also
would like to support another syntax and something optional like
the protocol notation from SmallTalk. Then we use tools to verify that
the implements relationships are right.
AZ> When were these articles written? Frankly, modern compiler
AZ> technology -- and type inferencing -- will help far more than type
AZ> specification.
Type Inferencing is still almost impossible for far to many situations
and this will not change because it is fundamental problem.
AZ> Those who want to make the program run faster.
I've never seen any ruby program where i didn't wished that it would
run faster.
D
Douglas Livingstone
D
Douglas Livingstone
A
Austin Ziegler
Then perhaps one of the things you can suggest, Lothar, is what such
a standard might look like, and perhaps even add some stuff to rdoc
to complement this. Maybe:
#
arameter bar: aString#
arameter baz: anArray or +nil+# :returns: true if aString ...
def foo(bar, baz =3D nil)
:
end
This would give potential type hints to various tools. This would
be complicated, of course, by the fact that what we really need to
know is=20
Right. What I want is type hints independent of the method
declaration. Emphasis there: I *WANT* type hints. I have believed
that they are useful for things like SOAP from the beginning. I
don't, however, want anything that looks like type declarations in
the method declaration. That, to me, is a step down the path toward
static typing -- and that's precisely what we don't need in Ruby.
That step is an important one, conceptually. If you provide people
the ability to do something, they will do it. Thus, if we allow
people to do:
def foo(bar: String, baz: [ NilClass, Array ] =3D nil)
:
end
They will. And all of the clean, easy-to-read-and-use Ruby code that
we've come to love will go away. Especially the -use part, because
if I want to use a StringIO object now, I'll either need to modify
the library, or get the String out of the StringIO before I can use
it.
It has been conclusively shown that type restrictions based on class
names precisely do NOT do that in Ruby. Those restrictions, in fact,
do NOT make the code more robust, and are therefore bad things.
I am absolutely positive that this should not be Ruby 2.0. It
complicates things unnecessarily. I think that we can agree that
Java-style Interfaces are poor substitutes for mixins; the proposal
for interfaces in Ruby are equally poor.
Mmm. I'm not sure that I agree. Part of what I'm thinking here has
to do with what Microsoft has done with the .NET platform and Java
has done with Hotspot compiling. Programs are shipped as MSIL. There
is then an initial compile phase of the MSIL to processor-specific
*optimized* instructions. An implementation of Ruby 2.0 could do
something similar, where long-running programs, or programs that are
run often, have cached compiled versions of code that are based on
type inferencing.
This might be something that uses a binary other than "ruby" to run
these programs, as you don't necessarily want cached compiles
littering your hard drive, but these could be used to gain the
benefits of type inferencing. In the use of one-off scripts, this
will obviously be of no benefit, but type hints would be of little
benefit in any case. Rails, Nitro, and other programs (including
PDF::Writer) would benefit greatly.
I've applied a similar concept in one of my demo programs for
PDF::Writer. Because the hardest work is generating the PDF
structure in memory, I have made it so that the TechBook interpreter
can *cache* the generated structure. Once cached, the resulting PDF
can be generated in an almost immeasurably short time.
I won't pretend that I know how to do what I've written about above,
but given that type inferencing exists and that MSIL-to-binary
compiles exist, we aren't talking about something radically new.
We're just talking about a natural evolution, which uses multiple
runs (or long-term runs) of a program to provide continuous
optimisation to the execution of a program.
But have you wanted that at the cost of restricting its utility? If
you have, then I wonder if you've really wanted that in Ruby.
I'll be honest -- there are some things in PDF::Writer that would
benefit from a bit of type restriction. But they are few and far
between. My biggest computing cost in generating PDF documents with
PDF::Writer is on the need to have transactional object support for
tables and similar objects. That said, I generate the manual (which
is growing toward 75+ pages with at least two dozen tables and lots
of live code examples) in about 2 1/2 minutes on my 3Ghz P4. It
takes about 6 minutes on my 1Ghz Transmeta CPU. Average one or two
page reports that I expect people will generate take consistently
fifteen seconds or less.
-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
G
gabriele renzi
Austin Ziegler ha scritto:
Sorry, but If I recall correctly MSIL brings explicit type informations,
so that is not the same thing.
The runtime inference may happen, at least in HotSpot, when you are
doing stuff like using boxed structures and the JIT can transform them
in a native array once it figures they will hold integers.
But some informations can't be inferred that easily. Think for example
of the information about an object representing a 32bit/nativesize integer.
We will always pay the penalty due to the need to consider that it
could, at any moment, become a Bignum, even if there is a guarantee that
this will never happen.
(not that I care too much about performance, but I still think optional
typing is great for documentation)
Sorry, but If I recall correctly MSIL brings explicit type informations,
so that is not the same thing.
The runtime inference may happen, at least in HotSpot, when you are
doing stuff like using boxed structures and the JIT can transform them
in a native array once it figures they will hold integers.
But some informations can't be inferred that easily. Think for example
of the information about an object representing a 32bit/nativesize integer.
We will always pay the penalty due to the need to consider that it
could, at any moment, become a Bignum, even if there is a guarantee that
this will never happen.
(not that I care too much about performance, but I still think optional
typing is great for documentation)
C
Caleb Clausen
Austin said:#
#
# :returns: true if aString ...
def foo(bar, baz =3D nil)
I don't see how what you propose is all that different, semantically,
from calling out the type in the method header. You seem to be arguing
that: 'I want X like in other languages, but I don't want it to look
like it looks in other languages, because programmers from other
languages can import their bad habits.' And to add a feature that
doesn't at least resemble the syntax for that feature in most other
languages is to compromise the (currently much battered) principle of
least surprise, at least for those programmers coming to ruby from
another language. The usual syntax where the type is embedded in the
variable definition has some advantages: it's compact, and it keeps
related things together. It's not for no reason that langauge after
language that actually implements this has done it (more-or-less) the
same way.
Specifying an overly restrictive type is an error. One can write a bad
program in any language, as the various obfuscated programming
contests have shown. Just because this is possible is no reason to
limit what good programs can do.
Type and class are not the same thing. Class is one variety of type,
but there are others. For instance, there is the 'method signature',
(or duck type,) the set of methods that can be called. You try to
rebut this notion:
You manage to criticize without letting us know what your actual
objections are. What things are complicated, and how? Java interfaces
are a poor substitute for mixins, but that's because they're not meant
to be mixins. I would say instead: Java interfaces are a poor
substitute for duck types, (since, like everything else in Java, they
require a big pile of declarations ahead of time) but we can make the
Ruby version work the right way, with a lot less declarations. (Only a
little pile.)
People expect too much from hotspot and the like. It works great for
Java, sure, but that's in large part because Java is statically typed.
Expecting the same performance in a language with no type information
on variables whatsoever is unrealistic.
And no, type inferencing _by_itself_ will not solve the problem. Type
inferencing works in ML, but ML, like Java and C# is not a dynamic
language. ML lacks a feature that Ruby has: method_missing. To
understand why this is important, let me briefly explain type
inferencing.
Type inferencing works by examining the methods actually used by a
particular variable. This method signature (duck type) is compared to
the declared method signature of known classes. From this, a set of
all known classes that could legally be assigned to the variable is
inferred.
Method_missing throws this all to heck. A class with method_missing
might implement any duck type, and so has to be added as a possibility
to every variable. That's why dynamic languages (like SmallTalk) that
use type inference still require some type hints in some
circumstances.
Speed is only one advantage to a static typing system. In general,
static typing makes it easier (for programs as well as people) to
analyse programs that use it.
A
Austin Ziegler
I don't see how what you propose is all that different,Austin said:#
#
# :returns: true if aString ...
def foo(bar, baz =3D nil)
I *WANT* type hints. I have believed that they are useful for
things like SOAP from the beginning. I don't, however, want
anything that looks like type declarations in the method
declaration.
Thus, if we allow people to do:
def foo(bar: String, baz: [ NilClass, Array ] =3D nil)
:
end
They will. And all of the clean, easy-to-read-and-use Ruby code
that we've come to love will go away.
semantically, from calling out the type in the method header. You
seem to be arguing that: 'I want X like in other languages, but I
don't want it to look like it looks in other languages, because
programmers from other languages can import their bad habits.'
Then you're not paying attention. Sorry if that offends you, but
you're just not paying attention. Type hints are primarily a
documentation feature. Let me repeat that for emphasis: it is a
documentation feature. If an optimizing Ruby compiler is able to
take advantage of it -- great. If not ... too bad. This is intended
as both human and machine documentation for automatic documentation
tools (rdoc), IDE autocompletion, and SOAP method descriptions (and
the like).
DO *NOT* USE POLS in your argument. It doesn't apply. Matz has
indicated that it's just so much crap. I don't particularly *care*
if programmers coming from other languages are confused by a type
hinting system that doesn't look remotely like their static typing
system -- it isn't the same. It shouldn't be the same. It shouldn't
give them a false sense of understanding as to what it is.
It also carries tons of disadvantages, as I've expounded before, but
will happily repeat again for those not paying attention:
1. It looks like the stuff in other languages, but because Ruby
isn't statically typed (thank GHU for that), it won't have the
same meaning as it does in those languages.
2. If it does have the same meaning in those languages, we're no
longer talking about Ruby.
3. It will encourage people to use it for the wrong reasons in the
wrong way.
4. It becomes more than informational.
All of these are killer problems. Type hinting in Ruby should be
informational. No more.
You haven't been paying attention. StringIO doesn't inherit from
String or IO, but it will act like either. If I add a #read method
and a #write method to a random object, it will act a lot like an
IO. If I add #to_str to said object, it acts a lot like a String.
Specifying a restrictive (that is, non-informative) type AT ALL
prevents me from using many of these features that make the language
we're using Ruby.
Emphasis: restrictive type indicators will make the language that
does this Not Ruby.
Oh, please *don't* try to lecture me on this stuff, Caleb. You'll
just piss me off. The method signature is not related to the "duck
type." If you've used Ruby for any length of time, you recognise
that as well. I'm not Matz -- or even Dave Thomas -- but duck typing
is, ultimately, not *caring* about the type of object you're
provided. It's just using the type of object.
No, we can't. Interface declarations are simply wasted code time and
space. It's that simple. (And Java interfaces *are* a poor
substitute for mixins; they are the way that Java implements MI, but
they require independent implementation in all cases. Ruby
implements MI through mixins, but like C++'s STL, they have a common
implementation.)
Simple rebut of your attempt at justification: at what point in a
class definition can you conclusively say that it is -- or is not --
an Enumerable? Given that classes in Ruby are open, you can't say it
until you try to use it like an enumerable.
class Foo
include Enumerable
end
a =3D Foo.new
a.inject(0) { |a, b| a + b }
# NoMethodError: undefined method `each' for #<Foo:0x2b5f290>
class Foo
def each
yield self
end
end
a.inject(0) { |a, b| a + b }
Obviously, this class won't work -- there are other parts missing,
but not until I've defined an #each method is Foo an enumerable.
What value would be something like a NoEnumerableInterface error be
as opposed to the simple "undefined method `each'" that we get?
Enumerable's documentation clearly states that it requires the #each
method be implemented for the Enumerable methods to work. Why do we
need an "interface" for that? The interface -- and implementation --
is in Enumerable. We don't need anything more than that.
Not at all. Self is an indication that my suggestion will work:
[...] the compiled method is specialized on the type of the
receiver. If the same message is later sent to a receiver of
different type (e.g., a float instead of an integer), a new
compilation takes place. This technique is called customization
[...] the compiled methods are placed into a cache from which they
can be flushed for various reasons; therefore, they might be
recompiled from time to time. Furthermore, the current version of
the compiler will recompile and reoptimize frequently used code,
using information gathered at run-time as to how the code is being
used [...]
http://rubyurl.com/aFVmq
=09(http://research.sun.com/self/release_4.0/
=09 Self-4.0/manuals/Self-4.1-Pgmers-Ref.pdf)
Gee. It looks like I'm right. Self is an untyped language -- and the
HotSpot technology in Java is *based on the research for Self*.
(Indeed, note the point about the compiled cache and recompile and
reoptimize. That describes HotSpot exactly.)
IIRC, Haskell also supports type inferencing, and is far more
closely considered a dynamic language. Method missing is a simple
case of unoptimizable code. At any rate, it's rather moot, since the
support (above) for the original point that I made rather shoots
down what you've said.
[...]
Bullshit. This is a lie told by proponents of statically typed
languages that has been shown false again and again and again.
Static typing doesn't increase safety, ability to be analysed, or
anything else -- that doesn't help the compiler of said statically
typed language. There are side benefits from IDEs that have been
observed in the last serveral years, but statically typed languages
have been around a lot longer than autocompletion. And we *still*
get buffer overruns.
Sorry, but I question even the belief that speed is an advantage to
a static typing system -- remember that C++ was *slower* than C for
years (and in some cases, still is), and they're both statically
typed languages.
(Hint: even statically typed languages need to break the chains more
often than proponents want to admit. In Java it's Object. In C/C++
it's void*. Both require a lot of care and work to make them
happen.)
-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
A
Austin Ziegler
Mmmm. Not really. See my rather pointed post to Caleb. Self managed
this as an dynamically typed language. HotSpot is based on Self's
VM. Self would reoptimize based on cache and analysis. That's all
I'm saying would have to happen here, in Ruby. Easy? Not at all. But
a lot easier than changing the very nature of Ruby into something it
isn't.
HotSpot, as I understand it, took *longer* to get working right
because it now had to work on a statically typed language.
Additionally, the example of MSIL is just that: an example. It's an
intermediate step that results in an optimized binary.
(And, really, it's not anything like #method_missing that makes Ruby
a hard language to optimize; it's #eval. The reality is that even
things like #method_missing can be optimized because they will be
called in a predictable way in most programs.)
Mmmm. Disagree. You only pay the penalty when you make the switch,
just as you do now in Ruby. Again, see the response to Caleb which
points out Self's optimization.
If it's made in a documentation format. That's my whole point --
typing as documentation is good. Anything else is bad.
-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
E
Eric Mahurin
--- Austin Ziegler said:
From your history of posts, you definitely are not sorry that
you are offending. Insulting people will not help convince
anybody that you are right. You will get much further being
nice and attempting to see where they are coming from.
BTW, I happen to agree with you on this topic. I like no/duck
typing in the language. It provides much more flexibility and
power.
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
A
Austin Ziegler
Actually, I am sorry if he's offended. I *am* exasperated that this
keeps coming up and that no one ever looks at this history of the
topic before bringing it up again, or that certain people bring it up
regardless.
If you were offended by the stridence that I've used in opposing some
of the proposals you've made, I am sorry. That doesn't mean I won't be
strident about opposing things that I think are bad for Ruby, but that
I don't mean to cause offence with that.
I do want hinting -- or at least a documentation "standard" -- for the
reasons mentioned in this thread (documentation, IDEs, etc.). But I
don't want anything that can reasonably be considered remotely close
to static typing.
-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)
G
gabriele renzi
Austin Ziegler ha scritto:
I think I understand what the point of our debate is:
you are thinking of a "fast" thing (i.e. the self system, which in the
paper [1] is claimed to be from 5 to 2 times slower than equivalent C
code).
I am thinking of a "as-fast-as-C" implementation such as those claimed
by the CL people, and also thinking that the fastest *available platform
* with a ruby-like enviroment, VisualWorks, is fast but again quite
slower than C.
[1]
http://research.sun.com/self/papers/iterative-type-analysis.html
I think I understand what the point of our debate is:
you are thinking of a "fast" thing (i.e. the self system, which in the
paper [1] is claimed to be from 5 to 2 times slower than equivalent C
code).
I am thinking of a "as-fast-as-C" implementation such as those claimed
by the CL people, and also thinking that the fastest *available platform
* with a ruby-like enviroment, VisualWorks, is fast but again quite
slower than C.
[1]
http://research.sun.com/self/papers/iterative-type-analysis.html
E
Eric Mahurin
--- Austin Ziegler said:
I don't know if he was offended or not, but the statements
above do look offensive. Some people might leave the group
with statements like that. Someone I didn't know emailed me a
while back venting some frustration and said he left the group.
I didn't agree with his particular viewpoint, but I did think
it was sad that he felt so attacked he had to leave.
OK. Just keep in mind that your opinions are just that -
opinions. And everybody is entitled to theirs.
And I agree with that too. I especially want something in the
rdoc standard to say what a method returns.
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
L
Lothar Scholz
Hello Austin,
AZ> Not at all. Self is an indication that my suggestion will work:
AZ> [...] the compiled method is specialized on the type of the
AZ> receiver. If the same message is later sent to a receiver of
AZ> different type (e.g., a float instead of an integer), a new
Which simply means that it is optimized with exactly one type hint.
It's easy as inside a method "self" can never it's type. But it's
not possible to optimize very much with this. Eiffel and D are using the
feature to transform most of the virtual method calls to binary calls.
But you get very few optimizations that you can get from better
hinting.
AZ> Gee. It looks like I'm right. Self is an untyped language -- and the
AZ> HotSpot technology in Java is *based on the research for Self*.
AZ> (Indeed, note the point about the compiled cache and recompile and
AZ> reoptimize. That describes HotSpot exactly.)
I've never seen very good documentation about HotSpot internals, what
does compiled cache mean, what does recompile and reoptimze mean. As
long is don't see some implementation details this is for me just
marketing hype.
Sure recompile can be something in the oder to check the arguments so
that if i have: x + y and in the past i knew that x and y are often
integers then something like
if (ISINTEGER(x) && ISINTEGER(y)) return x+y;
callinfix(x,'+',y)
The if statement can be transformed to one (SUN Sparc V8 architecture)
or multiple machine code operations.
AZ> Bullshit. This is a lie told by proponents of statically typed
AZ> languages that has been shown false again and again and again.
AZ> Static typing doesn't increase safety, ability to be analysed, or
AZ> anything else -- that doesn't help the compiler of said statically
AZ> typed language. There are side benefits from IDEs that have been
AZ> observed in the last serveral years, but statically typed languages
AZ> have been around a lot longer than autocompletion. And we *still*
AZ> get buffer overruns.
Buffer Overruns have nothing to do with statically typed langauges.
And i don't see any evidence why your argument should be right other
then "religious believe in dynamically typed language".
AZ> Sorry, but I question even the belief that speed is an advantage to
AZ> a static typing system -- remember that C++ was *slower* than C for
AZ> years (and in some cases, still is), and they're both statically
AZ> typed languages.
Sorry but this is wrong. Seems that you never ever looked at
compiler generation.
Also your argument is that one statically typed language implementation is
slower then another statically typed language implementation. What a
huge surpise.
AZ> Not at all. Self is an indication that my suggestion will work:
AZ> [...] the compiled method is specialized on the type of the
AZ> receiver. If the same message is later sent to a receiver of
AZ> different type (e.g., a float instead of an integer), a new
Which simply means that it is optimized with exactly one type hint.
It's easy as inside a method "self" can never it's type. But it's
not possible to optimize very much with this. Eiffel and D are using the
feature to transform most of the virtual method calls to binary calls.
But you get very few optimizations that you can get from better
hinting.
AZ> Gee. It looks like I'm right. Self is an untyped language -- and the
AZ> HotSpot technology in Java is *based on the research for Self*.
AZ> (Indeed, note the point about the compiled cache and recompile and
AZ> reoptimize. That describes HotSpot exactly.)
I've never seen very good documentation about HotSpot internals, what
does compiled cache mean, what does recompile and reoptimze mean. As
long is don't see some implementation details this is for me just
marketing hype.
Sure recompile can be something in the oder to check the arguments so
that if i have: x + y and in the past i knew that x and y are often
integers then something like
if (ISINTEGER(x) && ISINTEGER(y)) return x+y;
callinfix(x,'+',y)
The if statement can be transformed to one (SUN Sparc V8 architecture)
or multiple machine code operations.
AZ> Bullshit. This is a lie told by proponents of statically typed
AZ> languages that has been shown false again and again and again.
AZ> Static typing doesn't increase safety, ability to be analysed, or
AZ> anything else -- that doesn't help the compiler of said statically
AZ> typed language. There are side benefits from IDEs that have been
AZ> observed in the last serveral years, but statically typed languages
AZ> have been around a lot longer than autocompletion. And we *still*
AZ> get buffer overruns.
Buffer Overruns have nothing to do with statically typed langauges.
And i don't see any evidence why your argument should be right other
then "religious believe in dynamically typed language".
AZ> Sorry, but I question even the belief that speed is an advantage to
AZ> a static typing system -- remember that C++ was *slower* than C for
AZ> years (and in some cases, still is), and they're both statically
AZ> typed languages.
Sorry but this is wrong. Seems that you never ever looked at
compiler generation.
Also your argument is that one statically typed language implementation is
slower then another statically typed language implementation. What a
huge surpise.