Re: [Tutor] Learning to program, not code.
> > I'm 28 years old, currently unemployed and not in school until fall of > 2015 as a junior. I picked up python a little under a year ago, with the > hopes that I could make a career out of programming - when I finish school > that is. So, as of right now you could say it's a hobby, however, I > figured that I would jump the gun and learn it now, on my own, with widely > available resources we have today. Currently, I have a solid foundation of > how data structures and how OOP works, but the problem lies within having > analysis paralysis. I have a tendency to over analyze everything, and with > programming - as we all know - there are a million ways to accomplish the > same task. > On Fri, Dec 19, 2014 at 8:06 AM, Dave Angel wrote: > On 12/18/2014 09:09 PM, Brandon Dorsey wrote: > >> Hello All, >> >> Programming has always been a passion of mine, >> > > A great start. Can you tell us a little more about yourself? Is Python > the first language you've tried, or are you successful at other languages? > Are you in school, at what level, do you already have some other career and > this is a hobby? Do you have some hobbies that programming might synergize > with? > > > however, I'm frequently > >> frustrated at >> >> simple fact that I've been learning python for 8 months, and I have yet to >> start, and finish, a simple >> >> project. >> > > How are you learning python? Are you in a class, did you buy a book, > download a tutorial, what? > > I find difficult to not only visualize the execution, >> > > There are tools that may help with that, but it's not clear to me whether > that would really help. If you want to play, you could look at: > > ttp://www.pythontutor.com/visualize.html#mode=edit > > but to figure out when and where to >> >> use data structure 'x'. >> > > Alan gave some brief descriptions. You should realize that those are just > the particular collections that are in the builtin section of python. > There are many more in the standard library, MANY more out on the internet > (eg. pypi), and many more in your head, just aching to come out. > > Any suggestions on how to approach programming > >> from a different angle? >> > > That's a great perspective. > > We're now drowning in a sea of riches, information on any topic. But in > most cases, you have to be introduced to a topic systematically, with > controlled flow, in order to understand what the fancier concepts are all > about. When I "started" programming in 1966, it was with a borrowed > Fortran book over spring break. I wrote a number of programs on sheets of > paper, but had no machine to execute them on. (I also expect there were > more errors than useful statements, but I didn't know anything about that > either) I went on a field trip to the nearest computer, which was at > Yale. I got to see the actual machinery through some large windows, but > didn't have a chance to run anything till almost a year later, at my own > college. Even then, freshmen weren't taught anything about them, and I had > to learn from another student how to submit punched cards to the computer. > And how to run jobs without having a legitimate account. > > Frequently when people develop an interest in programming now, it's in > order to write a game, design a website, or to solve some fairly complex > problem. If they then try to research the tools, they get overwhelmed with > the possibilities. And without a narrower focus, they never get that > satisfaction that comes with finishing a project. > > Without knowing anything at all about you really, I'd suggest you either > take a course, or really *do* a tutorial. Many people just read a book (or > site) about the subject, and don't actually try the exercises. In my case > it was excusable, since I didn't have the several million dollars necessary > to buy a computer, but the principle still holds. Start small, and > systematically build up your abilities. If you're disciplined enough to do > that on your own, there are many Python tutorials that you can download. > And when you get stuck, you'll have a manageable problem that somebody can > help with. > > If you've done all that, and you're still stuck, then be much more > specific in your question here. Pick a project (or exercise, or > assignment) that you've started working on, and describe the following: > > 1) python version and OS version > 2) project description > 3) code fragment that shows your present difficulty > 4) what happens, and what you hoped would happen > 5) any error messages (show the full stack trace) you get > 6) meaningful subject line > > Python is a fabulous language for learning. You can get feedback a few > seconds after you run the code, and you can make a change and try again in > under a minute. I worked in one environment where the turnaround for a > compile was about a day and a half. And in another where the compile of > the complete application was done only once a week, and making it was
Re: [Tutor] Learning to program, not code.
On Sun, Dec 21, 2014 3:30 AM CET Dave Angel wrote: >On 12/20/2014 08:16 PM, Brandon Dorsey wrote: >> >> I'm 28 years old, currently unemployed and not in school until fall of >> 2015 as a junior. I picked up python a little under a year ago, with the >> hopes that I could make a career out of programming - when I finish school >> that is. So, as of right now you could say it's a hobby, however, I >> figured that I would jump the gun and learn it now, on my own, with widely >> available resources we have today. Currently, I have a solid foundation of >> how data structures and how OOP works, but the problem lies within having >> analysis paralysis. I have a tendency to over analyze everything, and with >> programming - as we all know - there are a million ways to accomplish the >> same task. >> > >Why do you quote your own remarks, instead of just writing them? And why were >they at the beginning of the message instead of following the context you were >actually quoting? > >Now that I've figured out which part of the message was yours, I can respond. > >You don't say what your major is, nor what you have been actually doing to >develop your skill at Python. My guess is that you're picking too-ambitious >tasks, and that you have not actually worked through the beginning problems of >whatever tutorial you've worked on. There's a reason my college required >homework to be done and turned in, in most classes, at the more elementary >levels. > >It's easy to think you know more than you do, I don't say that to offend, but >to try to help you get perspective. If you've been jumping ahead, perhaps >that's the best way for you to learn, but it's not for everyone. > >Pick a simpler problem, and fully chase it down. Do NOT try to get the >perfect algorithm, try to get a complete working implementation of the entire >problem. Analysis is fine, but start by decomposing the problem into pieces >you can solve exactly, then plug them together to make up a complete program. > >And if you've picked the right boundaries for the decomposition, you could >then go back and optimize individual pieces, in various ways. But for many >problems, maybe even most, it just doesn't matter. In real life, you'll find >that there are just a few places where things have to be reworked for >performance, and until you've got a lot of experience, you'll always guess >wrong what those will be. Once you have a lot of experience, you'll merely >usually guess wrong. That's why it's important to solve the whole problem >before trying much to optimize any particular piece. > >If you think there are a million ways to solve a task, then the task is too >big to consider as a whole. Decompose it into pieces small enough that there >are only a dozen for any one of the subtasks. Then pick one of the dozen, and >get it done. Do it in such a way that it can be described on its own, tested >on its own, and maybe even shipped on its own. Don't postpone writing unittests (don't use doctest). They really give you focus and confidence (peace of mind!). If you also use version control, you can automatically run all tests before each commit. >So enough for generalities. After you've picked a task, and divided it into >subtasks, try to solve one of those subtasks, and show us what you're trying, >what you've done, and what you don't like about it. > >You'll get lots of advice, some of it very good. Just remember that many of >us love to prematurely optimize (it's fun),, and you're at the wrong stage to >be doing that. So go ahead and write loops instead of list comprehensions. >Worry more about whether the variable names make sense, whether the functions >are trying to do too much, and whether you're making too many untested >assumptions about the outside world. > >-- DaveA >___ >Tutor maillist - Tutor@python.org >To unsubscribe or change subscription options: >https://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
Albert-Jan Roskam writes: > Don't postpone writing unittests (don't use doctest). They really give > you focus and confidence (peace of mind!). Excellent advice. Write unit tests as a way of documenting what you want the function to do, and also to document what the function did wrong in that bug you just found :-) (Although, I'd modify the above to: do use doctest, but *not* for unit tests. Use doctest only for testing code examples you already have in your documentation, it's good for that.) > If you also use version control, you can automatically run all tests > before each commit. There's no “if” there. Use a distributed version control system (Mercurial is good and is written in Python), and always make small easily-described commits while working. -- \“Visitors are expected to complain at the office between the | `\ hours of 9 and 11 a.m. daily.” —hotel, Athens | _o__) | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
On Sun, 21 Dec 2014 21:15:43 +1100 Ben Finney wrote: > Use a distributed version control system > (Mercurial is good and is written in Python) I'm beginning to really appreciate [fossil](http://fossil-scm.org/). Re: "Learning to program, not code". Is that like learning to think rather than (or before) learning to express your thoughts? Hmm, I'll have to think about that... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Learning to program, not code.
On 21/12/14 09:21, Albert-Jan Roskam wrote: Don't postpone writing unittests (don't use doctest). But do wait till you know what you will be testing. You can't write a unit test until you have a unit in mind. The OP seems to be struggling to figure out what units he needs. Once he has done that, unit testing can be included as part of the normal discipline of writing code. But you need to know the structure before you get to that stage. But even with system testing the first challenge is still to understand what it is you are trying to build. Until you understand the problem you can't deliver a solution nor can you test if the solution is correct. They really give you focus and confidence (peace of mind!). Often misplaced! Remember that unit tests only test units, you also need system tests and very few unit testing frameworks are any good at that. And especially where GUI front ends are used. There are UI testing frameworks and they help, but the real challenges in testing any system are the test data build and the timing and synchronising of the tests. Of course, system testing should never, ideally, be done by the programmers who wrote the code, but "ideally" often isn't possible... If you also use version control, you can automatically > run all tests before each commit. In theory yes, but if it's a big system that may not be practical. retesting 10,000+ files takes a long time even on modern computers. Now I doubt if many readers of this list are working on 1 file codebases but you need to bear in mind that some day you may be and these *rules* don't always apply. I've worked on systems where running a full build/test cycle took 3 to 4 days. It was usually done over the weekend and Mondays and Tuesdays were reserved for bug fixing. The aim being to have a new working system every Wednesday morning. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Fwd: Re: Learning to program, not code. [LONG RESPONSE!]
It appears that Michael only sent this to me when I think he meant to send it to the list... -- Forwarded message -- From: "Michael Shiloh" Date: Dec 21, 2014 7:25 PM Subject: Re: [Tutor] Learning to program, not code. [LONG RESPONSE!] To: "boB Stepp" Cc: > On Fri, Dec 19, 2014 at 08:12:14PM -0600, boB Stepp wrote: > > On Thu, Dec 18, 2014 at 8:09 PM, Brandon Dorsey wrote: > > > > > > Hello All, > > > > > > simple fact that I've been learning python for 8 months, and I have yet to > > > start, and finish, a simpleproject. I find difficult to not only visualize > > > the execution, but to figure out when and where to > > > use data structure 'x'.Any suggestions on how to approach programming > > > from a different angle? > > > > I am going to take a stab at this. Perhaps the perspective from a > > non-professional in the world of computer programming might be of > > help. > > Very interesting question, Brandon, and many excellent answers. I like the > comments that Bob made in particular. > > I have two modest suggestions: > > 1) Pretend you are explaining to someone else how to solve the problem (a pet > or stuffed animal would work as well). Pretend the person you're telling knows > very little so that you have to explain in great detail. I find this helps > sometimes, but not always. > > 2) Bob made the wonderful suggestion that if the entire problem seems > overwhelming, but you can see how to work on some small part of it, start with > that. I would add that if some small part of it interests you in particular, > start with that first. If you are excited or motivated, that will help you > push through the bumps in the road. > > I often do the part I'm most curious about first. > > > Good luck, > Michael ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
