Dracorat: I've been lurking here for a bit, but I thought I'd offer my input. I tend to agree with the others, that UML isn't a good introduction to programming, but hear me out.

UML, as you said...

Dracorat wrote:

That's not UML's purpose... UML is a tool.

...is a tool. It's one representation of specific object-oriented programming patterns. It is one way of communicating these patterns and relationships with other members of a team who are already fluent in these patterns. This breaks down when the patterns themselves mean nothing to the reader.

You sound like you have been doing this for at least a little while, so I posit that you don't remember learning basic things like conditions, assignments, and other mundane semantics like that. I know I forget that a lot when I help classmates (some of which are completely new to programming) with homework. It can be amazing what people fail to find "intuitive" (which really just means "familiar").

By starting with UML, you are trying to teach somebody how to structure a story before they even know any words. You're explaining literary devices to somebody who has never dealt with language. UML - or more generally speaking, high-level object oriented design (because UML is really just one tool for that) - can only really be grasped once you have some idea what the building blocks of that design are.

Edit: Of course, this is ignoring the fact that UML is super boring, and doesn't actually produce anything but boxes on paper. Anyone can draw a bunch of boxes on paper. That is mad super boring, yo. I know I certainly wouldn't have continued programming if I had to model everything in UML before I was allowed to write any code.

Actually, I'm proposing using UML as a foundation for starting that discussion.

Let's consider OOP without UML for a moment. When OOP is described without UML, it's usually done with either pseudocode or even real code. It's done with a basic understanding that someone can read code.

Starting with UML (which in all likelihood also means starting with an arbitrary example that may have nothing to do with programming) starts with objects in their purest form: Objects. By creating relationships between them, we get people thinking of objects as objects and not as classed methods or groups of methods. Once we have people thinking in that way, then we start the task of transcribing the theoretical (objects as objects) to programming code (objects as classes).

UML is a tool. You're absolutely right to point that out (and by the by, thanks for being civil about it). And what I'm advocating will seem to some like entering the building through the fire escape rather than through the front door.

I didn't come to this point simply because I decided I don't like the front door. I came to this point as a result of asking myself "what's the underlying problem with coders today and how can it be better?" - a question that I had to answer in order to ask this one "how can I set up future programmers for success?" I quite often teach things - sometimes programming. Sometimes other stuff.

Sometimes I do get the feedback that I "talk too much". It's probably fair.

But I quite often also get the feedback "You're the first person who ever could make me understand this".

Maybe there's a conspiracy to set me up with only Martians. But I doubt it.

But back to UML, it's somewhat like you describe "describing literary devices before you describe words" - but then, that's not fully accurate either. I *am* asking for my students to extend a bit of trust to me that I'm describing something that eventually leads to programming even if they can't see it now. But then I deliver on it.

What I'm doing in actuality is that I'm setting up foundation first. I build on that foundation by example later. To start with UML is a bit like the chicken-egg scenario - you can't have one without the other. So I begin a bit in the theoretical - with real world examples to help cement it - before we get to code.

Now, as a final concession, I'm not the usual type of instructor. I have told people "you should not be doing this type of work" - though not often. And before someone pops on the bandwagon - it's not because I was unable to teach the concepts. Sometimes people don't understand the commitment that learning to program requires. They think that getting a program to do what you want is a weekend course or something similar. I can't really blame them - good programmers / computer experts - can make computers look easy. Just like we all ask ourselves "Did I just pay the doctor 80$ for that?"

But when someone with skill and a desire to know comes along, I will bend over backward to make sure that they understand and grasp the concepts. I will ask clarifying questions to be sure they do.

Because I want people to succeed. (No implication that others do not - just clarifying my style.)

I'd hope that the student would get to the point of designing complicated things.

I'm not trying to say it wouldn't be useful in the future. I'm asking why it needs to be taught hand-in-hand with OO. They would eventually have problems complicated enough to require profiling or debugging with a tool, but that doesn't necessarily justify teaching it from the very beginning. I'm not criticizing a lack of complexity of starter programs. I think UML would only prove useful for a large hierarchy and set of relationships that can't easily be remembered. So why make them learn a separate language and possibly tool was the question.

