The Joys Of Programming

So, just for clarification, do arguments over Ruby vs Python fall under the umbrella of religion or politics?

psoplayer wrote:

So, just for clarification, do arguments over Ruby vs Python fall under the umbrella of religion or politics?

Yes.

No!

psoplayer wrote:

So, just for clarification, do arguments over Ruby vs Python fall under the umbrella of religion or politics?

Being less silly, I don't think anyone here has super-strong opinions one way or the other.... I suspect that, on GWJ, if you asked that question, you'd probably get reasonable, even-tempered responses.

I think even on the wider Web, users of both languages see strengths in the other, and I don't think they'd deride "opposing" users. Back when Ruby was really slow, there was a fair bit of criticism on that front, but I think it's about the same speed as Python is, now. The Python libraries may be stronger, but the transition from 2.7->3.X is turning out to be very, very slow and painful. Many of the libraries haven't been ported, which weakens 3.3 a great deal.

And man, Perl is dying fast. It's been ten years, and they're not even done with the new language design yet, much less an actual implementation.

The biggest differences between Ruby and Python are cultural.

Ruby values expressiveness. Python values uniformity.

Ruby values unrelenting progress and accepts breaking compatibility with old things as a cost of doing business. Python values stability and accepts slower progress as a cost of doing business.

In the grand spectrum of languages, however, they are not far apart from each other. These differences look large only when cast against each other. Cast against the rest of the computer language world, and the differences are not so large anymore.

Someone tried to lay out these differences in a blog post that ended up on HackerNews yesterday, but the post's comparison was a bit too troll-y towards Python. The commenters did a bit better.

An example of this is Rails and Ruby 1.8 -> 1.9, and Django and Python 2 -> 3. Python 3.0 went stable December 2008, and Ruby 1.9 went stable January 2009. Django is just now about to get Python 3 support in stable. Rails, meanwhile, is about to become 1.9 only. The current version of Rails is the last one to support Ruby 1.8.

Can we at least band together to derisively mock Tcl? Or am I the only one who had a professor crazy enough to force his students to (attempt to) use it?

boogle wrote:
DanB wrote:

ha, Vim. You people...

I'm willing to accept emacs as an alternative.

I don't like using old-school editors 99% of the time. However, now that I frequently have to rebase and squash all my commits into a mega-commit (part of my company's Git workflow in order to use Gerrit for code review), I do appreciate being able to wield :2,$s/^pick/s -- even though I could easily do that with a more modern editor too.

SixteenBlue wrote:

Use git.

SVN for the win!

RolandofGilead wrote:
SixteenBlue wrote:

Use git.

SVN for the win!

At least it's not AccuRev. Ugh.

Datyedyeguy wrote:
RolandofGilead wrote:
SixteenBlue wrote:

Use git.

SVN for the win!

At least it's not AccuRev. Ugh.

I like SVN. At this point I think I prefer git, but SVN is super easy to use.

I just found out about git blame today.
This is seriously the best thing ever.

I honestly wouldn't be able to use git with git stash. That's a must have for me.

I should look into hook scripts. That's the kind of thing I generally don't do.

Yes, git blame is totally fantastic. I love the crap out of Git and would never go back to SVN (might be interested in trying Mercurial or another similar competitor, for funsies).

If you just learned about git blame, might I recommend some other lesser-known git features to check out?

  • git stash: store work-in-progress if you get interrupted and aren't ready to commit
  • aliases: yeah, you could do it in .bashrc or whatever, but it's supported directly in your .gitconfig too; I recommend aliases for custom log formats and common command chains (pull && push, or send local branch to remote && set up tracking)
  • hook scripts: run custom code during particular git events; easiest one to use as a developer is pre-commit hook -- exit with a failure code to abort a commit attempt; I've used it to programmatically ensure that I don't leave debug statements in code, run tests, validate compilation, check code style, etc. so only acceptable code gets committed

When someone else checked in a logfile accidentally, which would be constantly changing during development and thus interfere with my habit of "git commit -a -m", I also discovered "git update-index --assume-unchanged", which can give Git temporary amnesia about changes to specified files. Screwing with Git's brain for fun and profit!

Now that I've also gotten exposure to rebasing at my current job, the next major feature that I want to explore is the reflog. I vaguely know its purpose, but I've never interacted with it directly.

ADD: Oh man and I had no idea before briefly glimpsing at the man page for reflog, but there are more ways to refer to revisions than I realized!

SixteenBlue wrote:

I honestly wouldn't be able to use git with git stash. That's a must have for me.

I should look into hook scripts. That's the kind of thing I generally don't do.

Stashing is indeed a lifesaver.

