After about 15 years on a normal keyboard (8 of those in Linux), I can safely say that it was relatively easy to adapt to the OS X keyboard. Yes it breaks muscle memory, but it's also very easy to relearn, including the key combinations for PGUP, PGDOWN, HOME, END, etc. I also recognize that using CMD instead of CTRL is easier on the hands, because I use my thumb to reach for CMD, instead of using the pinky to reach back and straining too hard. I can now use both types of keyboards with ease. The old muscle memory is still there (plus most Wine apps still need CTRL, so...). The desktop environment definitely takes time to get used to, and there are some things which are really annoying at first, such ash CMD+TAB being application based instead of window-based (though you can add extra commands for window-based). Overall, though, after getting used to it, things really do mostly just work and integrate awesomely. It's unbelievable to be able to grab the icon of a file in a simple title bar and drop it onto my e-mail, Skype, my IDE or even a browser "upload" button. It just works. Drag and drop works amazingly well. Time-machine may use "ancient technology" but it works fucking great. I have moved whole systems in hours and retained all my files, configurations, etc. I have lost critical files and recovered them with ease. Did you just move or rename an open file? Don't worry, most apps have realized that, they don't stop working, they know you moved or renamed the file. Plus, one of the things that really pulled me into Mac was the trackpad. I love it. I augment it with BetterTouchTool and I have blazingly fast gestures for nearly everything. It really saves me loads of time. Oh, and suspend. At the time none of my machines did this transparent combination of suspend+hibernate, but I close the lid on the mac and it just suspends. It also hibernates if it notices that the battery is low, so that if it dies out, or is nearing that, it can hibernate and come back (you don't notice any of this on an SSD).

All that and it's still UNIX. I still have dozens of terminals open. I have most software that is on other *nix systems, such as Wine (wine works great!). The only real issue I've faced is that the way network interfaces work leads to some re-learning and adaptation to some new tools. However, if you are willing to spend the money, I definitely recommend the switch. I left after being tired of having so many workarounds for silly things (my last distro was....Gentoo, but I use Ubuntu and Debian before...in the days of ndiswrapper...). Gotta open Skype? Too bad it needs this special driver loaded or it'll crash pulse, so make a script for it. Want to do this? run a script. That? run a script. I had too many of these, too many small actions. I automated most of it, but I still needed to remember slight details and, over time, I have learned that it is better for me to have a good environment where I can just work and focus on my work. This is why I also buy more chargers and adapters, so I don't have the hassle of unplugging and packing a bunch of them everyday. This "philosophy" is, in great part, why I tried the switch to OSX. I'll admit at first it was challenging, but I don't really think of ever going back. Plus the hardware is great -- and the support too.

But hey, to each their own. Most of my colleagues and friends used to, like me, despise mac and complain about it. Every single one of those who tried mac have stayed there. One of them was forced to use it because of work (iOS development), complained nearly every day for months...and now he's all Mac. I just wanted to give my 2 cents :)

I've said this in reddit, but I'll repost it again here in hopes that my naive opinion might help you in any way:

P.S: Bring slashdot back to its glory days and maybe my sig will be gone for good! :)

node and chrome have nothing to do with each other besides sharing the JS engine.

Coding is easy. Coding things right, with some decent abstraction isn't that easy. Thinking an architecture isn't easy. Finding out the requirements and mapping them into a maintainable, testable, delierable-on-schedule application isn't easy.

What's easy is to be a prick.

One of the reasons why I moved away from several Linux machines was because no matter what scheduler I used, disk IO always slowed the system down to a crawl. It's supposed to slow, but not like that. I mean the mouse was jerky, applications would stop responding...this with a single set of cp commands, let alone when I ran out of RAM and the beast started swapping in and out.
I was told to get an SSD. I switched OSes and it got better all of a sudden. Weird. 8 years down the drain.

I'm sure Linus will beat the shit out of her. After all, his method works!

