> Although I'm sure it's dating myself, I'll admit that in college I
> learned Pascal. At the time the "real programmers" stuck up their
> noses at Pascal and raved about C. I evenutally looked into C and now
> want to forget everything I saw. My favorite review of C is from
> Bertrand Meyer, roughly: "C is the closest thing we have to portable
> assembly language". You might be interested in doing things that
> require something like portable assembly (like, say, writing hardware
> drivers) you should absolutely learn C or C++. Otherwise, I say, stay
> away from it. The only other good thing I can say about it is that it
> makes fast programs, so applications where speed is of the
> essence... yeah. But... ick.
I learned C, what, 20 years ago. I moved straight from Borland's Turbo
Basic to Borland's Turbo C. This was back before Borland's Turbo C++.
Pascal existed at the time, but I really wanted more power. It was just
C with training wheels, and I was moving from Basic -- I didn't want
another teaching language.
If you want to write hardware drivers, don't bother to learn C++.
There's a lot of overhead with C++ that is just a horrible idea to have
in a kernel.
Unless people want to write hardware drivers or do some mad embedded
development work, I totally agree there is no reason to learn C.
My father was writing assembly before the invention of C. He was very
glad to find a "portable assembly language". Really, this is an apt
description, as the language has specific features originally designed
to make it to compile.
> [...] But, the Object Oriented aspects of perl are weird -- I
> often say that they are somewhat cynical (read the official perl
> object-oriented tutorial http://perldoc.perl.org/perltoot.html to get
> a sense of what I mean). But basically, some people fell in love with
> Perl so badly that they thought they should use it for everything. I
> like to think that I kept my head a bit more than that, and when I
> found myself fighting against the language in some applications, I
> looked for other options.
Much of Perl seems strangly glued together. Looking at the
object-oriented features in Perl makes it look stapled crudely. It is
really just strange.
> When Java hit the scene in the 1990s, I bought the hype... and,
> Steven, I must say, if you think Ruby is over-hyped, you're probably
> not remembering what it was like when Java first came out.
Java was hyped as a write-once use-everywhere language. That totally
failed, and only when they actually stopped pushing it as the One
Universal Language and decided to use it in server environments, with
specific listed virtual machines did it even start to be useful.
I well remember the dawn of Java. It was horrible. However, for better
or worse, it has matured in to *the* language of enterprise. (Then
again, they're replacing what? COBOL? FORTRAN?)
> Java was
> going to change our whole outlook on programming. It was going to be
> so simple that everyone was going to start programming in it, everyone
> would forget about all other languages, and, best of all, we would all
> "write once, run anywhere". I bought into this at the time and
> started researching Java. What I found is that is basically offered
> nothing to me.
I've seen the Java Compatibility Kit. I well know how they write
documentation for an abstract language with no regard for how the
implimentation works, or how different implimentations function.
It is just a bad design. You need to have your developers know how
things *actually* work, not just how the abstract language was designed.
> I do most of my work in the world of web development
> and system administration, and Java did not show me anything I was
> interested in. Over time, I've only become more cynical about Java,
> as nearly every java application I've had to use has been slow, ugly,
> and just generally depressing to use. I suspect that some people
> overcome the ugly-java tendency and I don't notice that they are java
> apps... and I guess that hardware has finally caught up with Java
> Virtual Machines, because I'm now less struck by everything Java
> seeming so slow. So, it's probably not as bad as I think of it being.
> But, suffice to say, I still have little interest in it. However, if
> I was looking to write desktop applications, I'm sure I'd look into it
> more. It's surely better than C.
Personally, I absolutely *hate* Java. However... if you want to be
a paid developer (as opposed to a system administrator like you and I)
and you want to do the development work in Linux... it is really your
best bet.
> Then everyone started talking about Python. I suspect Python is a
> great language. I've barely used it. Basically, my feeling is that
> if I had a project well-suited for Python, I'd probably just do it in
> perl. Python's approach to object-orientation seems only slightly
> less an afterthough than perl's... you still have no real support for
> anything private/protected, and you still have that "explicit self"
> thing (c.f. http://beust.com/weblog/archives/000501.html) which is
> kinda funny in perl but more strange in Python which seems to be more
> proud of its OO support. And, I must admit, I'm hung up on the
> significant white space thing. I'm sure I could get over it,
> but... why?
Unlike Perl, Python was designed as a whole from the ground up. Even
Larry Wall says that Perl is an amalgam of the languages of the time.
You may not understand the reasons for explicit self, one of the common
Python mantras is "explicit is better than inplicit".
A well designed API doesn't need private/protected locks placed to
prevent other developers from doing "inappropriate" things. Also, when
it comes to large APIs, those locks can get in the way of creating
components that fully integrate with a third-party API in a new way.
The emphasis is on *testing* and not on compile-time static checks.
But, yeah, I admit that white-space thing is weird for a lot of people.
> So, I turned to Ruby. Sadly, I must admit that I agree with several
> of Steven's criticisms of the language: code breaking on language
> updates does happen, much more often than it should... It is indeed
> slower than other comparable languages. Matz should have included
> utf8 support from the beginning. Having said that, it's nowhere NEAR
> as bad as Steven makes it out to be. Most strange of the things
> Steven said is: "recommends coding practices which are staunchly to be
> avoided in *any* other language." I don't really know what he's
> talking about there, but in my experience the BEST thing about Ruby is
> the coding practices that it encourages. Compared to Ruby, using PHP,
> Python, or Perl (or, really, C++) for OO programming seem very much
> like traditional procedural languages with OO tacked on. I can only
> imagine he's talking about things that other languages don't even have
> (so no wonder they should be avoided!). Classic Ruby-isms like:
Yes, things Ruby has that other languages don't have and other languages
do not *need*.
Ruby turns my stomach to the point I try not to think about it. Much of
the problem is related to a user community with absolutely brain-dead
stupid administrative practices, and no one in the community knows
enough about administration to correct the issue.
I do like how Ruby is proud of the equilivant to C's longjmp() function.
Assembly has the function, but no scripting languages support the
feature, and for good reason.
I also like the fact that for almost every online rant about the many
problems with Ruby one of the fanboys will comment, "Clearly you are
new." It is by far, my favorite Rubyism.
Don't even get me started on GEMS... Just look up the discussions
between the Debian folks and the Ruby folks. The Debian folks have good
administrative practices.
Ruby also has some strange confusing names, and a history of
half-completed libraries.
And the standard getopt() function apparently functions by setting
*global* variables. This *clearly* doesn't work well if you want to
integrate one script within another. I've needed to do this in Python,
and it is absolutely painless as they don't have crazy policies about
using global variables for no good reason.
> should really make us all pause and wonder why so many languages
> consider it perfectly natural to write things like
>
> for (x = 1; x <= 7; x++) {
> whatever
> }
I actually never understood BASIC's FOR/NEXT construct until I saw it
compared to C. It just makes more sense.
However, C's (and many other) language for() construct is just another
way of performing a while loop. (This is why Python doesn't bother with
it.)
> At least many languages have now copied perl's "foreach $x (1..7)"
> approach, which is far more readable than the classic C-style syntax
> that java (foolishly, imho) emulated.
This actually originates from shell scripting languages. Perl pulled
it in from there and cleaned up the name.
In Python there is only a 'for' function that works on 'sequences'
and 'interators'. Any class can be a sequence and/or interator.
> But really, my main point about Ruby is this: Ruby has problems, but
> ESPECIALLY if you're thinking of learning a language for FUN, it
> should not be ruled out (much less avoided like the plague). Perhaps
> Steven Black and I do very different things for fun, but most of my
> fun projects do not rely heavily on long-term code-maintenance, native
> UTF-support, or fastest-possible execution times. Meanwhile, Ruby
> will make you rethink the ways that many programming languages do
> things, and even if you never use it for a serious project, you'll
> probably expand your understanding of OO programming in ways that you
> won't get from most of the other languages in common use.
So you're basically saying that you do things for fun you're happy to
throw away? That is a very different approach to what I do. I like to
write things genuinely useful to other people, and that requires some
language stability.
Even though Ruby is as old as Python, it is significnatly less stable,
significantly slower (and eventually you will start to notice), less
complete, and much more poorly documented.
> Having said all that, I'll again say that I can't really recommend
> Ruby over Python, and they are good for similar kinds of things.
They are comparable languages. However, you can do everything you can do
in Ruby better and faster in Python, and it will be easier to write and
debug as it is better documented.
You can't really compare Ruby to Prolog, as Prolog really is doing some
neat stuff under the hood. There's a reason Prolog is slower.
> You see? You get me sucked into writing long emails! Now I'm behind
> on everything else I was going to do this evening...
Sorry about that.
--
Steven Black <blacks@indiana.edu> / KeyID: 8596FA8E
Fingerprint: 108C 089C EFA4 832C BF07 78C2 DE71 5433 8596 FA8E
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
No comments:
Post a Comment