I graduated Physics in 1995 and my programming experience had been hobbyist on my Apple II at home as a kid or on my Physics course projects, in simple languages. All my friends went into tech in some way or other mostly programming. I looked at C but after a little poking it scared the heck out of me and, intimidated I gave up and did slmethjng else. Only when I had to did I come back to trying programming 15 years later and discovering Ruby I learned that I could, and that I can. I've loved it ever since.
The gap is huge at first but with the growing relationship you learn about all the intricate details of being with someone on a daily basis, which can make all subsequent relationships much easier to handle.
C is rough, it's roots, but it doesn't distort the programmer in any way and teaches very sane principles as much as the innards of the machine, which is always a plus for all further endeavours. Just my two cents.
What I suppose I didn't realize at the time is that those classes weren't designed to teach me to build things with code, which is what I really wanted to do. I don't even want to be overly critical of the college level course because the academic CS stuff really helped me frame some of my thinking about code in the type of real world applications I build now. We also touched on some Haskell, automata theory, circuits, turing machines and assembly in that class. Still it left me feeling like building programs people use was impossible.
When I first started writing a rails app in ruby it was an "aha!" moment about how people actually get things done. Most people learning ruby learn it in the context of trying to build something others will use.
Managing memory in the most efficient way.
Writing PHP or Ruby code spoils you. You completely forget that memory even exists, until you need to do something heavy. It's a good lesson to learn if you want to move beyond just basic web dev personal project stuff. But if all you need is to automate some calculations or store an email list in a db I wouldn't bother.
It's very odd because as far as mobile is concerned, history is repeating itself. You have local apps running code. You can't assume those people running the app have as much memory as you. To build the best working app, run it on a smartphone with horrible specs. If it runs clean there, it will run clean most anywhere.
On the ajax website side it's the same thing. You're pushing the code execution off on the user. You have to be crafty about not assuming anything about the client.
A recent example I encountered was a "suggest as you type" feature for a website. If you try to lookup suggestions everytime a user types a letter in a search it will fail horribly on machines that are even slightly old. However on newer machines it works like a champ. So should we just not worry about those older machines?
Really this could have been done from the start (and was with cookies on some level), but necessity is the mother of invention.
No dev has a "love" of being trapped by constraints, but learns to utilize those constraints in the best way possible so when better things come along they can go above and beyond.
A real world example would be someone who learns to efficiently use memory can push off audio/video/image editing processes to the client side, while someone who relies on an abundant amount of memory could only push off maybe a few statistic calculations to the client side.
If you're looking for a business benefit to this: Pushing code execution off on the client without interrupting the user experience saves money on servers when dealing with scalability. Cut the processing in half by putting 50% of processing off on the client side and you cut your server cost in half.
https://github.com/eduardordm/sisop/blob/master/sisop.asm (see line 110)
C can be low level, but it is mainly a high level language and it will 'distort' programmers just as any other language. Just because it doesn't have simple features it doesn't mean it is closer to the hardware.
C teaches you how to destroy memory, not manage. malloc+free are most harmful functions of the history of computers. (and I don't think I'm exaggerating) You can actually evaluate how awful a C programmer is by counting the number of mallocs/frees he uses.
Oh, I don't like C, by the way. (but I'm really grateful for knowing how to solve problems using this handicapped tool)
That and can we move beyond high school analogies like this? It is getting tiring and I'm sure to outside observers it isn't helping a curious woman's impression of our corner of humanity.
I am currently teaching my 8yo programming, or rather in the process of building a set of teaching tools for her - right now things are very early stage, and she's busy playing VIM Adventures to familiarize herself to the keyboard and keystrokes. I'm trying to decide between Ruby and Python, which has the highly recommended Snake Wrangling For Kids going for it.
There are some small issues with Hackety, including one bug in a tutorial. We're working hard on fixing our big upstream dependency before being able to do another release, but please let me know what you think.
I look like a wizard to management!
I'm not working on projects with millions of daily users, just simple CRUD enterprisey apps, and Ruby and Rails are my Virgil, guiding me through programming hell. :P
Amazing ecosystem + package manager.
The problems you get to work on tend to be less soul-crushing.
First, I mapped keys at the OS level that reduced awkward movements, the most obvious of which is changing the caps lock to control.
The other major thing is acquiring a kinesis keyboard. After several weeks of using it, the pain gradually subsided, and now I have none.
The other thing i did in conjunction with this keyboard was to remap some of the keys unusually, like putting the escape key close to where my thumb could hit it.
There should be enough keyboard choices and key control to make the choice of language on criteria other than wrist or finger pain.
2.0.0 is kind of a big deal. It's not just any random version.
Furthermore, projects always have trouble getting people to actually use release candidates. I can't tell you the number of times I've seen a project where two or three RCs get released, issues are fixed, and when final comes out, people complain "omg there's so many bugs." They would have been fixed for final if you'd tried the RC!
also it gives me heads up that hey new release of ruby coming out soon, maybe i should go test the gems i maintain and make sure they're going to be compatible. RC2 is pretty close to p0
I find this less irritating than constant press release spam from commercial products, at least.
Can't really measure performance boost in production though, since I can't afford to get newrelic just yet
Brian Ford, one of the heads of Rubinius, has also been very outspoken about refinements, though I can't remember a specific link at this time.