>If you've never run into that problem, how can you understand the need for a solution?

Partly because you're oversimplifying (OOP doesn't just exist to solve _that_), and partly because sometimes you just find some tools to intuitively feel better than other tools for a job. I'm not saying you shouldn't find out what problems something tries to solve -- I do some tutoring to help my classmates (and some freshmen) improve their grades, and one of the things I stress is precisely that which you described, I always present them a new concept as the solution to a problem; I think that's the way to go. What I'm saying, however, is that it isn't always the case that we need to know the problem _before_ we learn the solution. It's not like OOP is "just" a solution to that, so you might be using it to solve your own set of other problems -- and if it feels like the right tool to you (even if it isn't), you don't need to know why it originally existed.

I have to correct myself. I said "It might, in most cases", where I meant "it might, in some cases".
Did you learn assembly, out of curiosity? By the way, I'm also developing a love/hate relationship with Haskell.
As to college, in this matter it isn't very different to any other person learning how to program. They make the same mistakes..it just helped me better understand the kinds of problems my classmates have.

Python isn't bad as a first language. I knew how to code when I got to college (where they use Python -- a very small, procedural, subset of it in the first course). I tracked the progress of my colleagues (and have tracked the progress of freshmen every year). It is clearly a very good choice because it allows them to "get right to it" and to think about algorithms, not syntax. Python is natural, and in two week's time most of them have mastered most of the syntax. I've also seen what happens in other areas where they start with a procedural subset of C++, and others where they start with C. Boy do they have problems getting started...

Do note that I, however, would like to teach computer courses differently, starting from the low-level stuff to the high-level stuff. I know it sounds like I'm contradicting myself, but this is because I think these are just different teaching philosophies, stressing different important things in students' minds -- that is, I don't think Python is a bad choice, I think it's excellent, though I would prefer it if we could shift paradigm and start teaching how it works on the inside before teaching people how to use the outside.

>You can't really understand a paradigm unless you know the problem it was designed as a response for.

Let me disagree with you on that one. While I do think that it is of extreme value to know what problems something (in this case, a paradigm) tries to solve, I do not think that you need to know procedural programming to know object oriented programming. And I'd like to point myself as an example. I started learning to program "for real" with C++. And I still have some of my old code around. It was awful, yeah, sure. It wasn't the perfect object oriented code, I hadn't acquired many, many, many ideas and idioms, so I wrote clunky code. I wrote clunky object oriented code, with objects that meant nothing (they added no real value), repeated classes without abstraction, improper abstraction, etc. Of course, you can also _do_ tell that in some areas I tended towards a more "procedural" way of doing things, but the concepts of Objects, their communication, their relationships, inheritance (heck, even encapsulation), were established well before my procedural programming skills matured.

This isn't to say that I have anything against learning procedural programming first. It might, in most cases, also be beneficial to most people. But as I saw my college classmates go through this (we did procedural Python, then C, then Java), I noticed that many of them had quite a lot of trouble getting rid of the "procedural way" of doing things, and often made more errors than I did when I first learned OOP. Maybe I'm an exception. But, oh well...

threat* Oh well. I guess thread works. They won't see us as threats, nor as threads...

That escalated quickly. I highly doubt that in a matter of thirty years we'll have "conscious machines" viewing us as a thread. Are these guys for real? Do they know anything about AI?

This is _really_ old news. I've been to two or three talks about this. How can anyone still be surprised?

But that's what I meant. Can't running X inside Wayland still allow us to use it as an X Server to point client apps to, thus only kind of changing X's backend?

Wayland and its never-ending stream of stories seems to be going the way pulseaudio did. It's heavily criticized, cuts down some features or is somehow buggy, but seems to give many users what they want, or at least that's what all these crazy stories point to.

As long as I can still run X atop Wayland, I don't really care. I loved pulseaudio when it was being bashed already. Maybe I'll love Wayland too? Has anyone here actually seriously tried this thing before bashing it?