For hook scripts, start simple with pre-commit, and you'll come to love them. If memory serves they can be written in any language (e.g. doesn't have to be #!/bin/sh if python floats your boat) -- Git will simply attempt to execute whatever file is at {repo_dir}/.git/hooks/pre-commit. If you use PHP, you can just check the return value of "php -l" and prevent checking in syntax errors. For JavaScript, grep for "debugger;" or "console". If you find a problem, echo a description to stdout and exit 1 to abort commit. Over time you'll find more and more use cases.

Malor wrote:

And man, Perl is dying fast. It's been ten years, and they're not even done with the new language design yet, much less an actual implementation.

People have been saying "Perl is dying" for at least ten years ;p

Perl 6 should probably have had another name, and unless you're interested in "cool stuff with language design", should mostly be ignored. Fortunately, where possible, a lot of the niftier stuff that is feasible makes its way into Perl 5. Perl 5 seems to be trudging steadily along at this point, neither dying nor growing substantially (I base this claim only on my following of news / mailing lists / available jobs with no actual mathematical analysis to back it up).

Well, in the general talk I hear, I just never, ever hear about Perl anymore. It'll probably end up being like COBOL, declining very, very slowly, as old codebases gradually get retired. But it's not really something people are interested in or excited about directly, it's just a means to a paycheck these days. Might be a language you could retire on, but probably isn't going to be exciting ever again.

It used to be the duct tape of the Internet, but it seems that nowadays, people prefer actual building materials.

Most people I know use Perl like sed or awk, and very occasionally like sh. Not so much for writing large bodies of software in any more.

Ruby vs Python: How about we reject both for being ridiculously bloated and slow?