Quote:

Can OOP be hard? Sure. But it doesn't have to be to get started. Begin with the basics because quite frankly, no student is going to ask "what's the benefit of composition over inheritance?" (or even in a a roundabout way by asking about inheritance interface definition changes vs. dynamic runtime binding)

But even fundamental OO keywords are hard. "Static", "public"/"private" that you encounter in many OO languages are incredibly hard to grok from the get-go and yet it's the one of the first things a Java newbie encounters. I don't like having to tell students "ignore this" or "ignore that" all the time. It tends to kill all curiosity and desire to learn what's really going on and then students start with the cargo-culting and copy pasta.

When I was starting out, I didn't know what LSP was or what is-a vs. has-a were as formal concepts. But I did start running into problems where naively using implementation inheritance everywhere (like a lot of beginning OO tutorials have you do) meant that my methods could be passed objects that didn't strictly make semantic sense and I was coming up with a lot of illogical object hierarchies. In trying to fix these problems, I discovered that parametric polymorphism and composition were far more useful in describing my types and expressing relationships between them than implementation inheritance was.

Quote:

Once they can UML their way out of a wet paper bag then use that basic understanding to ask "story problem" questions - the type they'll receive in the real world.

I guess this is the basic point of contention. How does learning UML help them learn to decompose problems in such a way?

Quote:

And instead of flexibility, you end up with severe design lock in. (Like if we get a call from our librarian later and she says "Oh I want to be able to store magazines and their subscription dates too" - this usually ends up with a new item being created "Magazine" and separate stores for both, and a bunch of if statements or new methods.)

I don't see what about the problem of designing a basic, but flexible toy library/inventory system requires OO. I can certainly see it being a valid way to teach it or design it, but you've stated that OO is programming 101 and I'm just not seeing the necessity for this particular problem or really any program you'd assign a beginner.

Quote:

If you have a different approach, more power to you. That doesn't make my approach invalid.

I'm not trying to definitively say that your method is invalid, just that you haven't convinced me.

In my work "life" I've gone from being the "code monkey" to leading development and project teams now.

Sounds like you've forgotten what being a novice is like. What makes you think that starting somebody with a bunch of box-and-arrow diagrams is going to make them want to be a good programmer more than actually sitting down and writing code? In seeing actual, honest-to-god results of what they write? Why should they give a fuck? Because that's what 90% of "teaching programming" is: instilling the desire to see cool stuff you do come to life in the magic box.

Nobody gets jazzed by writing UML and the idea that it should be taught to novices, where, full-stop, the most important thing is to make them want to continue, is silly.

I'm curious. How did you get started? Did you mostly learn in a classroom? Self-taught? Through step-by-step tutorials, or by exploring and trying random projects?

Self taught for the most part, though I've gotten certifications now.

In my work "life" I've gone from being the "code monkey" to leading development and project teams now.

From my own experience - also self-taught here - the best thing you can do for someone is to give them an environment to explore and discover. There is a time for learning various software design best practices, but it is definitely not an introductory topic. At this point they should just be trying to write as much shitty code as they can as often as they can. They'll learn from their mistakes and their failed projects, which are far more valuable lessons at that phase than simply being told what the best way is.

And in my own opinion, if they aren't excited enough to play (and I use that word specifically, because writing code has always been recreation for me) with code, they probably shouldn't continue. It will be a boring, monotonous life of endless bug fixes and user stories.

And in my own opinion, if they aren't excited enough to play (and I use that word specifically, because writing code has always been recreation for me) with code, they probably shouldn't continue. It will be a boring, monotonous life of endless bug fixes and user stories.

