Related
I am doing a design and build dissertation for my final year.
Everything is more or less good, except I cant find a software methodology to fit my process.
Basically I did the implementation FIRST and then from that I used tools to reverse engineer class diagrams, ERD, etc...
I can blag that I followed the waterfall method or something, but I would rather try to find an actual Software Development Mythology which does the implementation first.
I do know that is REALLY bad and is probably non-existing, however its small project and personal use only.
any helpful suggestions are greatly appreciated.
If you didn't design it first I don't think it will fit in any DESIGN pattern...
Most of the Design patterns are focused on designing it first, to save you the trouble of ending up with a bad software poorly designed.
You can just say you did the design you reversed engineered and followed it, assuming it fits any design pattern.
If the project is small enough to excuse doing something you say is "bad," maybe it's small enough to redo in a way that's "right." Just pick a methodology, (re)design your project according to that methodology, then re-code it according to the design. That way you wouldn't have to fudge anything.
There is no real process or software model that endorses coding before anything else. Well, technically there is the "Code-like-hell" approach but that is universally condemned (and not actually even a "real" approach in that it's considered a mistake.)
(See #27: http://www.stevemcconnell.com/rdenum.htm)
Most software models and processes exist to bring engineering principles to projects, and coding before planning is not an engineering principle. Granted, it's not necessarily wrong on an incredibly small project to just go ahead and code (most people would do it that way). At the same time, it does not follow any type of process or model that is well-established or almost universally accepted.
Your best options now are to redo it, say you reverse engineered it, or try to fudge it to fit some type of model, but I can't actually endorse doing the last one as it would probably end up just becoming lying.
Read about XP: extreme programming
http://www.extremeprogramming.org/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've been browsing Bjarne Stroustrup's new introductory programming book, Programming: Principles and Practice Using C++. It's meant for first-year university computer science and engineering students.
Early on in the book he works through an interesting extended example of creating a desktop calculator where he ends up implementing an arithmetic expression evaluator (that takes bracketed expressions and operator precedence into account) in a series of co-recursive functions based on a grammar.
This is a very interesting example, although arguably on the complex side for a lot of beginners.
I wonder what others thing of this particular example: would learning programming by seeing how to implement an expression parser excite and motivate you, or would it discourage you because of all the details and complexity?
Are there other good "real" programming examples for beginners?
When I was first learning to program, the best example I ever worked with was building a text adventure game from scratch. The basics just required knowing how to display text on the screen, receive input from the keyboard, and rudimentary flow control. But since text adventures always have room to add more features/puzzles/whatever, they can be easily adapted to explore aspects of whichever language you're learning.
Of course, not everyone finds games more interesting than calculators. It really depends on the programmer.
First, let me say that cognitive psychologists have proven in numerous studies that the most important factor in learning is desire to know.
If you want to learn about programming, you need to find a domain that stokes your desire to understand. Find a challenge that can be solved with programming.
I agree with the other folks when they suggest something that you are interested in. And games seem to be a common thread. As I reflect on my experience learning to program (too many years ago), math problems and a simple game was involved.
However, I don't think I really understood the power of software until I created a useful small program that helped a business person solve a real problem. There was a tremendous amount of motivation for me because I had a "client". I wasn't getting paid, but the client needed this program. There was sincere pain (gotta get my job done quicker) related to this situation.
So my advice is to talk to people you know and ask what small annoyance or computer-related obstacle to they have. Then try to fix it. It may be a simple web widget that reduces repetitive, manual tasks for an office worker.
One of my best early works was helping a little printing shop (no software, circa 1985) that struggled with estimating jobs to produce proposals that weren't money-losers. I asked alot of questions of the sales lady and of the operations manager. There was obviously an intersection of a common pain point with a really easy calculation that I could automate. It took me a couple of days to learn Lotus 1-2-3 (spreadsheet for you young-uns) enough to write a few macros. I was motivated. I had passion. I saw where I could make a difference. And that, more than anything else, drove me to learn some simple programming.
Having real people, real problems, and really simple solutions could be the inspiration you need as a beginning programmer. Don't try to write an accounting system. Just take one discreet piece of someone's frustration away. You can build on that success.
So, I wouldn't focus on the technique (yet). Don't worry about, "Am I doing this the most efficient way?" The main objective for a beginner is to have success, no matter how small, and build confidence.
BTW, that Lotus 1-2-3 set of macros grew into a full job tracking system. Very archaic, limited features, but made that little print shop much more profitable.
Create your motivation, fuel your desire, and develop your passion for programming like an artist unveils the masterpiece in a blob of clay. And be persistent. Don't give up when challenged with a roadblock. We all get stumped sometimes. Those are some of the best learning moments because humans learn more from failure than success.
Good luck.
I think making tiny games like text version of Tetris will be a good way of getting into pragramming world.
Board games are fun to design and code since they come in many shapes and difficulties
from tic-tac-toe to checkers to monopoly, its reinventing the wheel for educational purposes!
the best advice i can think of is to pick something from a field of interest you have because coding for the sake of coding might dim your resolve
Start small. Do examples that interest you. Stretch yourself just a little every time. Get comfortable with each step, to the point that you have confidence that you know what you're doing, and then try something a little harder the next time.
I think that any example program would help you learn a new language, but a beginner should try to work with something that is easy to understand in the real world, such as a mortgage calculator or something along those lines.
I think the answer is that it would depend on the person who is learning how to program.
One nice thing about something like an arithmetic expression evaluator is that it is a project that can start very small (make it work with just the format "X SYMBOL Y" where X and Y are single-digit numbers and SYMBOL must be a plus sign) and then you are slowly expanding the functionality to the point of a complicated system.
However, it might not be a great starter project for someone who doesn't really understand the concept of computers (hard disk, memory, etc.)
Try to think of something that you do on a computer that is repetitive, and could be easily automated. Then try to come up with how to make a program that automates that task for you. It can be anything, whether it's popping up a reminder every 15 minutes to stretch your legs or cleans up your temp directory on a regular basis.
The problem with this task is that it's conplex and not real life related. I don't need another calculator.
But once I had a CD with scratched surface near its center and lots of valuable JPEG files inside. I dumped the data from the unscratched part of the disk but all the filesystem was surely lost. So I wrote a program which analysed the dump and separated it into files. It was not very simple but was a nice and exciting file IO programming exercise.
Examples can be more complex than something you try to write yourself. It's easier to follow someone else doing something than it is to do it yourself. A real-world example like this calculator may be a fine way to introduce someone to a language. For instance, Practical Common Lisp starts with an example of an in-memory database (for CDs I think) and uses that as the springboard to explore parts of the language.
I prefer seeing a real example built up over time than just a lot of simple "Hello World" programs.
I've always found that implementing a game of some sort is sufficient incentive to learn various features of a language. Card games, especially, because they generally have simple rule sets to implement, but are sufficiently complex from an abstract point of view.
I would agree, though, with everyone else: find examples of things that interest you. Not everyone is a game fan, but something like a mortgage calculator would be far more interesting.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I am doing some research into common errors and poor assumptions made by junior (and perhaps senior) software engineers.
What was your longest-held assumption that was eventually corrected?
For example, I misunderstood that the size of an integer is not a standard and instead depends on the language and target. A bit embarrassing to state, but there it is.
Be frank; what firm belief did you have, and roughly how long did you maintain the assumption? It can be about an algorithm, a language, a programming concept, testing, or anything else about programming, programming languages, or computer science.
For a long time I assumed that everyone else had this super-mastery of all programming concepts (design patterns, the latest new language, computational complexity, lambda expressions, you name it).
Reading blogs, Stack Overflow and programming books always seemed to make me feel that I was behind the curve on the things that all programmers must just know intuitively.
I've realized over time that I'm effectively comparing my knowledge to the collective knowledge of many people, not a single individual and that is a pretty high bar for anyone. Most programmers in the real world have a cache of knowledge that is required to do their jobs and have more than a few areas that they are either weak or completely ignorant of.
That people knew what they wanted.
For the longest time I thought I would talk with people, they would describe a problem or workflow and I would put it into code and automate it. Turns out every time that happens, what they thought they wanted wasn't actually what they wanted.
Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.
I guess this answer is similar to Robin's about non-programmers understanding/caring about what I'm talking about. It's about learning the business as an agile, iterative, interactive process. It's about learning the difference between being a programming-code-monkey and being a software developer. It's about realizing that there is a differnce between the two and that to be really good in the field, it's not just syntax and typing speed.
Edit: This answer is now community-wiki to appease people upset at this answer giving me rep.
That I know where the performance problem is without profiling
That I should have only one exit point from a function/method.
That nonprogrammers understand what I'm talking about.
That bugfree software was possible.
That private member variables were private to the instance and not the class.
I thought that static typing was sitting very still at your keyboard.
That you can fully understand a problem before you start developing.
Smart People are Always Smarter than Me.
I can really beat myself up when I make mistakes and often get told off for self-deprecating. I used to look up in awe at a lot of developers and often assumed that since they knew more than me on X, they knew more than me.
As I have continued to gain experience and meet more people, I have started to realise that oftentimes, while they know more than me in a particular subject, they are not necessarily smarter than me/you.
Moral of the story: Never underestimate what you can bring to the table.
For the longest time I thought that Bad Programming was something that happened on the fringe.. that Doing Things Correctly was the norm. I'm not so naive these days.
I thought I should move towards abstracting as much as possible. I got hit in the head major with this, because of too much intertwined little bits of functionality.
Now I try keep things as simple and decoupled as possible. Refactoring to make something abstract is much easier than predicting how I need to abstract something.
Thus I moved from developing the framework that rules them all, to snippets of functionality that get the job done. Never looked back, except when I think about the time I naively thought I would be the one developing the next big thing.
That women find computer programmers sexy...
That the quality of software will lead to greater sales. Sometimes it does but not always.
That all languages are (mostly) created equal.
For a good long while I figured that the language of choice didn't really make much of a difference in the difficulty of the development process and the potential for project success. This is definitely not true.
Choosing the right language for the job is as important/critical as any other single project decision that is made.
That a large comment/code ratio is a good thing.
It took me a while to realize that code should be self documenting. Sure, a comment here and there is helpful if the code can't be made clearer or if there's an important reason why something is being done. But, in general, it's better to spend that comment time renaming variables. It's cleaner, clearer and the comments don't get "out of sync" with the code.
That programming is impossible.
Not kidding, I always thought that programming was some impossible thing to learn, and I always stayed away from it. And when I got near code, I could never understand it.
Then one day I just sat down and read some basic beginner tutorials, and worked my way from there. And today I work as a programmer and I love every minute of it.
To add, I don't think programming is easy, it's a challenge and I love learning more and there is nothing more fun than to solve some programming problem.
"On Error Resume Next" was some kind of error handling
That programming software requires a strong foundation in higher math.
For years before I started coding I was always told that to be a good programmer you had to be good at advanced algebra, geometry, calculus, trig, etc.
Ten years later and I have only once had to do anything that an eighth grader couldn't.
That optimizing == rewriting in assembly language.
When I first really understood assembly (coming from BASIC) it seemed that the only way to make code run faster was to rewrite it in assembly. Took quite a few years to realize that compilers can be very good at optimization and especially with CPUs with branch prediction etc they can probably do a better job than a human can do in a reasonable amount of time. Also that spending time on optimizing the algorithm is likely to give you a better win than spending time converting from a high to a low level language. Also that premature optimization is the root of all evil...
That the company executives care about the quality of the code.
That fewer lines is better.
I would say that storing the year element of a date as 2 digits was an assumption that afflicted an entire generation of developers. The money that was blown on Y2K was pretty horrific.
That anything other than insertion/bubble sort was quite simply dark magic.
That XML would be a truly interoperable and human readable data format.
That C++ was somehow intrinsically better than all other languages.
This I received from a friend a couple of years ahead of me in college. I kept it with me for an embarrassingly long time (I'm blushing right now). It was only after working with it for 2 years or so before I could see the cracks for what they were.
No one - and nothing - is perfect, there is always room for improvement.
I believed that creating programs would be exactly like what was taught in class...you sit down with a group of people, go over a problem, come up with a solution, etc. etc. Instead, the real world is "Here is my problem, I need it solved, go" and ten minutes later you get another, leaving you no real time to plan out your solution efficiently.
I thought mainstream design patterns were awesome, when they were introduced in a CS class. I had programmed about 8 years as hobby before that, and I really didn't have solid understanding of how to create good abstractions.
Design patterns felt like magic; you could do really neat stuff. Later I discovered functional programming (via Mozart/Oz, OCaml, later Scala, Haskell, and Clojure), and then I understood that many of the patterns were just boilerplate, or additional complexity, because the language wasn't expressive enough.
Of course there are almost always some kind of patterns, but they are in a higher level in expressive languages. Now I've been doing some professional coding in Java, and I really feel the pain when I have to use a convention such as visitor or command pattern, instead of pattern matching and higher order functions.
For the first few years I was programming I didn't catch on that 1 Kbyte is technically 1024 bytes, not 1000. I was always a little perplexed by the fact that the sizes of my data files seemed slightly off from what I expected them to be.
That condition checks like:
if (condition1 && condition2 && condition3)
are performed in an unspecified order...
That my programming would be faster and better if I performed it alone.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation.
With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
Have you ever played "telephone?" I don't think you should play it with your codebase.
What if the senior programmer leaves the company/project?
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of
the design and note how often you
have to refer to it.
Document stuff that is always a pain
to work with.
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm preparing to teach someone to program. When I learned the course material, I used turtle graphics for the first few exercises. In reading introductory textbooks, I have not found one that uses the technique. Did others find this approach helpful? If not, what is a better way to learn to program?
I think it depends on age of the target group.
If they are children (I would say up to 12-14 years), doing any easy graphics is a good way to motivate them; on the other hand, don't expect them to learn much about real programming or algorithms.
If they are teens (14-18), it's perhaps still good to use some algorithms that give pretty results (for example 3D or fractals), but since they are older and capable of more abstract thinking, I don't think 2D turtle graphics is interesting enough.
If they are older, doing any graphics is a distraction. At that age, they should have enough inner motivation to learn without anything fancy.
To sum up, I think that fancy graphics serves more motivational role (that you see what you did fast, and it's easy to show others what can you do with a computer) than learning role (that it would make learning real programming easier).
In the late 80s, before I was programming in C, I was programming in Applesoft BASIC and Logo. As a child I thought the turtle was great because it make programming simple. If I decide to teach my children Logo I will probably start here to get an actively developed Logo interpreter.
The key thing about LOGO is user-defined functions. It is very good at conveying that, as long as you emphasize it. Show interactively how to draw a square, then make a new word called square. Then show how you can draw patterns using square. Then make those patterns into words, and so on.
You could do worse in teaching programming than using a tool like Scratch. It's a drag and drop programming interface and can be used to teach basic concepts of programming with some fun visual results (as can be seen from the gallery on their website).
Rob
Logo gave me a very clear picture (no pun intended) on how recursive functions would work, and since I was doing assembly programming at the time, the need to return to the previous state when returning to a method became very clear with Logo.
Recursive implementations of things where also very easy to see the effect of.
I wrote script/code in a c-like dialect for a game called Doom2 before I knew what programming was, so when it came to seriously learning about concepts such as pointers, inheritance and polymorphism I found the basics a breeze because I could construct a mental model to not only help me understand, but also appreciate how cool things like pointers and arrays are.
A friend of mine is a good programming student, but he gets frustrated when he can't visualize an algorithm working, when I was starting to help other students I found they had the same problem, if they can't see something working it's harder to appreciate as a fledgling programmer, the same friend eloquently suggested I "Show 'em some crazy pimp shit and then show them how it's done". He's right, even if someone really wants to learn something they'll be able to draw on more mental energy if they think what they're learning lets them do awesome things.
My best bit of advice is this: AT THE START SPEND AS LITTLE TIME PROGRAMMING TO THE CONSOLE AS POSSIBLE
It makes you feel constrained and your efforts appear futile, only after you appreciate it as a front end should it be used for learning to program. I wouldn't use logo myself because I don't think it can teach concepts such as the aforementioned polymorphism or inheritance nearly as well as other methods, I know a friend of mine is teaching a teenager how to program using XNA in a wrapper, I think anything that can let you blit an image to the screen is fine. That way you can see why you'd want an abstract base class called EnemyEntity with behavior that's inherited by zombie and dog etc. It's not that the concepts are hard to understand, it's just that at first they're hard to appreciate.
I could go on but I think that puts across what I've learned by teaching others. I think using graphics in teaching programming allows students to gain the ability to build mental models of intangible concepts faster than any other.
XNA If you want to teach C# that's an amazing graphics library, just write a wrapper sprite class to hide as much complexity when first starting out and teaching concepts.
SDL A lower level library if you're going to start with c++
During one of my first-year computer science papers we used Java to create fractal patterns via a turtle object.
It was pretty fun to see visually whether or not we had correctly implemented the algorithm required to produce a certain pattern. However, so answer the main question, I wouldn't say that programming via a turtle is useful. I'd say the best way to teach someone to program is to get them to build their own app to do whatever they want it to do. This gives them creative control, plus if they get stuck they can learn how to resolve a problem.
I strongly suggest to start with a interpreted language like Logo (not compiled) because of the quality of the error messages. Reading error messages is very important in this process. Also, at the easy level, Logo allows you to run your instructions one by one in direct mode and carry them to your procedures when you get the expected results.
# Alex: MicroWorlds is a commercial version of Logo and it does exist in English, Spanish, Portuguese, Italian, Russian, etc. it's a big plus if you are not a native English-speaking person.
LOGO is not only Turtle-Graphics.
There are also other interesting concepts in it which come from LISP.
'Turtle' is just icing on the cake and the "imperative" side of Logo.
:)
I learned to program in BASIC by writing simple programs drawing faces (I mean circles and squares) on the screen. Somehow the whole turtle programming was never my thing, although a few of my friends learned that way. Later on I moved to Pascal, then to Delphi, Java and C++/C#.
In my opinion the trick is to "wow" your student and impress/empower with potential things that you can accomplish by writing your own programs. I would actually demonstrate some GUI programming or game programming. It's much easier to learn the basics by keeping the end goal in mind.
Recently I came across SmallBasic - a cool programming environment for kids designed to teach concepts. I would give that a try. It comes with a pretty complete paper describing how to use it.
When I got my first computer (VIC-20) and started programming it was very hard to explain to my parents what I was doing.
My mother tok a course in computing preparing for a project of computerizing the library she worked in. They had a couple of classes introducing them to programming. After learning LOGO she came home and said that she suddenly understood what I was into.
So LOGO with turtle graphics brought us closer together!
I did a "computing for kids" course in the late eighties, and there was an extensive section on turtle graphics using logo. In all honesty I was bored to tears, and learned virtually nothing from it.
I think "programming the turtle" might work better for someone who is artistically inclined, or hugely into geometry, but by and large, there are far more interesting problems to attack, even for kids.
Ah, the memories of good old Logo. I think I got more of a geometry lesson than a programming lesson out of it, e.g. figuring out how much to turn at various points to produce a particular shape, design or pattern. It may work if you plan on mixing geometry with the programming, but if the person doesn't have the basics of geometry, e.g. what is a square and how is it different from other 4-sided shapes, what is a triangle, etc.
I used logo and turtle at school too, a great introduction.
It looks like our kids will be getting a slightly updated interface with Microsoft Kodu. It looks very impressive. It's an icon based programming language made for creating games that runs on X-Box Live.
I'm currently learning python and using a little bit of turtle. In labs we haven't used it, but our homework does. It's nice to know it exists, and it's a good way to get certain commands and syntax in. Overall I don't feel it was completely necessary though.
When I was young, I found it very interesting. It was one of the first programming languages that I've learned, even though I've used it for about two days. It started my interest in programming.
Nowadays, I think the syntax is a bit unclear because most statements are abbreviations. Nowadays, computers are far more powerful thus the language could profit from clearer statement. Another factor is the native language of the person who is learning to use it. If English is not your native language then Logo becomes a bit more complex to understand. So if you're teaching Logo to children, make sure they're familiar with English terms first. (Quite easy if you're a native English-speaking person. More complex if you're originally Dutch, German, French, Portuguese. Even more complex if you're Russian or Chinese because you'd have to adjust to a different character set too.)
I have just begun teaching my 7-year-old how to program using Logo, and he is having a load of fun with it. The commands are easy enough for his limited reading ability and he just loves drawing cool pictures using the turtle graphics. I was amazed at how well he retained what he had learned using it, so I feel it was a good choice for his age.
For older kids (or adults) other languages might have more advantages as a beginner language though
Personal experience, YMMV...
My first encounter with a computer was turtle graphics in my early teens. I loved and was immediately hooked. (Perhaps because for the first time someone [something] did exactly what I told it to do?)
The visual and instant feedback made me want to do more and more. I really wanted to figure out how to replicate the pictures I saw in the book I was using. Without me even classifying it as "work", it slowly built up my early programming skills and my confidence I could learn on my own.
I credit it with sending me in the path I'm in today, a happy software developer who can't believe I get paid to do this work (I know, I know - all corporate snickering aside, I like my work).
As I said, YMMV.