L
Luc Heinrich
Friedrich Dominicus said:
Proper threading and a reentrant interpreter, for example.
Proper threading and a reentrant interpreter, for example.
D
David Garamond
Charles said:
perhaps i should say i want rite (or cardinal, or any other improved
implementation) pretty badly. i can live with the current language (ruby
1.8) for a long, long time. every language has its quirks anyway; i bet
ruby2 will have its own.
D
Daniel Cremer
So instead of spending money the people should spend time and help to
Very true, but what about those of us who are very busy, or very
incompetent and feel guilty
... Seriously I don't think we should
worry too much about _how much_ money will come in. It's the type of
thing that can have a snowball effect if things go well. At the moment
I'm stone broke because I'm working to start a company, however I
would sign up straight away for say 15$ a month, and if the company
goes well certainly more. Ruby has saved my life in numerous
situatuions already in the last month.
Also, I'm considering using ruby for some important apps. I may be
turning corporate already but it reassures me to think there's funding
going on (as little as it may be) to give the ruby projects momentum
(along with the momentum of people helping out of course). If I feel
like this I can only imagine how it looks to large companies.
Besides why do we need to pay someone fulltime right off the bat.
Aren't there other needs such as equipement or funding conferences and
such. If my contribution simply pays someone a big "thank you, keep it
coming" for all the overtime spent working at night and on the
weekends I'll still be happy.
Daniel
Very true, but what about those of us who are very busy, or very
incompetent and feel guilty
... Seriously I don't think we shouldworry too much about _how much_ money will come in. It's the type of
thing that can have a snowball effect if things go well. At the moment
I'm stone broke because I'm working to start a company, however I
would sign up straight away for say 15$ a month, and if the company
goes well certainly more. Ruby has saved my life in numerous
situatuions already in the last month.
Also, I'm considering using ruby for some important apps. I may be
turning corporate already but it reassures me to think there's funding
going on (as little as it may be) to give the ruby projects momentum
(along with the momentum of people helping out of course). If I feel
like this I can only imagine how it looks to large companies.
Besides why do we need to pay someone fulltime right off the bat.
Aren't there other needs such as equipement or funding conferences and
such. If my contribution simply pays someone a big "thank you, keep it
coming" for all the overtime spent working at night and on the
weekends I'll still be happy.
Daniel
D
David A. Black
Hi --
Not hard at all; we're all set up with our PayPal account
([email protected]). I didn't mean to be so informal about
announcing it but I do agree with your point about going ahead, so
there it is.
And if anyone knows of a company that might want to sponsor the
Conference or other activities connected to Ruby development and/or
advocacy, please contact me. We will in fact proceed in slightly more
formal stages as we go, but meanwhile the opportunity is certainly
there.
David
Not hard at all; we're all set up with our PayPal account
([email protected]). I didn't mean to be so informal about
announcing it
but I do agree with your point about going ahead, sothere it is.
And if anyone knows of a company that might want to sponsor the
Conference or other activities connected to Ruby development and/or
advocacy, please contact me. We will in fact proceed in slightly more
formal stages as we go, but meanwhile the opportunity is certainly
there.
David
L
Lothar Scholz
Hello David,
DG> os threads, gc improvements, (and perhaps precompilation/bytecode too).
DG> if i have to choose one, then os threads.
I second that. Having no real threads makes ruby very very unuseable for
todays state of the art application. And i don't talk about
performance, i talk about responsiveness of the application. The
former one will get important soon if Intel/AMD start shipping Dual
Core CPU's even for workstations as announced next year.
So i would vote for stopping all other things and start working
on threads in 1.9
DG> os threads, gc improvements, (and perhaps precompilation/bytecode too).
DG> if i have to choose one, then os threads.
I second that. Having no real threads makes ruby very very unuseable for
todays state of the art application. And i don't talk about
performance, i talk about responsiveness of the application. The
former one will get important soon if Intel/AMD start shipping Dual
Core CPU's even for workstations as announced next year.
So i would vote for stopping all other things and start working
on threads in 1.9
F
Friedrich Dominicus
Well I'm very much suprised that most seem to appreciate Ruby 2. I
have a very ungut feeling about it all has the "features" of the
second system which Brooks describes in book the mythical man month.
Do I have to remind you of the big troubles from Perl 4.x to Perl 5.x
and then again from 5.x somewhat to 5.8? How long are they talking
about Parrot now? 3 years?
Oh it's doable of course, but it will contain tons of bugs from the
beginning and that will last at least up to version 2.2 to shake out
most of them. Is that really worth it?
What I especially dislike is breaking backwards compatiblity. Nothing
is more annoying then coming back to a software you have written and
change it over and over again just because a new version of the
Interpreter/Compiler was shipped.
Ah yes it is probably just a bit annoying to hobbyists, because of all
the new shiny features. But for those happy with what the've written
in Ruby 1.8....
Whoever will/does/have work(ed) on the VM should think at least twice
about what the Squeak people have done....
Regards
Friedich
G
gabriele renzi
il Fri, 09 Jul 2004 17:02:34 +0200, Friedrich Dominicus
I have some bad feelings towards ruby2, mainly because the language
will expand in ways I don't like like @_vars, named parameters not
equal to positional ones and changes in block variable handling.
But I prefer to accept ideas from more wise people, in the end thay
gave me this wonderful language
Anyway there are some nice things in ruby2, and especially people feel
the need for a better runtime, more than a better language..
Ruby will remain ruby even in the next version, You should not think
of a *huge* change.
Some of the changes will appear in the upcoming 1.9 release, some
things will get deprecated and so on, to allow a safer transition.
And rite is *years* in the future, just like Python3000 or perl6.
You could still use ruby 1.9.9 until 2.2 come out. ruby-lang.org has
been running on 1.6 up to some months ago.
the change won't be as big as perl4->perl5 so all this thing you may
need to change will be not so really much, imo.
they have to choice to still use 1.8, what's wrong with it?
??
I have some bad feelings towards ruby2, mainly because the language
will expand in ways I don't like like @_vars, named parameters not
equal to positional ones and changes in block variable handling.
But I prefer to accept ideas from more wise people, in the end thay
gave me this wonderful language
Anyway there are some nice things in ruby2, and especially people feel
the need for a better runtime, more than a better language..
Ruby will remain ruby even in the next version, You should not think
of a *huge* change.
Some of the changes will appear in the upcoming 1.9 release, some
things will get deprecated and so on, to allow a safer transition.
And rite is *years* in the future, just like Python3000 or perl6.
You could still use ruby 1.9.9 until 2.2 come out. ruby-lang.org has
been running on 1.6 up to some months ago.
the change won't be as big as perl4->perl5 so all this thing you may
need to change will be not so really much, imo.
they have to choice to still use 1.8, what's wrong with it?
??
A
Austin Ziegler
Most of the changes planned for Ruby2 -- except Rite, IIRC -- will be
in Ruby 1.9 which is currently in development now.
-austin
D
David A. Black
Hi --
I too sometimes find myself worrying that Ruby 2.x will include too
many features and design additions... but when I feel that, what I
remind myself is: trust Matz Ruby 2 will be bigger than Ruby 1,
but I trust Matz to keep it non-bloated and, as he says, still Ruby.
I do hope that, as methods and libraries are added, others will
disappear, keeping the overall weight of the thing under control.
David
I too sometimes find myself worrying that Ruby 2.x will include too
many features and design additions... but when I feel that, what I
remind myself is: trust Matz
Ruby 2 will be bigger than Ruby 1,but I trust Matz to keep it non-bloated and, as he says, still Ruby.
I do hope that, as methods and libraries are added, others will
disappear, keeping the overall weight of the thing under control.
David
L
Lothar Scholz
Hello David,
DAB> I too sometimes find myself worrying that Ruby 2.x will include too
DAB> many features and design additions... but when I feel that, what I
DAB> remind myself is: trust Matz Ruby 2 will be bigger than Ruby 1,
DAB> but I trust Matz to keep it non-bloated and, as he says, still Ruby.
As long as "eval.c" looks like it does today i don't trust anyone.
DAB> I too sometimes find myself worrying that Ruby 2.x will include too
DAB> many features and design additions... but when I feel that, what I
DAB> remind myself is: trust Matz
Ruby 2 will be bigger than Ruby 1,DAB> but I trust Matz to keep it non-bloated and, as he says, still Ruby.
As long as "eval.c" looks like it does today i don't trust anyone.
C
Carl Youngblood
One thing that I think should be done with the native threads is to
provide some sort of abstraction layer so that Ruby2 takes advantage
of OS threads but code remains as portable as possible. Most
threading systems share a subset of equivalent functionality that, if
adhered to, would allow multithreaded ruby code to be both fast and
portable. Of course, this doesn't have to be built into ruby. One
could always write the abstraction layer as a module.
Carl
provide some sort of abstraction layer so that Ruby2 takes advantage
of OS threads but code remains as portable as possible. Most
threading systems share a subset of equivalent functionality that, if
adhered to, would allow multithreaded ruby code to be both fast and
portable. Of course, this doesn't have to be built into ruby. One
could always write the abstraction layer as a module.
Carl
D
David Garamond
Friedrich said:
I disagree. What features exactly do you see as the signs of second
system syndrome?
Basically Ruby2 tries to fix some design mistakes of Ruby 1.x and
improves a bit on its syntax. (Syntax matters!) Features like keyword
argument has been requested for years. I don't see Ruby2 trying to add
bells & whistles or include the kitchen sink.
So do you prefer to use Perl4? (Not me, thanks). And anyway, what "big"
troubles are there? Perl5 is very much backward compatible than Perl4.
Again, what are the issues do you experience? Virtually all my Perl
scripts run fine between 5.005, 5.6.x, and 5.8.
I'd say yes. A language that doesn't evolve is a dead language.
You can always stick to the old version or the stable branch.
Perl 5.8.x is still being mantained while Perl6/Parrot/5.9.x is being
developed.
Apache 1.3.x is still being maintained even though Apache2 is the
recommended version to use.
Ruby 1.8.x will still be maintained while Ruby 1.9/Rite is developed.
If you don't want Rite, you can always stick with Ruby 1.8.
D
David Garamond
gabriele said:
I don't like this either.
I have mixed feelings about this. But you can always use positional or
hash, ala Ruby 1.8.
Personally I prefer this. I predict this will save me hours of debugging
time in the future.
But I prefer to accept ideas from more wise people, in the end thay
gave me this wonderful language
Don't worry. matz so far has been very good with design decisions for
Ruby.
Isn't Python3k going to be a new _language_ generation (as is Perl6)?
Rite is an implementation for Ruby2, and surely the amount/degree of
changes between Ruby 1.8 -> Ruby2 vs Python2.x -> Python3K or Perl5 ->
Perl6 is much less (again, thanks to the matz' good designs).
Please, Rite, arrive soon[er]
F
Florian Gross
Friedrich said:
I'd like to think that Ruby was well-designed from the beginning on
which means that transitions should be fairly easy to do.
Ruby 2 won't introduce radically new features -- it's just a fairly
straight-forward evolution of the components of current Ruby as far as I
see it.
It depends -- we have a quiet big test suite for Ruby which should
prevent some bugs Ruby 2 might otherwise introduce.
I think that the best way to have this is just having multiple
interpreters installed -- after all every change, however small, might
break your code if you're unlucky.
More Regards,
Florian Gross