For all that I disagree with Dracorat's approach to programming pedagogy, I think we're misunderstanding what's being said. It's not about teaching UML as such, it's about teaching object-oriented design (i.e. problem decomposition) before getting to procedural logic, functional abstractions, and the various other traditional starting points in programming. Just like Python is a nice lightweight way to express those early steps in the approach we're advocating, UML class diagrams are a straightforward way to express that decomposition.

For all that I disagree with Dracorat's approach to programming pedagogy, I think we're misunderstanding what's being said. It's not about teaching UML as such, it's about teaching object-oriented design (i.e. problem decomposition) before getting to procedural logic, functional abstractions, and the various other traditional starting points in programming. Just like Python is a nice lightweight way to express those early steps in the approach we're advocating, UML class diagrams are a straightforward way to express that decomposition.

For all that I disagree with Dracorat's approach to programming pedagogy, I think we're misunderstanding what's being said. It's not about teaching UML as such, it's about teaching object-oriented design (i.e. problem decomposition) before getting to procedural logic, functional abstractions, and the various other traditional starting points in programming.

While UML is a point of contention, I don't think those of us disagreeing are missing the forest for the trees. The argument is that OOD is actually pretty hard and before you really understand it, it's not very useful for thinking about how to compose programs. In fact, it can be counter-productive.

For all that I disagree with Dracorat's approach to programming pedagogy, I think we're misunderstanding what's being said. It's not about teaching UML as such, it's about teaching object-oriented design (i.e. problem decomposition) before getting to procedural logic, functional abstractions, and the various other traditional starting points in programming.

While UML is a point of contention, I don't think those of us disagreeing are missing the forest for the trees. The argument is that OOD is actually pretty hard and before you really understand it, it's not very useful for thinking about how to compose programs. In fact, it can be counter-productive.

Yes. Personally, I don't think software design has any place in the first steps of learning programming at all. Learn to talk first, then we can have grammar lessons.

For all that I disagree with Dracorat's approach to programming pedagogy, I think we're misunderstanding what's being said. It's not about teaching UML as such, it's about teaching object-oriented design (i.e. problem decomposition) before getting to procedural logic, functional abstractions, and the various other traditional starting points in programming.

While UML is a point of contention, I don't think those of us disagreeing are missing the forest for the trees. The argument is that OOD is actually pretty hard and before you really understand it, it's not very useful for thinking about how to compose programs. In fact, it can be counter-productive.

As I said, I agree with you and TotalMeltdown. I just wanted to get the discussion past its hangup with UML, which was really besides the point.

As I said, I agree with you and TotalMeltdown. I just wanted to get the discussion past its hangup with UML, which was really besides the point.

Except insofar as it's absolutely emblematic of the PHB-ish process wank that's sure to derail novices before they even start, sure.

"Plan first, code later" is shit when you don't know how to code or plan. And you need to code before you can plan. There was no "hangup" in the discussion (but a decent bit of astonishment that somebody could say that for-srs) and you're mischaracterizing it by claiming there was.

When you're learning programming (no matter who's method you subscribe to) then in the beginning you create a lot of essentially useless programs in order to learn about very specific concepts in programming. You create an application that writes "Hello World" to the console not because it's useful but because it demonstrates how to create output. You create an application that adds numbers in order to demonstrate how to receive input, assign it to variables, perform an operation and put the variables on the command line - not because it's useful (it's not - especially when it's hard coded to just add two numbers in serial) but because it demonstrates these things.

Programs of that nature exist because the teacher needs them to exist in order to have something "straightforward" to teach a student.

Maybe that's good enough for some. "Here's the manual, I've given you the basics, you should be able to run with it now."

