Programming experiences

[Therem Harth]

For a while I've been bouncing between different programming languages - trying to learn how to design programs in one or the other, and pretty much failing. Couldn't seem to get comfortable with any of them, and quickly lost focus. ("What's with this syntax? How can I use the data structures I want? Why is my program giving me obscure runtime errors?")

But at the moment I'm working my way through Practical C++ Programming, and the language just seems to be clicking with me. I haven't gotten into the heavily OOP parts yet, but I think it's pretty nice even as just "C with iostreams"; having halfway sane string and I/O handling makes it much easier to translate what I'm thinking into what the computer should do. Likewise having a compiler that catches most of my mistakes (at least thus far).

Now I'm kind of idly curious about other people's experiences programming, or learning to program. Is it common to find that a lot of languages just "don't click" in the beginning?

[Derakon]

Yes, it is. For example, you should expect it to take at least two tries (and often more!) before pointers make any kind of sense. Programming requires a way of thinking that is fundamentally different from the way most people act. Our brains are used to coming up with all kinds of shortcuts and then forgetting all the steps involved in the normal process. For example, you may "just know" that 56/8 = 7, without having to actually do the math in your head. But computers don't do shortcuts; everything has to be spelled out for them, and to do that spelling out, you can't let your brain take any shortcuts either. It's not easy!

[Therem Harth]

Good point (so to speak). I've gotten the basics of pointers by now, but yeah, that was hard to figure out at first.

[Narvius]

I may be influenced by Torvalds, there (or the fact that one of my college introductory progamming courses mostly consisted of memorizing the more cryptic parts of C++ inheritance rules - a truly boring topic, moreso if you have eight or nine years of programming behind your ears and better things to do), but I do think that streams are the only worthwhile thing that C++ has introduced over C. And maybe reference arguments, I guess.

[Pete Mack]

IO Streams are plain evil. There are much better ways to do this, including static analysis of printf-stype formatting, or C# format statements.

The advantage of C++ over C is object-oriented programming, Period.

[Narvius]

Except OOP is only very rarely useful. :3

Well, I don't think I really get a voice, either way, because I'm an avid Lisper and just don't care about C/C++s features.

[Edit]
Also, the more important aspect of "streams" is handling input and output over a unified interface, not necessarily the left bitshifting implementation present in C++.

[Mikko Lehtinen]

Except OOP is only very rarely useful. :3

I've read that OOP is most useful with mouse-driven graphical interfaces. If you don't have to deal with that, it may well be that OOP isn't worth the effort, of course depending on what you're trying to do.

I'm a novice Python programmer and still trying to understand OOP myself. Python's "everything is an object" was actually very useful to me in a text-processing project. It allowed me to create a function that generated other functions based on data on common errors and how to correct them in a text file. Very useful! I'm not sure whether you could call that OOP programming or not, but I couldn't have done it if functions were not treated as objects.

I find it tedious to learn programming from books that start gradually explaining the basics. It gets boring fast, because you only rarely get to do anything cool. Dive Into Python 3 started with a complete, useful programs, and then explained how they worked. Starting from the big picture helped me to grasp how to use the programming language in real life.

[debo]

The best introductions / motivations for OOP came to me from the Structure and Interpretation of Computer Programs (the wizard book), and Object-Oriented Software Construction (from Bertrand Meyer -- first edition! The second ed is really bloated.)

READ THOSE! (SICP also taught me how to structure functional programs as well. Such an awesome book.)

[debo]

Also, if C++ is "clicking with you", you just might be a psychopath. Or at the very least, a masochist

[Derakon]

OOP has a great deal of value in being one of the most readily-intuitive approaches to designing software. Any given program tends to have a massive amount of state, but that state tends to be broken up into chunks such that only certain functions modify certain chunks. OOP simply formalizes that relationship. It allows the developer to avoid having to think about the irrelevant 95% of the program and focus on only the bits that matter.

Is OOP the only useful design approach? Certainly not. Is it the best design approach? Well, that depends on how you define "best". As I said, it's comparatively intuitive for most programmers; it also tends to be able to be applied to most problems to get you at least some benefit. Those are both significant positive qualities. It's not going to be the best option for every problem, though, but neither is any other approach.

[AnonymousHero]

OOP has a great deal of value in being one of the most readily-intuitive approaches to designing software. Any given program tends to have a massive amount of state, but that state tends to be broken up into chunks such that only certain functions modify certain chunks. OOP simply formalizes that relationship. It allows the developer to avoid having to think about the irrelevant 95% of the program and focus on only the bits that matter.

I think what you're really talking about here is encapsulation (aka Abstract Data Types aka Information Hiding aka ...) rather than OOP per se.

For example, modules exporing ADTs + functions is a good alternative to OOP which accomplishes many of the same goals. This is what's usually done in the MLs and Haskells of the world. (Plus you avoid the dangers of implementation inheritance )

[AnonymousHero]

Likewise having a compiler that catches most of my mistakes (at least thus far).

(Talking about C++).

C++11 certainly made C++ a hugely more safe and pleasant experience, but unfortunately the above statement is overly optimistic. C++ is rife with undefined behavior that you only ever find out about when it's too late -- because something just happens to work on your particular version of your particular compiler. The so-called "static initialization fiasco" is my particular favorite.

C++ also basically has all the wrong "defaults" -- unsafe by default, using managed pointers (smart_ptr, etc.) requires huge amounts of syntax whereas the unmanaged ones require only a "*". A particular niggle of mine is also the fact that you can give reference arguments without any way to notice at the call site. For example:

void f(int &a) {
   a = 5;
}

void main() {
    int x = 1;
    f(x);
    printf("%d\n", x); // Prints 5.
}

You might argue that this is just bad practice, but it would be simple to require some indication at the call site that the "x" in "f(x);" is really being transferred as a reference.

Aaaaaanyway...

[Narvius]

My personal opinion is that the main benefit (main - not only) of OOP is taking over some responsibility for the structure of a program from the programmer. I wouldn't go as to call it a crutch, since that is somewhat demeaning, and programming being as brain-breakingly hard as it is at times, we need all the help we can get, but I've felt liberated not having to utilize any object system in Lisp. There are some problem domains that are naturally best expressed via OOtion, but in the majority of the cases, it's simply a personal choice of what allows you to express your thoughts concisely, efficiently and (most importantly!) human-readably. And for me, that choice usually is not OOP.

And every language has some epic pitfalls. :P

[Pete Mack]

My personal opinion is that the main benefit (main - not only) of OOP is taking over some responsibility for the structure of a program from the programmer.

Well if there is more than one programmer, any responsibility for taking over structure of a program is much to be desired. In fact the part of OO I use the most is "interfaces" not "inherited classes." But if there's some minor polymorphism I want to accomplish, classes are a fine solution.

[Narvius]

Unified interfaces rule.