Boy This Stuff Makes Me Feel Stupid
Boy This Stuff Makes Me Feel StupidI've been lurking around this Wiki for a while. I'm astonished at the whole notion DesignPatterns, RefactoringImprovingTheDesignOfExistingCode, ExtremeProgramming, etc. ... but I'm not too far past "Hello World" when I really look at it.
I've worked through several tutorials on the net and most of them aren't very good. Mostly, there are all sorts of tutorials on language syntax for linear programs, but very little that teach ObjectOrientedProgramming. BTW: This really is hard for new folks: first understanding how classes might be better than functions is a big step. Next, being able to view a problem in terms of useful objects, not just adding some OOP-looking stuff to a regular program. I've been toying with a C++ compiler for a while ... but that doesn't mean I can use objects. (even when my code uses objects ;-)
Without any real object oriented background, this stuff feels just outside of my grasp ... and has been feeling that way for some time now.
I figure that if I'm going to get into programming, I should be PlayingToWin.
If new programmers, such as myself, learn this stuff from the start, then that's part of the PropagateXp problem solved, right?
There's a WikiWikiSandbox for people just learning to use Wiki ... I sure wish there were an ObjectOrientedProgrammingSandBox? ... maybe with PatternsForBeginners and people new to programming ...
I don't want to clutter up the other pages and waste people's time with my baby steps ... and good grief, not only are there experts here having these conversations, but some of these experts literally Wrote The Books on this stuff. Wow. It's kind of intimidating.
Don't be disheartened, I'm kind of in the same boat too and I'm sure there's loads of people out there who are like this too. I, for example, am a competent creative designer who can use HTML, Flash, Dreamweaver and a few graphics packages with the rest of them, which is great (I'm just a home programmer really) and I'm desperately trying to learn to program, but I can't use DOS (or program yet apart from a bit of qbasic - woo hoo)!
I get what it does but I haven't learnt the commands or anything, so I'm sort of starting from scratch and also feel like a bit of an outsider compared to just about everyone here. The thing I always remember is that I bet that lots of the really good programmers were once where I am now and it only takes time, patients, the will to learn and the effort to actually read and learn to get where you want to be :) - puke - but it's true I think. Sure there are those who just got born and could program from the age of three or something but not most people, most people have to sit down and slog it out (which is part of the fun too I think). When I say 'outsider' all I really mean is that I want to join in and contribute and be involved but I really have nothing to offer in terms of intelligent programming conversation yet so there seems like little point. I can read what's already there and learn that way too.
I should drink less coffee in the morning. -- SusannahWilliams?
Though the value of familiarity with "Dos" commands is unclear, I can easily teach you about them if you wish. -- vk
yes, that would be good, I have this that I'm learning from http://www.users.globalnet.co.uk/~jchap/tvdt.htm at the moment but it's not very in depth - the value in learning DOS is that (I'm also learning CeePlusPlus and VisualBasic and QBasic) when I run little programs (using BloodShed? compiler) they run so fast I can't see what happens so if I run them in DOS I can slow them down and observe at a human speed - so I've been told, I'm still trying to figure out how the BloodShed? compiler works (never used a compiler before in my life so it's all a bit new really). thanks :) -- Sus
I've done it! worked out the 'help' command on DOS found the one that makes things go - and watched my first ever program run and you'll never guess what it said... HelloWorld! how about that. in your face apathy! I rock. -- Sus
A handy tip: Put ">c:\path\filename.txt" (without the quotes) after a command, where "path" is some directory you previously created to hold text files, and "filename" is some name of up to 8 characters, and you should find that the command's messages go straight onto the text file you specified, overwriting any previous content (if the file already existed). This technique comes under redirection. You can instead use ">>" instead of ">", and the output should then be added after any existing contents of the file.
The AP Computer Science test (a test to give highschoolers college credit for a beginning programming course) includes a section about a case study, written in java, of a marine biology simulation. It's extremely simplistic in order to be easily understood by beginning programmers, and you don't actually need to have a java compiler to read it, understand it, and learn OOP concepts from it. The code and documentation is available to download at http://www.collegeboard.com/student/testing/ap/compsci_a/case.html.
Give up your life and apprentice to a master ... not necessarily an XP master, anyone who can and will mentor you. Work with people who are better than you. Read, experiment, code till you drop. Hang out at coding bars. Oh, wait, there probably aren't any coding bars.
Perhaps they'll start to show up, now that we have internet cafe's...
If I had a laptop, anywhere that serves Guinness (http://www.guinness.com) would become a coding bar. Guinness is code fuel almost comparable to coffee and WaterJoe? (http://www.waterjoe.com).
I had a boss who'd go out with us for lunch during birthdays and such. Invariably, we'd have a few beers. At the end of lunch he'd point out the worst drinkers and say "you, you and you are NOT allowed to touch the code this afternoon."
Don't worry about feeling stupid. Worry about not feeling stupid. When I feel absolutely confident that I know something, chances are, I'm either wrong, or I'm right and it is time to move on and learn something, a.k.a start from stupid again.
Have you tried writing a simulation? Programming seemed rather flat to me before I was introduced to DonKnuth's elevator simulator. A simulator has a scheduler and a model. The scheduler is a nerdy little thing that feels kinda like an operating system. But the model, well, it can be anything. Write a couple simulators and then read what people here say about modeling. You'll be in the groove in no time.
Hey, let's help this guy out by writing a LittleSimulator to get him started.
Howsabout a version of the classic game "Centipede"? Random numbers scatter mushrooms around the screen. Then a snake made of segments winds its way down the screen, changing direction horizontally whenever it hits a mushroom (and moving downward one step also.) Player controls a little "thing" that shoots the centipede (a wasp? I don't know.) A hit will destroy a segment, breaking it into two centipedes which then move independently. So the bullets, bits of centipede and the player's "thing" are all separate tasks that need to be scheduled. This is how I learned that kind of thing back in '83 in BASIC, and I did it all over again in C++ in '93 and had a great time. You can add the various pieces in stages. The breakable centipede is the hard part. You will take something with you from the experience of writing simple games like this, which is to make every aspect of your program's internal state visible on the screen in real time, somehow, even if you hide it from your users. The moment you can see your program working, you will be hooked. -- DanielEarwicker
As a classic gamer, I like the above idea.... CentipedeGame also seems particularly well-suited to object-oriented programming, in that the breaking-off of segments becomes much easier, and could perhaps be done in one or two lines of code. If only graphics were easy to program in, well, any language. PythonLanguage is nice, and Tkinter's okay, but it's not really "for games". RubyLanguage is nice, too, but using graphics toolkits in Ruby is barely documented at all in English. But it's, in theory, better than graphics programming in the Atari, Commodore or Apple BASIC, with all the PokeStatements? and other pitfalls of BasicLanguage. Perhaps there should be Wiki pages for CentipedeAsBeginnerProject. -- NickBensema
Graphics!? Baahh! Text mode, please! The centipede looks like this OOOOOOOO. Er... and he has a split method... or are the individual segments objects? :) Now, get started! -- DanielEarwicker
Well, text mode support in those languages isn't that much better. I imagine there are curses libraries out there, and it would be nice if some of them were well-documented for Python or Ruby. Is curses even available for Ruby? Or should we code our own ANSI escape code libraries? My concern is that, for the most part, these easy-to-learn languages don't seem to have the kind of support that would make Centipede as easy to throw together as, for example, a Web server or a quicksort algorithm. -- NickBensema
Speaking of Ruby, a great introduction to essentials of software development is ThePragmaticProgrammer
I've ignored all the advice on this page, including my own (see CentipedeGame.)
Forget about C++. If I was looking for an Object Sandbox, I'd start at http://www.squeak.org or better still http://www.python.org
There is a pretty good book on Squeak, written very readably. It's a good place to start (although a bit like learning Esperanto as your first language.)
I'd second that. The biggest mistake I made learning OOP was to start with C++. You need a language that concentrates on classes and objects rather than wasting time and effort on distractions such as organizing #includes You need something which demands OO thinking with as few distractions as possible. I'm not a Smalltalker but the sales pitch looks nice ;-)
Here are two approaches to avoid:
So when teaching Java, you were teaching OOP and using Java to do it? This sounds great. At what level of experience were your students?
I'd ask what sorts of things would you present them with in order to get them thinking in terms of OOP, but I'm not sure you'd be excited about essentially putting your course on-line.
Here are a couple of links for you....
The crowd of 2nd year compsci. undergrads that I was teaching had done a term's worth of introductory Eiffel (see my tirade above). I think they were cynical about OO due to emphasis in their Eiffel course on FormalMethods. I was supposed to give a short conversion course from Eiffel to Java. But a "syntax course" would've been pointless since most of the audience didn't "get" OO. I started the JavaBandwagon page to articulate some of my thoughts about this ;-)
The main things in order:
The point being - I didn't have enough time to go through the whole "what is a pattern?" discussion. I just wanted to encourage some feeling for the QualityWithoutaName. The last few slides of lectures introduced the word "pattern" - and gave names (and references) to what they had used.
The assignments were marked using the GuruChecksOutput method. If I did it again, I'd like to try using UnitTests to do the mechanical part of the marking.
And don't forget - most people posting to this site have 'years' of experience. Learning may take a while - don't expect to have it all sussed in two weeks. -- PeterForeman
The assignment I described came with the vast majority of the code needed to make it work. Too many beginner level programming assignments I've seen have the students writing 100% of the code doing all the design and devising their own tests. This tends to make the whole operation "hit or miss". The value in the assignment isn't in producing writing new code, it's learning to fit a little new code into what you've already got.
I think this comes down the the philosophy of the teacher - formal methods dogma, or the Beck-Cunningham WabiSabi "zen" sort of approach.
You know, I first started learning to programming by pairing with my father. At first, all I could really do was sit there and ask, "Do you have a test for that?" Later, I moved up to, "Didn't you just do that over there?" and "What's a hash?". When I struck out on my own, I was missing the nitty-gritty stuff, but that is much easier to look up in a book than the understanding of a program that I had found by following someone else and WatchingWhereTheyWalked?. I started in Smalltalk, and have never not thought in objects. Which makes the fact that all my college teaches is C and assembly all the more frustrating. [Why frustrating? This gives you a great chance to learn something different. Neither OO nor smalltalk are the be-all and end-all of coding. Both C and assembly are vastly better languages than smalltalk *for some tasks*, for example...]
There's an interesting discussion about handling change in ObjectOrientedProgrammingAnEvolutionaryApproach (by BradCox). He discusses three approaches, the TheSourceCodeIsTheDesign (anybody can come in to change anything), formal methods - change is the clients problem (we do only what's in the spec). OO appears as a reasonable compromise (change and reuse carefully tempered with encapsulation and interfaces).
Although Eiffel has its good points, I'd love to see someone try to refactor an Eiffel application. The main problem I've seen with Eiffel is that it's so concerned with doing the RightThing that the details have got out of control. (See WorseIsBetter) Everyone I've seen who advocates Eiffel is so busy handling the language they still haven't learned to envision objects. I really don't think DesignByContract should be in a first course on OOP - too fiddly, learn to build abstractions first.
The kind of arguments in the above suggestions, with the insanely long WikiWord, are what might make people feel stupid (remember the page title?) Unfortunately, to learn good object-oriented programming, it's probably best to start with a really good object-oriented language. And it's only because I haven't yet learned the SmalltalkLanguage that I endorse RubyLanguage. What makes ME feel stupid when I read Wiki, however, is that DeVry didn't teach me UnitTests. I guess they were too busy coming up with a clever jingle to humiliate me with after I graduated. But from what I've heard so far, it sounds neat, but it's difficult to figure out where to start.
And for my fellow RecentChanges cruisers, read my comments above about CentipedeGame and CentipedeAsBeginnerProject. -- NickBensema
I disagree! If you want to learn about OOP, do it in CeeLanguage! Build structures with pointers to functions, create "new" functions to allocate those structures, hide most of the "methods" with static functions, and pass "this" explicitly in all your methods.
It's a lot easier to understand if you can see what's really going on under the covers. Once you get used to the idea of how all that works, then you can start playing with languages that provide syntactic sugar that does all that stuff for you. -- BruceIde
Not a bad idea, I think, but would hesitate to suggest doing it in C. Writing an OO system is something like scheme, for example, will teach you all the same things without tying your hands behind your back while you do it! If all you know is C, this might make sense. However, in that case your time is probably better spent learning a second language (from a different family).
Actually that was what we did at our first programming course. We learned simple algorithms, recursion, LexicalClosures and HigherOrderFunctions in SchemeLanguage (Yes, we used TheWizardBook). The final task was to create an AdventureGame, with rooms and objects you could interact with. This forced you to create an OO system because you needed one, and the closures part had already taught you simple dispatch methods. I would recommend this approach to anyone, especially in Scheme. -- ClaesWallin
If you are starting to program, and OO isn't making any sense, then just don't use it.
Just program like you know how, and just program like makes sense to you.
When the day comes when you need to use OO, or more importantly, OO ideas, then it will all be clear to you.
Because you'll need it. And things are clearest when you need them.
Stated another way, YouCantLearnSomethingUntilYouAlreadyAlmostKnowIt. In a sense, you can't start to learn OO until you understand the Why of OO - the need for it. And as anyone with a few solid years of life under their belt can tell you, you can't really understand need until you've felt it.
At risk of showing some of my own prejudices, I'd recommend Python for learning programming. It's got simple, easy to read syntax. Punctuation as syntax (and, more extremely, the line noise of idiomatic perl) can be confusing to the beginner. It has an enormous standard library and even larger available one, allowing significant functionality with minimal code. Unlike VB or Java, if/when you want to learn more academic things like closures and higher order functions and the other esoterica you see referred to a lot on Wiki, you aren't out in the cold. It also runs almost anywhere and is free.
We have again started up a design patterns discussion group at http://groups.yahoo.com/group/ocpatterns/ using the head first design patterns book with many newbies. this setting seems to be the easiest one in which to grok patterns. the book's in your face attitude makes it interesting and tractable. I taught an ooad class to graduates students and found that "Object-Oriented Design Heuristics" by Arther J. Riel was a lot what was missing or at least not integrated. these heuristics seem to make the abstractions of the design patterns more tractable. -- RayTayek
See Also: PeopleWhoDontGetOo, LearningObjectOrientedProgramming, http://www.bartleby.com/123/62.html, ThinkingOutLoud
EditText of this page
(last edited October 18, 2013)
or FindPage with title or text search