You need to get out more. Even the worst programming book handles this far better than you describe (well, except maybe for Essential C#!). Take Programming Perl. Perl is not what you would call an OO language. It has been added on over time and it allows you to mix structural and object-oriented patterns as necessary. You can call $object->method() or you can call subroutine($object) as you decide. Or maybe you want to do subroutine($var1, $var2, $var3) that could be three properties of an object. Which I think makes it great for teaching, and why I think people like Python as well.

To that end, Programming Perl - and most Perl books - start with a Hello World program. Then they add to it. Your hello world program then says Hello, Dracorat! after prompting you for your name. Next it asks you for two numbers and adds them. Then it asks you to type one number per line and hi enter when you're done, and it adds all of those numbers. Then it adds error checking for when someone types in 'two', and then subroutines, and then recursion, etc. Eventually it gets to objects, the differences between OOP and SP, when you should use one or another, and by the end of the book your hello world program does more than just add a few numbers and ask for your name to give a personalized greeting.

I think that kind of progression, no matter the language, is something that a majority of people benefit from. You start with the basic building blocks of what a program is - sometimes good ones, and sometimes bad ones, and what makes them good or bad in certain situations - and you go from there. I would think that going the other way would be very difficult, no matter the subject material. You don't learn ancient greek by starting with the Illiad, right?

Hmm. The recommendation for Essential C# was hearsay, I'll actually read it sometime before I pass that along again.

That said it sounds like you already have a strong grounding and really wanted an introduction to the BCL.

Also learning thread safety is hard, so if you got it from the book I wouldn't knock it totally!

Oh, I'm not knocking it. It's not a horrible book, actually, but it is more of a reference book and in some ways more about the compiler/framework than using the language itself. If I were a windows programmer, just learning the intricacies of C# would probably have been all I needed, but coming over from *nix without any knowledge of the windows APIs it's just lacking, that's all. I would just be careful to recommend it as a reference book more than anything else.

The thread safety chapters are something I tried to internalize. Without some practical usage examples I have it in my head but it is going to take some practice to really understand it. I did find it confusing because the author starts with the old ways to do things, then into the new things, then into alternatives, and didn't really recommend which API to use now.

Still, I have a solid grasp to make more sense out of online tutorials, and it counts as an achievement for my year-end review in 2012

I think that kind of progression, no matter the language, is something that a majority of people benefit from. You start with the basic building blocks of what a program is - sometimes good ones, and sometimes bad ones, and what makes them good or bad in certain situations - and you go from there. I would think that going the other way would be very difficult, no matter the subject material. You don't learn ancient greek by starting with the Illiad, right?

This. When teaching programming to beginners, you need to introduce and concretely demonstrate the concepts of output, input, and internal program data. You need to show the learner that yes, they can actually control the actions and behavior of this machine. With those foundations you can gradually increase the complexity of your algorithms and input and output.

Javascript you can learn on ww3schools.com and python at khanacademy.org. I think javascript might more readily get you a job.

Javascript and Java is not the same thing. I'm a first year CS learning Java. I like it a lot.In case you are interested go to ninite.com - Mark the Java JDK and Eclipse on the bottom of the page and get the installer. That is all to setup. Go through the Eclipse tutorials, buy a book (head first Java is good), browse YouTube and voila.

Yep. We have two completely different approaches to programming and to teaching.

There are quite a few people in this day and age who do care about UML, OOP and flow charting. And no, it doesn't require rocket science to understand any of them.

It does require someone willing to learn which is something that I assumed was a given.

Sorry for the lagged reply, I've been away from the internet but am curious as to how you deal with the following aspects. I (disagree with, but) see your point about why you wish to first teach UML and have a student understand the (very-big) structure picture of what a program requires. Problem that I don't see mentioned is once you've taught the student how to determine the 1:N, 0:1 the messages, and user interfaces and all the other UML bittens, how does a student know a.) what data structures to use? b.) How to decide between competing data structures (big-O analysis)? c.) What algorithm to use to operate on those data structures? d.) What underlying representation is best for a given data structure?, etc...

I see a.) and d.) (Data Structures) b.) (Discrete math) c.) (Algorithms) as what form the (absolutely) minimal basis for a fairly standard course in computer science. I suppose one question that hasn't been answered is do you want your students to be coders, or computer scientists. If the latter, I cannot see any real benefit of starting with UML and OOP. If it is, however, the former, then maybe assuming they'll never need to understand WHY anything is the way it really is.