git stash: My working model in Mercurial is to just make a new clone when that happens. Not sure how that works with git, but in Mercurial if you clone a repo with changes in the working copy it ignores the working copy (and makes a shallow copy of the history when possible, so you don't get a lot of wasted space.) I haven't drunk the MQ kool-aid yet, which is like shelve on steroids as I understand it. There's also a "shelve" extension for Mercurial which is more or less the same as git stash.

Ruby vs Python: How about we reject both for being ridiculously bloated and slow?

Lot of truth to that, but computers are so insanely fast these days, and I/O is so glacial in comparison to CPU speeds, that in many cases, programs in more efficient languages wait faster for data from disk. If you can build an app in half the time, but it runs almost the same speed, it'd be a little silly to choose anything else.

That said, I'm glad Dwarf Fortress isn't in Python.

Malor wrote:
Ruby vs Python: How about we reject both for being ridiculously bloated and slow?

Lot of truth to that, but computers are so insanely fast these days, and I/O is so glacial in comparison to CPU speeds, that in many cases, programs in more efficient languages wait faster for data from disk. If you can build an app in half the time, but it runs almost the same speed, it'd be a little silly to choose anything else.

That said, I'm glad Dwarf Fortress isn't in Python.

This just comes down to the old question of what's more expensive, CPU cycles or coder time. And we're at least 20 years since the last time the true answer was CPU cycles.

wrt Perl here's some web usage stats for the last year:
http://trends.builtwith.com/framewor...
Although the trend is pretty stark it remains pretty popular and CPAN is one of the best code repositories out there. Perl's principle problem (aside from the obvious) are that it's just "no longer cool", with both Ruby and Python getting all that mindshare these days. Layer on top the whole Perl6 debacle and it should give anyone pause to worry about the actual sustainable, long-term future/popularity of the language. For instance, what the hell was all that stuff about Parrot? "We're going to build a VM that will run Python faster than the python VM", errr no; how about you put all that effort in to actually bothering to complete perl6 instead? Then there is the stated lack of a reference implementation which is a terrible idea from an engineering standpoint. That said you literally can not move for perl code all over the place in my field (computational biology), so it definitely isn't going anywhere soon as far as I can see. Personally I find it a bit of a shame as there are few languages that are quite so easy to be so productive with. It's also really easy to teach non-coders enough perl that they can be really productive; which is why it's so popular in comp.bio circles. Object Orientation is a large conceptual barrier that, when you are a coder, it's easy to forget is there and you can more or less bypass all that with perl.

Cyranix wrote:

Git stuff

Already using git hooks, alias and stash.
Heck, I've even had to do some rebasing to make things work with gerrit, but we've since adapted a clever git stash/reset method.
This is one of my favorite alias's for updating a commit that is up for code review.
*EDIT*
Also if you use s3 at all, s3cmd is a must have.

DanB wrote:

Although the trend is pretty stark it remains pretty popular and CPAN is one of the best code repositories out there. Perl's principle problem (aside from the obvious) are that it's just "no longer cool", with both Ruby and Python getting all that mindshare these days.

Part of why that is isn't just that Ruby and Python are newer, but Ruby and Python are both fully informed by the existence of Perl.

Ruby in particular was highly influenced by Perl - Matz reveres Larry Wall like a deity.

10 years ago, people would say that if you need to do serious string manipulation, you have to use Perl and its killer regex engine. You can do that in Ruby and Python now, and the presence of regex engines in those languages is a direct result of Perl.

And in a few years or so, someone is going to come along and improve on Ruby and Python.

If you use Git and Vim, you must check out Fugitive.

Watch the five VimCasts on Fugitive to understand what you can do with it. It's nice.

This just comes down to the old question of what's more expensive, CPU cycles or coder time. And we're at least 20 years since the last time the true answer was CPU cycles.

But even that's not quite focusing in the right place. CPU cycles are cheap, yes, but the real problem is slow I/O. Using a slow language, for most things that are I/O bound, ends up barely moving the needle for completion times. And an awful, awful lot of things are I/O bound. (or even HUMAN-bound, which is ridiculously slow.)

*Legion* wrote:
DanB wrote:

Although the trend is pretty stark it remains pretty popular and CPAN is one of the best code repositories out there. Perl's principle problem (aside from the obvious) are that it's just "no longer cool", with both Ruby and Python getting all that mindshare these days.

Part of why that is isn't just that Ruby and Python are newer, but Ruby and Python are both fully informed by the existence of Perl.

Totally agree, though I do think that the way the ball was dropped with perl6 (not appearing in a timely fashion) meant that perl usage lost a huge amount of ground. I just don't see that quite so many people in my field would have jumped ship to python if perl6 appeared and addressed perl5's obvious shortcomings.

Short, interesting blog post on some of the "joys" of programming: http://prog21.dadgum.com/154.html

What do you want to be doing X years from now? Where X is approximately your retiring age minus your current age.

Malor wrote:
This just comes down to the old question of what's more expensive, CPU cycles or coder time. And we're at least 20 years since the last time the true answer was CPU cycles.

But even that's not quite focusing in the right place. CPU cycles are cheap, yes, but the real problem is slow I/O. Using a slow language, for most things that are I/O bound, ends up barely moving the needle for completion times. And an awful, awful lot of things are I/O bound. (or even HUMAN-bound, which is ridiculously slow.)

Python and Ruby are slow enough to move that needle by a lot. Also, the languages are really not all that awesomely expressive. I mean, sure, if this was 1990...

Well, as compared to what, exactly?

Mixolyde wrote:

Short, interesting blog post on some of the "joys" of programming: http://prog21.dadgum.com/154.html

What do you want to be doing X years from now? Where X is approximately your retiring age minus your current age.

tl;dr: I'm worn out from a bunch of stupid stuff and work, but that blog post hit home pretty hard.

I'm staring down the barrel of this and I wish I had an easy answer. I remember a couple years ago in a fit of frustration I said something along the lines of "I've been doing this for 15 years now..." and that made me shut up and re-do the math and realize that not only was that right, I've actually been working with computers for 25. That is not a sentence I'm comfortable with.

There is a point where you realize you've taken that same bloody bedamned beach five times now, and you start to wonder if you're ever going to get the sand out of your boots. The first few times around the horn you can get on board with the whole no one's ever done this before vibe and just ride that up the cliff. But after you hit version 8 you start to see the flaws in the strategy you've been dragged into using and you start to wonder why no one (particularly in management) ever seems to learn from them. Then it gets harder to hop into that landing boat with anything approaching your usual verve.

After a time, you reach the point where you want to pull the covers up over your head when the claxon sounds because you really don't see the need to solve the same old problem a new way just because someone has the same initials as the TLA for the product (I kid you not, I tell you true, that was the reason for one critical infrastructure re-work I had to do two jobs ago). Or Dame Fashion has decided that this season it's de riguer to have your backend written in this kicky, new language that all the cool kids are using even though you know it's not scalable for your problem (I have an ongoing process that involves parsing 5.5 million files we were required to write in Javascript because someone in authority decided that was newer and therefore better for this than Perl-I've already discussed that person's "genius" in here several times).

I'm old, tired, and behind the times. I keep reading the posts in this thread and every time I hear Marlin's bewildered voice in my head saying, "You're really cute, but I don't understand what you're saying!"

I've had a couple flashes of what I would truly call joy in this work lately. I got a hold of a trial version of a newer version of my graphics software, and while I felt like a monkey with a thigh-bone clutched in my sweaty fist confronted with a big black stone, as I poked and prodded at it I kept running into stuff that made me thing, "Wow! It can do THAT now!?" That was fun. That felt like it used to feel to come to work. So I'll keep at it.

Mixolyde wrote:

Short, interesting blog post on some of the "joys" of programming: http://prog21.dadgum.com/154.html

What do you want to be doing X years from now? Where X is approximately your retiring age minus your current age.

f*ck, I'm almost 50. Hells yeah I want to be doing this when I'm 50. Beats honest work.