Which should I learn - Python or Ruby?67 responses total.
Why not both? Either is sufficiently intuitive that one can be usably proficient in a day or two; picking up both should not be that hard. Personally, from a pure language-design perspective, I prefer Ruby over Python. Steve Yegge, however, feels that it is not an acceptable substitute for LISP and gives a number of reasons why: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html Python feels a bit rougher around the edges, but is still useful.
Remmers, with all do respect, isn't it rogaine and viagra time for you?
I've never dealt with ruby and spent maybe 2 hours with python. Maybe I wasn't fully understanding python, but from what I could tell, python names it's chunk of memory. Here is how I understood it. In C, I would go like char i = 6; char *p = &i; in C, &i is just a chunk of unamed memory. The only thing that has a name is the shit associated with the variable i. However in python this would be a reference (ie not a pointer) and this reference would have a name. This means I can do true variable rebinding as opposed to simulatng variable rebinding in C.
It is true that, in python, variables are references. To me, Python feels a bit more hacked together; you can tell that some things were bolted onto the side of the language, often rather clumsily. Ruby is much cleaner in this respect.
I find some of the syntax of ruby very elegant. Never did any serious coding with python to really compare. But really like ruby.
Re #1: I'm sure you're correct that it's not difficult to pick up the basics of both languages, so let me clarify the question a bit. Do folks have a preference for one over the other as an environment for developing web applications? Or some third language? PhP (with which I've had a bit of experience) is another candidate to throw into the mix.
I prefer to write my web applications in PHP, and do any back-end scripting using Perl.
Regarding #6; Ah, that's a little clearer. Ruby, hands down. Rails is the `killer app' for web type stuff.
I've been hearing a lot of buzz about Rails, most of it favorable, although apparently there are scalability issues (Twitter is written in Rails and has run into some problems). Yeah, I've done some PHP development - my jremmers.org website is all PHP-based, currently. What would be the advantages of Ruby+Rails over PHP, or PHP+Perl?
(I've retitled this item to better reflect its purpose.)
Regarding #9; The usual: A better underlying language, a huge amount of 3rd party support, and some others: Rails has a good implementation of model 2 for web applications, which is really nice to work with. It makes developing really fast; and hopefully, a lot of of the scalability issues will be resolved with future upgrades to the Ruby interpreter. But how big do you expect your demands to be? Do you really expect to run into a lot of scaling problems?
Java + JSP in a Websphere or JES container, using Struts for the presentation framework and Oracle or DB2 or Postgres on the backend. Ok, that is probably overkill for what the average person plans to develop, but it would certainly be scalable and well supported, and marketable.
Linked from Jellyware 79 to Web 14.
Re #11: I don't expect to run into scaling problems for a while. I've done some cursory reading up on Rails (and also Django, its Python counterpart). Is it correct to say that these frameworks are geared to using a relational database as the backend data store? Or are they more general than that? I'm also discovering that some web hosting companies support Rails and others (like my current web host) don't.
Geared toward, but not required.
I really wouldn't use Perl or the Perl DBI when connecting to any kind of proudction level database. My whole gripe is because Perl OOP paradigm still lacks the maturity needed to be used in a production level setting. I also think the whole reference counting garbage collector that Perl uses is a bigger load of shit than organized religion. Cross, admit it. The perl garbage collector lags 3 decades behind the lisp garbage collector. Going off on a tangent, Perl sort used to suck ass because the sorting was unstable. However, I think as of Perl 5.6, they switched over to mergesort and hence you can finally get a stable sort. I refuse to comment on perl hashes. However, for a personal website or writing hobbyist code, I would use perl to connect to my database.
I don't care for perl.
Is this because nharmon and vive fagged up your perl experience?
No, because it's a sucky language.
I don't care for perl either, and agree that it's a "sucky language", though I still use it for quick jobs -- usually nothing that I think I'm going to have to go back to, because when I'm done the code usually looks like line noise and a month later I find it borderline unreadable. But #16 is a pretty silly thing to say. Perl is obviously being used in a really whopping number of production environments all around the world. The comments about the garbage collector and OOP paradigm are true, but pretty much totally beside the point.
I probably should play around with Ruby the next time I have a project..
Perl put a ridiculous number of man pages onto my computer so I removed it.
...
re #22: Why not just remove the man pages?
Perl sucks when its used for what it is not good at. but for small text editing I find perl one liners the best at the job. I would definitely not write a 1000lines program in perl.
You'd prefer a 10000lines program in C
Most people would be both pleased and astonished to have manpages that give copious amounts of information. I have to say, though, the Linux LVM manpages are REALLY good.
Yeah, Perl does spam the manpage space. Really clutters up manpage search results to the point of making them unusable. Shame on them. I wouldn't go so far as to remove Perl on that account, though. Getting back to Ruby vs. Python: Google searches turn up tons of discussion, with lots of opinions on both sides but no particular consensus. The _RESTful Web Services_ book I'm reading favors Ruby for its code examples, so that tends to tilt me in the Ruby direction, at least for now.
Writing 10000 line of C code is about as enjoyable as getting a BJ in a dres, stocking, and heels.
I thought you were into that kind of thing?
Okay, outside of the really bad typos in thread 29, writing 1000 lines of threaded code for Linux in C is like wearing cheap stockings. Both are piss poor imitations to the real thing and both tend to rip apart at the most inappropriate moments. I really forgot where I was going with this analogy. I'm also getting the feeling uncle remmer is ignoring me. And in other news, I finally understand what a fucking tagged union is. Yes, another winner topic that has taken me 6 months to understand.
I removed the man pages. Then I removed the doc pages (html). Then I noticed a large unicode directory containing Tibetan. ANd a Test directory. And a whole bunch of other files, maybe thousands of them. I only needed perl once to compile one program, and there was a workaround (manual installation?). If I ever need it again I can use it at grex or reinstall. The list of files in perl is 43K (20 printed pages). 80x43=3200 files? Do I really need anything not in bin or lib (not even including /lib/perl5/unicode - Bengali, Cherokee, Bopomofo, Ethiopic, Hangul are all interesting but not relevant to what I am doing with my computer). What do other people use perl for?
Mostly, text processing (in various guises). So it created a lot of files; were you running out of space or something?
What I'd recommend, if you can borrow use of someone else's machine and they will let you download and build on it, make either the microperl or miniperl (depending on your needs and space constraints). You will then have the relevant exe and can move just it and (I think) one or two .so files and be done with it.
Thanks for the suggestion about building a smaller perl. I don't like having a lot of junk on my computer that I do not use. I process text with pico. I have perl source code (from Slackware 10).
Please do not develop the bad habits of so many people who write perl codes. Many perl authors write intentionally opaque codes that use shortcuts, exploit side effects and massive (unnecessary) indirection. The arrogance seems to be "well, if I wrote it and I understand it, and if you cannot understand it to maintain it, I must clearly be smarter than you". Those fuckers deserve to be sodomized with a rusty hashmap and force-fed an uncommented library characterized by its gotos into inner-loops. And then beaten savagely.
Sounds like you need to learn perl.
It's possible to write decent code in Perl. All of my Perl code is *supremely* elegant and readable. :)
I would have to say the main reason I develop web apps in PHP is because it is almost universal for web hosts.
That's true. Rails and Django are less widely supported, or supported only on rather expensive "premium" accounts.
I did not mean to suggest that all perl authors commit the felonies I have listed, simply that they seem to be perpetrated by authors who write in perl more often than by authors who write in other languages.
You, my boy, have clearly never programmed in APL. :-)
You are correct, I never have even seen any codes written in APL. Do they lend themselves to horrible, unnecessary obfuscation and unmaintainability?
APL is *the* original write-only language; Perl is just a cheap imitation. Well, actually, maybe TECO is older than APL (commands to the TECO text editor look like linenoise. Emacs was originally written as a set of TECO macros; hence the name, Editor MACroS.
re #43: APL is so ridiculously obfuscated that APL source code can't
even be properly represented on an ASCII terminal (because it
requires a special character set..) Take *that*, Perl weenies!
Oh, is it an MVS language (hence EBCDIC) ? That's not obfuscation, that's a crap standard that just won't go the fuck away.
If memory serves, APL is neither ASCII nor EBCDIC - it's got Greek letters and various mathematical symbols. Efficient code creation requires a special keyboard. I believe APL had its origins in the 1960s and predates TECO by a bit. Again, if I recall correctly, structures such as vectors and matrices are first-class objects in APL; there are built-in operators for matrix multiplication and other higher-order operations. In suitable application areas, I'd think it would be possible to write APL code that is both compact and readable, although it may not have worked out that way in practice. But hey, this is the Ruby vs. Python item, not the dead languages item. :)
TECO dates from 1963, according to Wikipedia. I'd guess that it and APL are roughly contemporaneous. You are correct that APL uses a special character set and that vectors, matrices, etc, are all first class objects. Undoubtedly one could write readable APL code, just as one can write readable Perl, assembly, etc. In practice, however, that was not easy. It is hard to envision how one could write readable TECO macros.
re #46: as remmers explained, it wasn't a matter of character *encoding* (ASCII vs. EBCDIC (mostly?) represent the same set of characters, just in different orderings) but of needing an alternate character set that included a lot of mathematical symbols not present on an ordinary keyboard or in either ASCII or EBCDIC. See the wikipedia page for more information.
resp:47,48,49 Whoa! I will be glad to not ever run into something beastly like that. I'm sure it is great for its niche work, but ewww!
I played around with APL years ago on an IBM 5110 (a desktop size minicomputer that predated the original PC. Some of the characters were entered by typing one character, backspacing, and then typing another character. For example, type an inverse triangle (one of the APL special characters), backspace, and then type a single quote, which would result in a symbol that looked like an inverse triangle with a vertical tick mark inside it. I doubt I could write anything in APL now without going through the manual to refresh my memory, but at the time, I actually liked the language. Then again, I also liked Forth (and still do).
Re #48: I didn't realize TECO went back to the early 60s. Yes, that's contemporaneous with APL. The name of the language comes from Ken Iverson's book "A Programming Language", published in 1962, in which he used a symbolic notation of his own invention to describe such things as algorithms and computer architecture. A subset of Iverson's notation was implemented as a programming language, dubbed APL, in 1964. Wikipedia has more details. (As a college senior, I took a course on computers and algorithms from Iverson in 1963; "A Programming Language" was the textbook. My term paper was a description of the Burroughs 205 architecture, using APL notation. I remember thinking at the time that the "APL" notation was pretty nifty. However, for reasons dimly remembered, the course somehow managed to turn me off to computers. I elected to pursue pure math instead, not returning to computer science until after I'd finished graduate school.)
If you want the APL experience in something that uses a normal character set, try J.
Learn both.
Hmm. Maybe I should learn neither and just code in C.
That doesn't sound too fun. The matter really boils down to what you feel most comfortable with; if I were you, I'd dabble in both and then pick whichever language you preferred.
Which is what I'm doing, actually. Although I do find coding in C to be fun, usually.
John, have you considered learning a client-side language like javascript or maybe Flash? I've been having a lot of success using server-side CGI strictly to generate XML data while using javascript to make the web pages dynamic.
Oh yes, I'm well aware of the importance of client-side scripting in today's web. I've done a bit with JavaScript, nothing heavy-duty. On the client side, JavaScript is about the only widely supported non- proprietary tool around. On the server side, there's more choice. To date I've used C, Perl, and PHP for server-side stuff. I'd be interested in feedback on what advantages Python and Ruby have compared to those. I've been dabbling in both Python and Ruby, more in the latter. As a language it has some interesting features - user-definable iterators, for example. They would require a bit of brain-retooling on my part to use effectively, I think.
Remmers: Hasn't the code blocks washed over you like a spring shower? The reason i selected both is because both languages will give you an opportunity to see new language contstructs and ideas. Why not ERLANG?
I've been hearing some buzz about Erlang recently. Went so far as to download the system and type in a couple of sample programs. What would Erlang buy me over other choices?
> What would Erlang buy me over other choices? You'd get to hang out with the cool kids and sneer at the Perl programmers.
This response has been erased.
Lately I've been doing some assembly language coding on PICs, which after years of high-level languages requires a bit of brain re-alignment.
Seems to be popular again - microcontrollers and such.
Well, they're cheap and readily available, and they're easy to use because most of the peripherals and glue logic are on-board. $3 will get you a microcontroller with a 4 MHz clock oscillator, timers, counters, DACs, ADCs, I2C, and a serial UART, all built in. You just provide +5 volts and hook up the inputs and outputs where you want them.
Where I work, we have standard languages (COBOL or Java or REXX in the mainframe; Java or Perl in the midrange servers and dotnet or Perl in Windows), but only COBOL and Java have style guides. Since Perl works the same way in UNIX, Linux or Windows, I use it. I have been told by other system programmers (as well as by two application programmers) that my Perl has a very strong C accent. Is it the best language? No, but it works well enough. Forcing myself to maintain a very explicit, imperative writing style and being serious about my comments (I believe on average one line in three is a comment) makes my codes fairly maintainable; I have not had anyone come to my desk with a source print-out and a "WTF?" look on their face in a long time. -DTK
You have several choices: