Entry tags:
Perl 6
I feel the gentle winds of conventional wisdom buffeting me towards Ruby.
Is there a practical reason why I might want to do this? Coz if I learned it just for S&G but then didn't immediately start using it for serious, I'd forget it.
"Dude, Rails" is not a sufficient reason, unless you can tell me why I'd want to use Rails over any Mason-based solution.
(Referring to Ruby as "Perl 6" is from
xach, and the funniest in-joke I've heard all week.)
Is there a practical reason why I might want to do this? Coz if I learned it just for S&G but then didn't immediately start using it for serious, I'd forget it.
"Dude, Rails" is not a sufficient reason, unless you can tell me why I'd want to use Rails over any Mason-based solution.
(Referring to Ruby as "Perl 6" is from
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Mr. Grumpy
There, I said it.
I write code to make money. Sure, I enjoy coding, but really, I like money more. The language feature that is important to me right now is: can I create a deployable application with it?
For desktop apps, Python and Java fit this need very, very nicely. For ASP apps, it's PHP or Perl for me.
Size matters. Ruby doesn't have the CPAN^Wlibrary repository or developer community that the other languages that were mentioned boast. It may some day. Ruby is a cool little language, but that's not all that important anymore. Great tech does not a product make.
Certainly, it is time to write the obitrary of Perl. It's a great language that's in maintenance mode now. Still useful, but it's golden years are over. Java is fighting to stay relevant. Without Sun chucking gobs of money at it, Java would have all but died by now. Without the healthy rivally of a vigorous Perl community, Python seems pretty much in maintenance mode too.
At least Ruby appears to have momentum, but where is it going? CGI/Templates/MVC isn't exactly cutting edge and continuations are syntactic sugar.
If I had to advise a new programmer, I steer them towards C++ or even .Net.
C++ is generally more useful but a complete in the balls to program. Even a little skill with .Net can net you a schelpy job in the bowels of corpamerica.
I'm a grumpy old man.
Re: Mr. Grumpy
I was walking down the hall at a client's office the other day and commented to one of their engineers, "I'm old and cynical." A VP who was behind us, who's known me for years, piped up with, "I'm certainly not going to contradict you on that!" So I guess I count as a grumpy old man too.
About ten years ago I stopped learning new languages. I am guru-level with C++ (and FORTRAN, not that it matters anymore), pretty good with Perl, adequate with Java and Python and a few others. I resisted Python for a long time because maturity is the big value-add: I want to be able to dig up a lib to do any reasonable and most unreasonable tasks with a language. That's the only way it's worth my investment to learn the quirks.
So I'm a sworn enemy of all these languages like Ruby, Haskell and Lua, despite their growing popularity in many circles. Like you said, syntax is over-rated, which is why I like Perl: it doesn't have any! LIBRARIES are what make a language great, once it has reached a basic level of syntactical maturity.
No one would call Perl or C++ pretty, but they not only have the expressive power to do everything I could possibly want (and a good deal more than some maintenance programmers can handle) they also have really deep libraries, covering all the ground I need. There are very, very few things that someone hasn't already done in these languages, and I'm happy to exploit that store of past effort rather than waste my time reinventing the wheel.
So my advice to anyone who wants to learn a new language is to do it for fun if you want, but for production code a) stick to what you know and b) focus on what has the best, deepest, richest libs.
no subject
no subject
It was supposed to be a link to this article which attempts to illustrate the difference syntax can make.
no subject
Yeah, syntax can make a difference. But a lot of syntax is a bad idea for two reasons: it lets programmers do things they probably shouldn't because it's "easy" (for them, not the maintenance coders) and it creates multiple ways of doing the same things, which requires the language-idiom-police to move in and enforce some standards.
GOTO's looked pretty cool once upon a time, and I'm pretty sure that closures (and anonymous inner classes) are not particularly good things to have in production code. Maintainability degrades when there is extreme decoupling between dependent objects and actions. When something blows up in the middle of an anonymous class that was created on the fly somewhere long ago in a constructor far far away the poor guy maintaining the app is in trouble.
So in the best Canadian fashion I am in favour of syntax if necessary, but not necessarily syntax.