Maybe I'm just an old hardass (I'm not even that old) after seeing multiple people come through interviewing for an open position on the team I am on with honest-to-goodness CS degrees (bachelors and masters even!) who cannot explain the difference between a queue and a stack.

Perhaps you should (though your current experiences in learning it may be useful as far as a anecdotes go)

I wasn't recommending Java. I just wanted to share the resources that have worked for me and that I know about in case our beginner wanted Java anyhow. I have no choice but to learn Java at my University. Python and .NET are optional later.

UML has been taught alongside Java in my class. Write a small 2 class project and explain it in UML. UML by itself is too boring. Just get the basics of UML from Youtube and keep it in mind when coding I think. Don't know if Python has some UML to Code or Code to UML tools. Would be great.

A piece of friendly advice: make sure that by the time you are done with your program (curriculum) you can clearly explain the difference between a queue and a stack That way, when you are asked in an interview you don't look like an idiot and make the interviewers wonder what the hell is going on...

I strongly doubt you would follow that. At least, not without quitting. Racket is, effectively (I almost said 'functionally', but caught myself), a no-go unless you expect people to want to learn programming for the sake of programming.

Nobody learns to program for the sake of programming. It feels like a lot of people forget that.

I strongly doubt you would follow that. At least, not without quitting. Racket is, effectively (I almost said 'functionally', but caught myself), a no-go unless you expect people to want to learn programming for the sake of programming.

Nobody learns to program for the sake of programming. It feels like a lot of people forget that.

Plenty of non CS/SE/EE/etc people DO in fact learn programming for skills it teaches, but no really what's wrong with HtDP and Racket? It's basically entirely designed as a successor to SICP.

It's actually sort of interesting to look at the top US CS Programs Undergrad and Grad, and what language they start with ...

Like I said: it's a language for learning programming for the sake of programming. There's no feedback loop of "look, you can make cool stuff, now learn more stuff so you can make cooler stuff." I've noticed that a lot of experienced programmers (myself included) fall into the "you need to know X, Y, Z before you can go make Cool Stuff" trap, when it need not be the case. If you want novices to get jazzed and to continue programming, you've gotta make them love it--and nobody's gonna love Racket.

Not speaking entirely out of my ass here; I've taught novice programmers before in informal and academic settings. Our CS department used Scheme (probably would be using Racket now, it was DrScheme when we did). People who already knew how to program loved it. People who didn't hated it and said, "what's the point?". And we could have said "well, derpa herp, you learn the fundamentals", and that's even technically correct (the best kind of correct), but a newbie is exceedingly unlikely to care. And you have to make them care.

I mean, I don't like Python. At all. I throw rocks every time Alamout talks about how he wuvs it so. But Python is a really easy, approachable language that has enough tools and libraries to make getting some of those "wow" moments into newbies' heads very quickly. LPTHW has a bunch of them and is pretty cool about it. My 14-year-old brother is learning LPTHW and loving it; do you really think he'd give one single crap about SICP or HtDP?

While SICP has a clearly indepth focus on Math and makes people with anything less than great Calculus/Algebra skills go nuts, HtDP is not at all like that, I mean it's just some really simply basic stuff and just happens to allow you to copy and paste IMAGES right into the "IDE". I'm working on teaching a 10yo to program and Racket has been the only thing that has caught his interest - it's crazy how he learned just a few simple math operations and he started making animations. 38 line program and he was able to make a cat chase a dog around the screen.

Myself, I started with BASIC on a C64, then went into ASM on the same machine before learning Pascal and C on a PC. So I had all of that under my belt when I went to college and learned with .. SICP, but I totally appreciate that what I thought about programming from "before" college and what I thought after college were like different worlds of understanding, understanding I wish I had when I first started writing stuff in BASIC.

Hypercard all the way. You can drag-and-drop UI components and graphics. the language is easy to read, the event model is simple, and you have plenty tools at your disposal to make animations and play sounds. What's not to like?