On Fri, Mar 09, 2007 at 03:30:12AM +0900, Daniel B. wrote:
convey a sense that it is childish.
A Windows-only fork would have several advantages.
First, I could use the native Windows API functions for everything and
not worry about *nix compatability.
That’s not a benefit of a Windows-only fork – it’s a “benefit” of
deciding you’re not going to code for portability. Choosing a
Windows-only language is part of making the decision to ignore
portability, not a free pass so you don’t have to make the decision.
Second, I could modify the core classes as I see fit to take advantage
of the Windows API functions.
Why can’t you do that with Ruby – or just create mutant relatives of
the Ruby core classes?
Third, I could alter the API of some of the Ruby core classes and/or
modules where it makes sense to do so on Windows (i.e. get rid of the
Unix-isms, add Windows-isms).
You could do that anyway. Feel free to create Windows-only modules.
Fourth, I could more easily handle Unicode issues (ties back to the
first reason).
I think my answer to that is the same as my answer to the third point.
A Windows-only fork would have several advantages.
First, I could use the native Windows API functions for everything and
not worry about *nix compatability.
That’s not a benefit of a Windows-only fork – it’s a “benefit” of
deciding you’re not going to code for portability. Choosing a
Windows-only language is part of making the decision to ignore
portability, not a free pass so you don’t have to make the decision.
Fair enough, but it would mean that I could drop the cruft of
supporting 95/98/ME, too. It would be an “NT Family only” fork.
Second, I could modify the core classes as I see fit to take advantage
of the Windows API functions.
Why can’t you do that with Ruby
Patches for Windows are a colossal pain (it requires modifying 3 files
as far as i can tell) and, in my experience, major patches are
unlikely to be accepted anyway.
– or just create mutant relatives of
the Ruby core classes?
I’ve done that already to some extent with Win32Utils. But, to get
Unicode support, I would effectively have to redefine every method.
Third, I could alter the API of some of the Ruby core classes and/or
modules where it makes sense to do so on Windows (i.e. get rid of the
Unix-isms, add Windows-isms).
You could do that anyway. Feel free to create Windows-only modules.
But you’re forgetting the stdlib alterations.
Not to worry, though. I’m not really going to pursue it. Not without
VC funding, anyway.
– or just create mutant relatives of
the Ruby core classes?
I’ve done that already to some extent with Win32Utils. But, to get
Unicode support, I would effectively have to redefine every method.
Ouch. Point taken.
Then again . . . you’d have to do that anyway, with a fork. Hmm. Can’t
win for losing.
But you’re forgetting the stdlib alterations.
Not to worry, though. I’m not really going to pursue it. Not without
VC funding, anyway.
Oh, I don’t think I have anything to fear from a Windows-only fork –
I’m not worried. I’m pretty sure Ruby, being portable where yours would
not and likely to provide better Unicode support than yours would by the
time you got yours into release-worthy status, wouldn’t hurt any for the
competition. Besides, if all you forked was the implementation and
syntactic details that relate to platform-specificity, I’m pretty sure
the core Ruby would only benefit from the existence of such a close
relative.
. . . especially if it was open source, so that each could benefit from
the development of the other.
On the other hand. I once was talking to the late John Cocke. John
was one of the oldest language gurus at IBM, and was best known for
his work on optimizing compilers, and later for fostering RISC
architectures which relied on such compilation technology.
John told me that when he wrote his first FORTRAN compiler, he had it
accept something like 7 different spellings of the keyword CONTINUE,
because “I’ll be damned if I’ll let any compiler I write tell me I
can’t spell.”
Interesting, but if you type CONTINUE or elsif that many times and
get error messages, you’re going to learn to spell it.
Well this is what you get if you force an already angry person to learn
a butt ugly language because some managor never heard of anything other
than ASP.Net, Java and Ruby on Rails. And decided (under these
conditions correctly) that the best option is RoR.
It’s true. Perl is unquestionably the least butt-ugly language ever.
Remember in those days, heck even in the 80’s languages and tools
(programs) used the shortest names possible because computing power
and memory were at a premium so even saving one character made a
difference. Thus we get all these sick little names for Unix tools,
love them or hate them.
On the other hand. I once was talking to the late John Cocke. John
was one of the oldest language gurus at IBM, and was best known for
his work on optimizing compilers, and later for fostering RISC
architectures which relied on such compilation technology.
John told me that when he wrote his first FORTRAN compiler, he had it
accept something like 7 different spellings of the keyword CONTINUE,
because “I’ll be damned if I’ll let any compiler I write tell me I
can’t spell.”
Jenda, certainly u b trollin’
“rubyists” accept whatever it is. Not all changes need to be
backward compatible. If changes are well documented and reduce
unintended side-effects, then they’re fine and easy enough to fix.
On Thu, Mar 08, 2007 at 08:49:00PM +0900, Jenda K. wrote:
Well, maybe it does the exact some thing … and maybe it also changes
the obj variable from whatever it was before this line to the last
object in the list.
FWIW, I understand this is/has changed in ruby 1.9, so that block
parameters are always local to the block.
Makes sense. Except that it’s a backwards incompatible change.
I don’t see why can’t the rubyists accept that sometimes it does make
sense to be able to explicitely declare a variable, to explicitely mark
an assignment as being more than as assignment, but rather also a
variable declaration. Even if allowing myself to ask Ruby to report a
compiletime error if I do not mark the first assignments is out of
question.
On Thu, Mar 08, 2007 at 09:10:19PM +0900, Marc H. wrote:
"The “Ruby in 20 Minutes” tutorial is obviously geared to the
audience for your book, and stick to it – you’ll have better luck that
way. The Pickaxe is great within its niche. Just don’t make the
mistake of thinking that niche is for people who are new to programming.
I bought the Pickaxe and did great with it for the first few chapters.
I read it religiously. Big game - Michigan vs. Ohio State. (GO BLUE!)
I brought the Pickaxe with me to the ‘in-law’s’ and read the book while
my partner watched the game. I was glued to it.
But, at a certain point, I got lost. Even though I had gone through the
Pine tutorial (not as thoroughly as I should have, but I have a crappy
attention span), and even though I had taken a logic and design course
in school… I got lost.
I have found that just eventually writing little stupid things and
seeing what tweaks I could make to those little tweaks, as well as
asking questions on this list, participating with my Ruby Mentor(s), and
going through code has been invaluable.
Now, I’m starting to go through the Pickaxe again, with a little bit
more experience and understanding this time. I’m nowhere near the skill
level of being able to write wonderful applications/programs, but I’m
better than when I first posted to this list. I’m even highlighting
things now. Wahoo!
