info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
My son wants me to teach him Python
278 views
Skip to first unread message
John Ladasky
Jun 12, 2013, 3:46:13 PM6/12/13
to
Hi folks,
My son is 17 years old. He just took a one-year course in web page design at his high school. HTML is worth knowing, I suppose, and I think he has also done a little Javascript. He has expressed an interest in eventually wanting to program 3D video games.
For that purpose, HTML and Javascript are too limited. I hardly consider either one to be a real programming language. I want to get him started with a real applications programming language -- Python, of course. And he's ready to learn. OK, so it's not necessarily a fast enough language for the epic video games he envisions, but it's a darn good start. I'll tax his brain with a compiled language like C at some other time.
He's a smart kid, but prefers to be shown, to be tutored, rather than having the patience to sit down and RTFM. Have any of you been down this road before? I would appreciate it if you would share your experiences, or provide resource material.
Thanks!
My son is 17 years old. He just took a one-year course in web page design at his high school. HTML is worth knowing, I suppose, and I think he has also done a little Javascript. He has expressed an interest in eventually wanting to program 3D video games.
For that purpose, HTML and Javascript are too limited. I hardly consider either one to be a real programming language. I want to get him started with a real applications programming language -- Python, of course. And he's ready to learn. OK, so it's not necessarily a fast enough language for the epic video games he envisions, but it's a darn good start. I'll tax his brain with a compiled language like C at some other time.
He's a smart kid, but prefers to be shown, to be tutored, rather than having the patience to sit down and RTFM. Have any of you been down this road before? I would appreciate it if you would share your experiences, or provide resource material.
Thanks!
Chris Angelico
Jun 12, 2013, 4:02:46 PM6/12/13
to pytho...@python.org
On Thu, Jun 13, 2013 at 5:46 AM, John Ladasky
<john_l...@sbcglobal.net> wrote:
> He's a smart kid, but prefers to be shown, to be tutored, rather than having the patience to sit down and RTFM. Have any of you been down this road before? I would appreciate it if you would share your experiences, or provide resource material.
>
Actually yes! My dad (whose name is also John) asked me the same
<john_l...@sbcglobal.net> wrote:
> He's a smart kid, but prefers to be shown, to be tutored, rather than having the patience to sit down and RTFM. Have any of you been down this road before? I would appreciate it if you would share your experiences, or provide resource material.
>
question, regarding one of my siblings. I put the question to the
list, and got back a number of excellent and most useful answers
regarding book recommendations, and we ended up going with (if memory
serves me) Think Python [1]. It seems to be doing fine, though I've
overheard some issues regarding Tkinter, Python 3.3, and Debian
Squeeze. So be aware that you may have to compile your own Python, and
if you do, you may have to look at what modules get compiled in. But
from my experience of building Python, that's not difficult.
[1] http://www.greenteapress.com/thinkpython/ I think, but DNS on this
computer is broken at the moment so I can't verify that link
ChrisA
Joel Goldstick
Jun 12, 2013, 4:23:21 PM6/12/13
to Chris Angelico, pytho...@python.org
On Wed, Jun 12, 2013 at 4:02 PM, Chris Angelico <ros...@gmail.com> wrote:
> He's a smart kid, but prefers to be shown, to be tutored, rather than having the patience to sit down and RTFM. Have any of you been down this road before? I would appreciate it if you would share your experiences, or provide resource material.
>
There is a google course in python on videos. I believe it has time outs for doing assignments. Here is where you go to get started https://developers.google.com/edu/python/
Actually yes! My dad (whose name is also John) asked me the same
question, regarding one of my siblings. I put the question to the
list, and got back a number of excellent and most useful answers
regarding book recommendations, and we ended up going with (if memory
serves me) Think Python [1]. It seems to be doing fine, though I've
overheard some issues regarding Tkinter, Python 3.3, and Debian
Squeeze. So be aware that you may have to compile your own Python, and
if you do, you may have to look at what modules get compiled in. But
from my experience of building Python, that's not difficult.
[1] http://www.greenteapress.com/thinkpython/ I think, but DNS on this
computer is broken at the moment so I can't verify that link
ChrisA
Chris Angelico
Jun 12, 2013, 4:34:15 PM6/12/13
to pytho...@python.org
On Thu, Jun 13, 2013 at 6:23 AM, Joel Goldstick
<joel.go...@gmail.com> wrote:
>
>
>
> On Wed, Jun 12, 2013 at 4:02 PM, Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Thu, Jun 13, 2013 at 5:46 AM, John Ladasky
>> <john_l...@sbcglobal.net> wrote:
<joel.go...@gmail.com> wrote:
>
>
>
> On Wed, Jun 12, 2013 at 4:02 PM, Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Thu, Jun 13, 2013 at 5:46 AM, John Ladasky
>> <john_l...@sbcglobal.net> wrote:
>> > He's a smart kid, but prefers to be shown, to be tutored, rather than
>> > having the patience to sit down and RTFM. Have any of you been down this
>> > road before? I would appreciate it if you would share your experiences, or
>> > provide resource material.
>> >
>
>
>> > having the patience to sit down and RTFM. Have any of you been down this
>> > road before? I would appreciate it if you would share your experiences, or
>> > provide resource material.
>> >
>
>
> There is a google course in python on videos. I believe it has time outs
> for doing assignments. Here is where you go to get started
> https://developers.google.com/edu/python/
Went digging to see what version they support, and found it - buried -
> for doing assignments. Here is where you go to get started
> https://developers.google.com/edu/python/
and with some FUD:
https://developers.google.com/edu/python/set-up
"For Google's Python Class, you want a python version that is 2.4 or
later, and avoiding the 3.x versions for now is probably best."
I would recommend going with Python 3, preferably 3.3, because that's
the future of Python. Unless you have a good reason for sticking with
2.x, go with 3.x.
ChrisA
Ethan Furman
Jun 12, 2013, 5:31:54 PM6/12/13
to pytho...@python.org
While I agree with Chris that 3.x is best, there is a free class from Udacity that is actually pretty good, even if it
does target Python2 (.7 I believe).
https://www.udacity.com/course/cs101
--
~Ethan~
does target Python2 (.7 I believe).
https://www.udacity.com/course/cs101
--
~Ethan~
John Ladasky
Jun 12, 2013, 6:06:35 PM6/12/13
to
On Wednesday, June 12, 2013 8:34:15 PM UTC, Chris Angelico wrote:
>Unless you have a good reason for sticking with 2.x, go with 3.x.
I agree, Chris, I will be teaching my son Python 3 from the start. In fact, I'm in the middle of a messy upgrade of my own computer to get everything ready for Python 3. Upgrading my son's machine should be less painful, because he doesn't need cutting-edge versions of scipy, wxPython or Matplotlib... but I do hope that some of the game packages, like PyGame, are Python 3-compatible. I haven't checked into that yet.
>Unless you have a good reason for sticking with 2.x, go with 3.x.
John Ladasky
Jun 12, 2013, 6:07:19 PM6/12/13
to
On Wednesday, June 12, 2013 8:02:46 PM UTC, Chris Angelico wrote:
> [1] http://www.greenteapress.com/thinkpython/ I think, but DNS on this
> computer is broken at the moment so I can't verify that link
Your link is correct, thank you!
> [1] http://www.greenteapress.com/thinkpython/ I think, but DNS on this
> computer is broken at the moment so I can't verify that link
Ian Kelly
Jun 12, 2013, 6:22:01 PM6/12/13
to Python
Chris Angelico
Jun 12, 2013, 7:34:04 PM6/12/13
to pytho...@python.org
On Thu, Jun 13, 2013 at 6:34 AM, Chris Angelico <ros...@gmail.com> wrote:
> Went digging to see what version they support, and found it - buried -
> and with some FUD:
>
> https://developers.google.com/edu/python/set-up
> "For Google's Python Class, you want a python version that is 2.4 or
> later, and avoiding the 3.x versions for now is probably best."
>
> I would recommend going with Python 3, preferably 3.3, because that's
> the future of Python. Unless you have a good reason for sticking with
> Went digging to see what version they support, and found it - buried -
> and with some FUD:
>
> https://developers.google.com/edu/python/set-up
> "For Google's Python Class, you want a python version that is 2.4 or
> later, and avoiding the 3.x versions for now is probably best."
>
> I would recommend going with Python 3, preferably 3.3, because that's
> 2.x, go with 3.x.
BTW, just to clarify this statement: I don't object to there being
courses for 2.x that don't touch 3.x (though I'd still use this as a
strong criterion in choosing a course); the bit I object to is the
vague FUD about "avoiding" 3.x, as though that branch isn't stable
yet. If it simply said "For Google's Python Class, you want a Python
version between 2.4 and 2.7.x", that'd be much better.
ChrisA
Rick Johnson
Jun 13, 2013, 12:00:01 AM6/13/13
to
On Wednesday, June 12, 2013 2:46:13 PM UTC-5, John Ladasky wrote:
> [...]
I'm going to suggest a completely different path to enlightenment for the lad. A path that has the potential for semi-instant gratification whilst also humbling the boy to the grim realities of computer graphics and application development. *evil grin*
Since your son has zero experience with both graphical and application based programming i would suggest starting at (near) the very bottom of the GUI spectrum, which, in the Python world would be the Tkinter Canvas.
Some people would suggest starting with "turtle.py", and yes this is a good suggestion, however, i highly suggest that he begin by coding a python turtle program HIMSELF.
But first i would let him use the existing turtle program, play around with it, understand some of the commands, etc... but whatever you do: DON'T LET HIM SEE THE SOURCE CODE! Then i would ask him to think about how this program works in a general manner (psst: remember, he's not a programmer "yet"!).
For starters we know we need to create a "window" (this is where you would explain what a GUI library is. And to satisfy the instant gratification, we should create a window very soon.
After we can create a blank window, we should take this opportunity to quickly cover some of the common subwidgets that can be placed into a window, such as:: "Text", "Entry", "Label", "Button", etc.., and maybe some simple code to display each of them will be fun.
Now that we know "generally" what a GUI is, and we know about windows and sub-widgets, it's time to refocus on the turtle program. We will need to create a drawing area within the window for which to draw the turtle -- enter the Tk::Canvas!
Next we can take a slight tangential meandering and learn about common Canvas primitives (like rectangles and lines and whatever!) Then we should decide which primitive would best suit a turtle, and draw that primitive.
Once we have drawn the turtle, we quickly realize that it needs to sprout some legs and move around. This is where the fun really starts to begin... I think you can figure out where to go from there. Math functions, event processing... fun times!
After he gets a simple turtle program running i would point out that even though he went to quite bit of work to solve this fairly simple problem, most of the really difficult code, like turning pixels on and off, drawing and ordering GUI windows, event loops, etc, etc... has been abstracted away into multiple layers of low level code. Even though the starting point of our project could be considered "slightly low level" relative to Python, there are vast libraries of millions of lines of code, layered one atop the other, making all this possible.
The point of this exercise would be to get him thinking about solving problems instead of just reaching for a prepackaged library, and then not fully appreciating (or furthermore, truly *understanding*) the vast scope of *real* software design.
Anybody can grab PyGame and start making simple games, but do they understand what is going on under the hood? I don't think they need to understand the science behind the internal combustion engine, however, if they cannot explain the basics of how the major components like: electrical, fuel, suspension, drive-train, braking, etc... work, then they lack a fundamental insight into solving complex problems that can arise later.
For instance, if you hear a knocking sound whilst driving but the sound is absent whist idling, you can deduce that the problem most likely exists in the drive-train. From there you'd need to focus in at an even smaller level of detail -- but you could not come to that conclusion if you did not possess (at minimum) a basic understanding of the underlying component systems.
Of course some might say: "Rick, why go to all that trouble when you could traumatize him with openGL instead". And to that i would reply: "Save OpenGL for lesson number two!"
*wink*
> [...]
> He's a smart kid, but prefers to be shown, to be tutored,
> rather than having the patience to sit down and RTFM.
> Have any of you been down this road before? I would
> appreciate it if you would share your experiences, or
> provide resource material.
Hello John.
> rather than having the patience to sit down and RTFM.
> Have any of you been down this road before? I would
> appreciate it if you would share your experiences, or
> provide resource material.
I'm going to suggest a completely different path to enlightenment for the lad. A path that has the potential for semi-instant gratification whilst also humbling the boy to the grim realities of computer graphics and application development. *evil grin*
Since your son has zero experience with both graphical and application based programming i would suggest starting at (near) the very bottom of the GUI spectrum, which, in the Python world would be the Tkinter Canvas.
Some people would suggest starting with "turtle.py", and yes this is a good suggestion, however, i highly suggest that he begin by coding a python turtle program HIMSELF.
But first i would let him use the existing turtle program, play around with it, understand some of the commands, etc... but whatever you do: DON'T LET HIM SEE THE SOURCE CODE! Then i would ask him to think about how this program works in a general manner (psst: remember, he's not a programmer "yet"!).
For starters we know we need to create a "window" (this is where you would explain what a GUI library is. And to satisfy the instant gratification, we should create a window very soon.
After we can create a blank window, we should take this opportunity to quickly cover some of the common subwidgets that can be placed into a window, such as:: "Text", "Entry", "Label", "Button", etc.., and maybe some simple code to display each of them will be fun.
Now that we know "generally" what a GUI is, and we know about windows and sub-widgets, it's time to refocus on the turtle program. We will need to create a drawing area within the window for which to draw the turtle -- enter the Tk::Canvas!
Next we can take a slight tangential meandering and learn about common Canvas primitives (like rectangles and lines and whatever!) Then we should decide which primitive would best suit a turtle, and draw that primitive.
Once we have drawn the turtle, we quickly realize that it needs to sprout some legs and move around. This is where the fun really starts to begin... I think you can figure out where to go from there. Math functions, event processing... fun times!
After he gets a simple turtle program running i would point out that even though he went to quite bit of work to solve this fairly simple problem, most of the really difficult code, like turning pixels on and off, drawing and ordering GUI windows, event loops, etc, etc... has been abstracted away into multiple layers of low level code. Even though the starting point of our project could be considered "slightly low level" relative to Python, there are vast libraries of millions of lines of code, layered one atop the other, making all this possible.
The point of this exercise would be to get him thinking about solving problems instead of just reaching for a prepackaged library, and then not fully appreciating (or furthermore, truly *understanding*) the vast scope of *real* software design.
Anybody can grab PyGame and start making simple games, but do they understand what is going on under the hood? I don't think they need to understand the science behind the internal combustion engine, however, if they cannot explain the basics of how the major components like: electrical, fuel, suspension, drive-train, braking, etc... work, then they lack a fundamental insight into solving complex problems that can arise later.
For instance, if you hear a knocking sound whilst driving but the sound is absent whist idling, you can deduce that the problem most likely exists in the drive-train. From there you'd need to focus in at an even smaller level of detail -- but you could not come to that conclusion if you did not possess (at minimum) a basic understanding of the underlying component systems.
Of course some might say: "Rick, why go to all that trouble when you could traumatize him with openGL instead". And to that i would reply: "Save OpenGL for lesson number two!"
*wink*
Chris Angelico
Jun 13, 2013, 12:08:44 AM6/13/13
to pytho...@python.org
On Thu, Jun 13, 2013 at 2:00 PM, Rick Johnson
<rantingri...@gmail.com> wrote:
> On Wednesday, June 12, 2013 2:46:13 PM UTC-5, John Ladasky wrote:
>> [...]
>> He's a smart kid, but prefers to be shown, to be tutored,
>> rather than having the patience to sit down and RTFM.
>> Have any of you been down this road before? I would
>> appreciate it if you would share your experiences, or
>> provide resource material.
>
> Hello John.
>
> I'm going to suggest a completely different path to enlightenment for the lad. A path that has the potential for semi-instant gratification whilst also humbling the boy to the grim realities of computer graphics and application development. *evil grin*
>
> Since your son has zero experience with both graphical and application based programming i would suggest starting at (near) the very bottom of the GUI spectrum, which, in the Python world would be the Tkinter Canvas.
No. Definitely not. Programming does NOT begin with a GUI. It begins
<rantingri...@gmail.com> wrote:
> On Wednesday, June 12, 2013 2:46:13 PM UTC-5, John Ladasky wrote:
>> [...]
>> He's a smart kid, but prefers to be shown, to be tutored,
>> rather than having the patience to sit down and RTFM.
>> Have any of you been down this road before? I would
>> appreciate it if you would share your experiences, or
>> provide resource material.
>
> Hello John.
>
> I'm going to suggest a completely different path to enlightenment for the lad. A path that has the potential for semi-instant gratification whilst also humbling the boy to the grim realities of computer graphics and application development. *evil grin*
>
> Since your son has zero experience with both graphical and application based programming i would suggest starting at (near) the very bottom of the GUI spectrum, which, in the Python world would be the Tkinter Canvas.
with something *simple*, so you're not stuck fiddling around with the
unnecessary. On today's computers, that usually means console I/O
(actually console output, with console input coming along much later).
ChrisA
Rick Johnson
Jun 13, 2013, 12:47:23 AM6/13/13
to
On Wednesday, June 12, 2013 11:08:44 PM UTC-5, Chris Angelico wrote:
> No. Definitely not. Programming does NOT begin with a GUI. It begins
> with something *simple*, so you're not stuck fiddling around with the
> unnecessary. On today's computers, that usually means console I/O
> (actually console output, with console input coming along much later).
Chris, you're a dinosaur, only thing is, somebody forgot to tell you.
> No. Definitely not. Programming does NOT begin with a GUI. It begins
> with something *simple*, so you're not stuck fiddling around with the
> unnecessary. On today's computers, that usually means console I/O
> (actually console output, with console input coming along much later).
*Everything* these days revolves around graphical interfaces. The console, which was once the dark and mystical battlefield where knighted geeks would slay the plagues of exception demons, has been reduced to a mere: "little black box of nostalgia".
1. Rock is dead...
2. The console is dead...
3. Welcome to the 21st century Chris!
PS: Although i'll bet you think the "rock is dead" mantra is relatively recent, nope! Jim Morrison was singing about it waaay back in 1969!
Andrew Berg
Jun 13, 2013, 1:23:00 AM6/13/13
to comp.lang.python
On 2013.06.12 23:47, Rick Johnson wrote:
> 1. Rock is dead...
Nah, he just does movies now.
Seriously, though, GUI stuff might be okay to learn early on since he's interested in making games. There's no reason to focus heavily on it
this early, however.
--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
> 1. Rock is dead...
Nah, he just does movies now.
Seriously, though, GUI stuff might be okay to learn early on since he's interested in making games. There's no reason to focus heavily on it
this early, however.
--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
Modulok
Jun 13, 2013, 1:30:23 AM6/13/13
to Rick Johnson, pytho...@python.org
>> *Everything* these days revolves around graphical interfaces. The console,
>> which was once the dark and mystical battlefield where knighted geeks would
>> slay the plagues of exception demons, has been reduced to a mere: "little black
>> box of nostalgia".
>> 1. Rock is dead...
>> 2. The console is dead...
I use a console every day and I'm 28 years old. I write code for everything
from Autodesk Maya to web API's to database backends. (Yes, GUI code too.) The
console is far, far from dead. It has a steeper learning curve than a GUI but
even in 2013 it's still invaluable. To date I have not met a good programmer
who doesn't use a console on a regular basis. It's not the only tool in the box
but, properly configured, it's a heck of a good one. I don't see this changing
anytime soon.
Back on topic...
If he wants to learn game programming, teach him game programming. Don't push a
bunch of prerequisites on him that he has to learn first. You'll only kill the
spirit. There's plenty of time to learn the other stuff as needed. You might
look at the Unity game engine. There's a lot of UI to start with for tweaking
assets and a *lots* of programming. There's a free version and tons of
documentation. You might consider signing up for www.digitaltutors.com/ for
additional sources of documentation on both Unity as well as digital content
creation software you'll be using along the way. This will feed his desire to
learn due to the instant gratification of making a 3D "game" in an hour.
Unfortunately, with Unity you don't get to write code in Python, but there's
Boo script which is Python inspired, as well as JavaScript if he's already
comfortable with that. (Eww... but even it has good parts.) If you decide to
get seriously invested in digital content creation software (i.e. Maya, etc)
most of those are scripted in Python. Maya used to be all MEL (and the MEL
interpreter is still supported) but most new code for proprietary tools is done
in Python. (MEL is kind of perverse in comparison.)
Most important of all - keep it fun!
-Modulok-
Ethan Furman
Jun 13, 2013, 1:48:16 AM6/13/13
to pytho...@python.org
On 06/12/2013 10:30 PM, Modulok wrote:
>
> If he wants to learn game programming, teach him game programming. [. . .]
Oh, that reminds me:
http://inventwithpython.com/
Which has a number of free books; the two of interest for your son being:
Invent Your Own Computer Games with Python
Making Games with Python & Pygame
Both are for Python 3.x.
--
~Ethan~
>
> If he wants to learn game programming, teach him game programming. [. . .]
Oh, that reminds me:
http://inventwithpython.com/
Which has a number of free books; the two of interest for your son being:
Invent Your Own Computer Games with Python
Making Games with Python & Pygame
Both are for Python 3.x.
--
~Ethan~
TP
Jun 13, 2013, 4:35:08 AM6/13/13
to Chris Angelico, pytho...@python.org
Here's a link [1] to Chris' original question (and the following answers including mine which mentioned Think Python).
Chris' requirements were slightly different. In your case "Python for Kids - A Playful Introduction to Programming" [2] might be more appropriate as a first book. Despite the title it covers a wide range of topics *specifically geared towards writing a game in Python*. See the detailed table of contents to help decide.
Also Chris has an "unnatural" abhorrence of Python 2.7 :) --- at least as far as learning Python books. As such he dismissed too early what I think might be a great initial (or 2nd) book, Hello Python [3]. To requote the Preface which resonates at least with me:
"I thought back to how I first learned to program. I didn't read an
entire programming book from cover to cover and then write a program
after I knew everything there was to know. Instead I started with a
goal, something that I wanted to do, and worked toward it, figuring
things out as I went. I read programming books from time to time,
but really only to figure out the bits I was stuck on. When I was
done, my programs weren't particularly elegant or fast, but they
were mine---I knew how they worked, and they solved a real problem
that I was having."
Some chapter titles include "Gaming with Pyglet", "Twisted Networking" (which implements a MUD), and "Django" so it covers quite a bit of ground. Again see the detailed table of contents.
Notice that the subtitle for Think Python [4] is "How to Think Like a Computer Scientist" which is not every beginning programmer's goal. Yes, Think Python is free, and yes it's probably quite good, but it's not for everyone. In particular the presentation is a lot drier than the above mentioned books.
Somewhat offtopic but mentioned in the thread: Here's what Elliotte Rusty Harold had to say about Java Console IO in Java I/O, 2nd Edition (OReilly, 2006) which I recently read while helping somewith with their college Java (yuck!) homework:
Many common misconceptions about I/O occur because most programmers'
first exposure to I/O is through the console. The console is
convenient for quick hacks and toy examples commonly found in
textbooks, and I will use it for that in this book, but it's really
a very unusual source of input and destination for output, and good
Java programs avoid it. It behaves almost, but not completely,
unlike anything else you'd want to read from or write to. While
consoles make convenient examples in programming texts like this
one, they're a horrible user interface and really have little place
in modern programs. Users are more comfortable with a well-designed
GUI. Furthermore, the console is unreliable across platforms. Many
smaller devices such as Palm Pilots and cell phones have no
console. Web browsers running applets sometimes provide a console
that can be used for output. However, this is hidden by default,
normally cannot be used for input, and is not available in all
browsers on all platforms.
Yikes, a bit opinionated isn't he? Reminds me of some people on this list :)
Finally, regarding sneering at HTML/Javascript. While I've never used the technology, HTML5/Javascript has the Canvas and possibly WebGL. I've noticed all sorts of new books on the topic, for example:
Core HTML5 Canvas Graphics, Animation, and Game Development (Prentice Hall, 2012)
HTML5 Games Development by Example - Beginner's Guide (Packt, 2011)
HTML5 Games Most Wanted (Friends of Ed, 2012)
Supercharged JavaScript Graphics - With HTML5 Canvas, jQuery, and More (O'Reilly, 2011)
HTML5 Graphics and Data Visualization Cookbook (Packt, 2012)
This in fact "may" be/is the future of graphics programming (at least in terms of # of apps written)? And TypeScript [5] "may" make using javascript (under the hood) less objectionable.
I still agree with your overall approach, learn programming via Python first --- not for god's sake Java, which colleges still think is the bee's knees :). But realize that it's only one tool in the programmer's toolkit and you'll eventually have to learn many languages.
[1] http://mail.python.org/pipermail/python-list/2013-May/646208.html
[2] http://nostarch.com/pythonforkids
[3] http://www.manning.com/briggs/
[4] http://www.greenteapress.com/thinkpython/thinkpython.html
[5] http://www.typescriptlang.org/
Chris' requirements were slightly different. In your case "Python for Kids - A Playful Introduction to Programming" [2] might be more appropriate as a first book. Despite the title it covers a wide range of topics *specifically geared towards writing a game in Python*. See the detailed table of contents to help decide.
Also Chris has an "unnatural" abhorrence of Python 2.7 :) --- at least as far as learning Python books. As such he dismissed too early what I think might be a great initial (or 2nd) book, Hello Python [3]. To requote the Preface which resonates at least with me:
"I thought back to how I first learned to program. I didn't read an
entire programming book from cover to cover and then write a program
after I knew everything there was to know. Instead I started with a
goal, something that I wanted to do, and worked toward it, figuring
things out as I went. I read programming books from time to time,
but really only to figure out the bits I was stuck on. When I was
done, my programs weren't particularly elegant or fast, but they
were mine---I knew how they worked, and they solved a real problem
that I was having."
Some chapter titles include "Gaming with Pyglet", "Twisted Networking" (which implements a MUD), and "Django" so it covers quite a bit of ground. Again see the detailed table of contents.
Notice that the subtitle for Think Python [4] is "How to Think Like a Computer Scientist" which is not every beginning programmer's goal. Yes, Think Python is free, and yes it's probably quite good, but it's not for everyone. In particular the presentation is a lot drier than the above mentioned books.
Somewhat offtopic but mentioned in the thread: Here's what Elliotte Rusty Harold had to say about Java Console IO in Java I/O, 2nd Edition (OReilly, 2006) which I recently read while helping somewith with their college Java (yuck!) homework:
Many common misconceptions about I/O occur because most programmers'
first exposure to I/O is through the console. The console is
convenient for quick hacks and toy examples commonly found in
textbooks, and I will use it for that in this book, but it's really
a very unusual source of input and destination for output, and good
Java programs avoid it. It behaves almost, but not completely,
unlike anything else you'd want to read from or write to. While
consoles make convenient examples in programming texts like this
one, they're a horrible user interface and really have little place
in modern programs. Users are more comfortable with a well-designed
GUI. Furthermore, the console is unreliable across platforms. Many
smaller devices such as Palm Pilots and cell phones have no
console. Web browsers running applets sometimes provide a console
that can be used for output. However, this is hidden by default,
normally cannot be used for input, and is not available in all
browsers on all platforms.
Yikes, a bit opinionated isn't he? Reminds me of some people on this list :)
Finally, regarding sneering at HTML/Javascript. While I've never used the technology, HTML5/Javascript has the Canvas and possibly WebGL. I've noticed all sorts of new books on the topic, for example:
Core HTML5 Canvas Graphics, Animation, and Game Development (Prentice Hall, 2012)
HTML5 Games Development by Example - Beginner's Guide (Packt, 2011)
HTML5 Games Most Wanted (Friends of Ed, 2012)
Supercharged JavaScript Graphics - With HTML5 Canvas, jQuery, and More (O'Reilly, 2011)
HTML5 Graphics and Data Visualization Cookbook (Packt, 2012)
This in fact "may" be/is the future of graphics programming (at least in terms of # of apps written)? And TypeScript [5] "may" make using javascript (under the hood) less objectionable.
I still agree with your overall approach, learn programming via Python first --- not for god's sake Java, which colleges still think is the bee's knees :). But realize that it's only one tool in the programmer's toolkit and you'll eventually have to learn many languages.
[1] http://mail.python.org/pipermail/python-list/2013-May/646208.html
[2] http://nostarch.com/pythonforkids
[3] http://www.manning.com/briggs/
[4] http://www.greenteapress.com/thinkpython/thinkpython.html
[5] http://www.typescriptlang.org/
Chris Angelico
Jun 13, 2013, 4:43:10 AM6/13/13
to pytho...@python.org
On Thu, Jun 13, 2013 at 6:35 PM, TP <win...@gmail.com> wrote:
> Also Chris has an "unnatural" abhorrence of Python 2.7 :) --- at least as
> far as learning Python books.
Thanks for hunting that thread down, I probably should have back when
> Also Chris has an "unnatural" abhorrence of Python 2.7 :) --- at least as
> far as learning Python books.
I mentioned it :)
As to my abhorrence of Py2 - I don't hate the language (and do use it
at times), but if someone's going to learn programming, s/he should
really learn from something with native Unicode strings. Yes, you
could use Python 2 and open with some future directives, but unless
the course/book is written with that in mind, you'll end up having to
unlearn and relearn to master true Unicode handling. No point doing
that when you can just learn on Python 3!
ChrisA
Chris Angelico
Jun 13, 2013, 12:53:57 AM6/13/13
to pytho...@python.org
happily smashed scissors.
2. The console is healthy. It's often now seen alongside a GUI, with
neither being by any means dead. And "glass teletype" is still the
easiest UI to program for in any language.
3. Thanks! I've been here for a while, but it's still nice to be made welcome.
ChrisA
rusi
Jun 13, 2013, 9:01:45 AM6/13/13
to
Python is at least two things, a language and a culture.
As a language its exceptionally dogma-neutral.
You can do OO or FP, throwaway one-off scripts or long-term system
building etc
However as a culture it seems to prefer the OO style to the FP style.
This is unfortunate given that OO is on the down and FP is on a rise.
Some thoughts re OOP: http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-4.html
So my suggestion is use some rigorous FPL like Haskell to learn/teach
programming.
After that you can switch to python or some other realistic language.
Note: I have some serious reservations regarding Haskell
http://blog.languager.org/2012/08/functional-programming-philosophical.html
Nevertheless it seems to be the best there is at the moment.
tl;dr: Haskell is in 2013 what Pascal was in 1970 -- good for
programming pedagogy.
Roy Smith
Jun 13, 2013, 9:07:54 AM6/13/13
to
In article
<545a441b-0c2d-4b1e...@e1g2000pbo.googlegroups.com>,
This is true of all languages. Hang out on the PHP, Ruby, Python, etc,
forums and you quickly learn that the cultures are as different (or more
so) than the languages.
The same is true for the human race. The human race is what it is
partly because of the DNA we mix-and-match every generation, but also
because of the information we pass from brain to brain. Neither one
tells the full story of what we are.
<545a441b-0c2d-4b1e...@e1g2000pbo.googlegroups.com>,
This is true of all languages. Hang out on the PHP, Ruby, Python, etc,
forums and you quickly learn that the cultures are as different (or more
so) than the languages.
The same is true for the human race. The human race is what it is
partly because of the DNA we mix-and-match every generation, but also
because of the information we pass from brain to brain. Neither one
tells the full story of what we are.
rusi
Jun 13, 2013, 9:37:34 AM6/13/13
to
On Jun 13, 6:07 pm, Roy Smith <r...@panix.com> wrote:
> In article
> <545a441b-0c2d-4b1e-82ae-024b011a4...@e1g2000pbo.googlegroups.com>,
question.
So let me try state my point differently:
Python-the-language has strengths that are undermined by the biases in
the culture of Python.
A father wanting to give his son the best may want to apply correcting
anti-biases.
> In article
> <545a441b-0c2d-4b1e-82ae-024b011a4...@e1g2000pbo.googlegroups.com>,
>
> rusi <rustompm...@gmail.com> wrote:
> > Python is at least two things, a language and a culture.
>
> This is true of all languages. Hang out on the PHP, Ruby, Python, etc,
> forums and you quickly learn that the cultures are as different (or more
> so) than the languages.
Umm... Of course. I dont know though how that relates to the OP's
> rusi <rustompm...@gmail.com> wrote:
> > Python is at least two things, a language and a culture.
>
> This is true of all languages. Hang out on the PHP, Ruby, Python, etc,
> forums and you quickly learn that the cultures are as different (or more
> so) than the languages.
question.
So let me try state my point differently:
Python-the-language has strengths that are undermined by the biases in
the culture of Python.
A father wanting to give his son the best may want to apply correcting
anti-biases.
Tomasz Rola
Jun 13, 2013, 11:37:34 AM6/13/13
to
On Thu, 13 Jun 2013, rusi wrote:
> On Jun 13, 12:46 am, John Ladasky <john_lada...@sbcglobal.net> wrote:
> > Hi folks,
> >
> > My son is 17 years old. He just took a one-year course in web page
> > design at his high school. HTML is worth knowing, I suppose, and I
> > think he has also done a little Javascript. He has expressed an
> > interest in eventually wanting to program 3D video games.
[...]
> On Jun 13, 12:46 am, John Ladasky <john_lada...@sbcglobal.net> wrote:
> > Hi folks,
> >
> > My son is 17 years old. He just took a one-year course in web page
> > design at his high school. HTML is worth knowing, I suppose, and I
> > think he has also done a little Javascript. He has expressed an
> > interest in eventually wanting to program 3D video games.
>
> Some views of mine (controversial!).
Not really :-)
> Some views of mine (controversial!).
>
> Python is at least two things, a language and a culture.
> As a language its exceptionally dogma-neutral.
> You can do OO or FP, throwaway one-off scripts or long-term system
> building etc
>
> However as a culture it seems to prefer the OO style to the FP style.
> This is unfortunate given that OO is on the down and FP is on a rise.
> Some thoughts re OOP: http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-4.html
>
> So my suggestion is use some rigorous FPL like Haskell to learn/teach
> programming.
> After that you can switch to python or some other realistic language.
quite decent lang as far as I can tell. And it's compiled, too.
I would also consider Racket, which is a Scheme superset. It too, comes
with compiler/JIT, plus IDE, plus libraries plus I understand examples
from "Structure and Interpretation of Computer Programs",
( http://mitpress.mit.edu/sicp/ ) can be run on it. I have heard some
folks are doing real life stuff with it, too and IDE might help beginner a
lot (this one is very nice, not just magnified editor).
> Note: I have some serious reservations regarding Haskell
> http://blog.languager.org/2012/08/functional-programming-philosophical.html
> Nevertheless it seems to be the best there is at the moment.
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **
Tomasz Rola
Jun 13, 2013, 12:50:29 PM6/13/13
to pytho...@python.org, Eugen Leitl
I've reposted on another list and got this reply. At first I was sceptic
a bit, but for the sake of completeness, here goes. Processing language
seems to be interesting in its own right. Examples are Java-flavoured,
images are ok.
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **
Date: Thu, 13 Jun 2013 16:55:11 +0200
From: Eugen Leitl <eu...@leitl.org>
To: <in...@postbiota.org>
Subject: Re: [info] (comp.lang.python) Re: My son wants me to teach him Python
On Thu, Jun 13, 2013 at 04:48:52PM +0200, Tomasz Rola wrote:
> No. Definitely not. Programming does NOT begin with a GUI. It begins with
> something *simple*, so you're not stuck fiddling around with the
> unnecessary. On today's computers, that usually means console I/O
> (actually console output, with console input coming along much later).
screen, especially if they are colorful, move and make
sounds at that. The next step would be a simple,
interactive game.
Which is why I would synthesize something neat yet
simple from http://processing.org/tutorials/
Python is overkill for a kid. Ugh. Some people have just
no common sense at all.
_______________________________________________
info mailing list
in...@postbiota.org
http://postbiota.org/mailman/listinfo/info
Paul Rubin
Jun 13, 2013, 1:25:17 PM6/13/13
to
Tomasz Rola <rto...@ceti.pl> writes:
> I've reposted on another list and got this reply. At first I was sceptic
> a bit, but for the sake of completeness, here goes. Processing language
> seems to be interesting in its own right. Examples are Java-flavoured,
> images are ok.
There is a book "Python for Kids" that I haven't looked at, from No
> I've reposted on another list and got this reply. At first I was sceptic
> a bit, but for the sake of completeness, here goes. Processing language
> seems to be interesting in its own right. Examples are Java-flavoured,
> images are ok.
Starch Press. You might check into it.
You might also look at the game Code Hero, which teaches kids to program
games with Unity3D and Javascript.
Mark Janssen
Jun 13, 2013, 1:34:53 PM6/13/13
to John Ladasky, pytho...@python.org
> Despite not want to RTFM as you say, you might set him in front of
> VPython, type
I totally forgot PyGame -- another likely source of self-motivated
learning for a teen programmer.
--
MarkJ
Tacoma, Washington
> VPython, type
I totally forgot PyGame -- another likely source of self-motivated
learning for a teen programmer.
--
MarkJ
Tacoma, Washington
rusi
Jun 13, 2013, 1:36:29 PM6/13/13
to
On Jun 13, 9:50 pm, Tomasz Rola <rto...@ceti.pl> wrote:
> I've reposted on another list and got this reply. At first I was sceptic
> a bit, but for the sake of completeness, here goes. Processing language
> seems to be interesting in its own right. Examples are Java-flavoured,
> images are ok.
>
> Regards,
> Tomasz Rola
>
> --
> ** A C programmer asked whether computer had Buddha's nature. **
> ** As the answer, master did "rm -rif" on the programmer's home **
> ** directory. And then the C programmer became enlightened... **
> ** **
> ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
> I've reposted on another list and got this reply. At first I was sceptic
> a bit, but for the sake of completeness, here goes. Processing language
> seems to be interesting in its own right. Examples are Java-flavoured,
> images are ok.
>
> Regards,
> Tomasz Rola
>
> --
> ** A C programmer asked whether computer had Buddha's nature. **
> ** As the answer, master did "rm -rif" on the programmer's home **
> ** directory. And then the C programmer became enlightened... **
> ** **
>
> ---------- Forwarded message ----------
> Date: Thu, 13 Jun 2013 16:55:11 +0200
> From: Eugen Leitl <eu...@leitl.org>
> To: <i...@postbiota.org>
> Subject: Re: [info] (comp.lang.python) Re: My son wants me to teach him Python
>
> On Thu, Jun 13, 2013 at 04:48:52PM +0200, Tomasz Rola wrote:
>
> > No. Definitely not. Programming does NOT begin with a GUI. It begins with
> > something *simple*, so you're not stuck fiddling around with the
> > unnecessary. On today's computers, that usually means console I/O
> > (actually console output, with console input coming along much later).
>
> Of course kids are more interesting in things painted on
> screen, especially if they are colorful, move and make
> sounds at that. The next step would be a simple,
> interactive game.
>
> Which is why I would synthesize something neat yet
> simple fromhttp://processing.org/tutorials/
> ---------- Forwarded message ----------
> Date: Thu, 13 Jun 2013 16:55:11 +0200
> From: Eugen Leitl <eu...@leitl.org>
> To: <i...@postbiota.org>
> Subject: Re: [info] (comp.lang.python) Re: My son wants me to teach him Python
>
> On Thu, Jun 13, 2013 at 04:48:52PM +0200, Tomasz Rola wrote:
>
> > No. Definitely not. Programming does NOT begin with a GUI. It begins with
> > something *simple*, so you're not stuck fiddling around with the
> > unnecessary. On today's computers, that usually means console I/O
> > (actually console output, with console input coming along much later).
>
> Of course kids are more interesting in things painted on
> screen, especially if they are colorful, move and make
> sounds at that. The next step would be a simple,
> interactive game.
>
> Which is why I would synthesize something neat yet
>
> Python is overkill for a kid. Ugh. Some people have just
> no common sense at all.
All kids can be fit into the stereotype -- 'kid'??
> Python is overkill for a kid. Ugh. Some people have just
> no common sense at all.
I can tell you after 25 years teaching programming --
Some kids will take to FP, others will not
Some will take to C, some wont
Some will take to C AND C++, some will take to only one
The majority are ok with python, some hate it
One of my long term projects is to take a type classification like
http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
and see how it maps to a person's potential as a programmer
russ....@gmail.com
Jun 13, 2013, 3:03:03 PM6/13/13
to
I couldn't read every post here so don't know if this has been suggested, or if there is perhaps a better suggestion which I haven't read in this thread, but in as far as I've read I feel the need to recommend:
learnpythonthehardway.org
Knowing a little JavaScript and even allot of HTML doesn't take him out of the total noob category when it comes to programming (did someone say game programming? Hold your horses!). I took a visual basic course (which I dropped out of admittedly after 3 months) and still knew absolutely nothing, which isn't necessarily just because I'm dumb.
After eventually learning Python in incremental and sporadic episodes of free time, I did come across a few resources and by virtue of the frustration of having taken so long to learn to code in the easiest damn programming language to learn, I found myself scrutinizing allot of the tutorials I'd been passing by.
I noticed developers.google.com somewhere up there. That's just a no no. Sorry. Maybe some of the people here are more than "pretty smart" but there's a good chance it'll be over his head at first, and at first is a bad place to be in over your head when you're learning the fundamentals.
I also notice Invent with python. I personally would go for 2.x rather than 3 but that aside, for reasons I'm too tired to word, I didn't find it a good fit for me. I takes a "dive right in" approach and well, I never did learn to swim.
Udacity was the third suggestion I noticed. This is also a no no. I completed the cs101 udacity course which I'm sure is the course in question here, and I loved it! Really I learn crap load from it, but at every step I asked myself, would this had helped if it was the first place I went to to learn to code? No. There were allot of gaps I noticed when looking from a complete beginners perspective and even though the course claims to has no prerequisites, I would have hated if I started with that. However that was last year and I think it was only a few months old, so it may be allot different now, I haven't checked.
I read How to think like a computer scientist, A byte of python, and even the official docs. The only one I came across that made me say "&*#! why didn't I google that?" was learnpythonthehardway.
I do think it depends a great deal on the individual, and for me personally, that style of learning was just it. For one you learn from the bottom up. It's a compulsion for some to know that that know a thing before they're brave enough to move forward. In cases where a "leap" is the only way forward, the tutor pulls you across that divide by your ankles. You feel a sense of obligation to take to his instruction. And above all, it greatly emphasizes the "learn by doing" approach, in small steps, not big projects that you end up completing just to get through it but don't learn much from.
So that's my recommendation. But all that aside, my biggest point would be, just pick one do it. As you can see if you read that, my biggest flaw was simply the lack of devotion to one path.
Game programming if he still wants to do that is another question entirely I feel. Fundamentals are fundamentals. The only variable is how long it might take him to get passed it. Even with Python, some people just never get it.
learnpythonthehardway.org
Knowing a little JavaScript and even allot of HTML doesn't take him out of the total noob category when it comes to programming (did someone say game programming? Hold your horses!). I took a visual basic course (which I dropped out of admittedly after 3 months) and still knew absolutely nothing, which isn't necessarily just because I'm dumb.
After eventually learning Python in incremental and sporadic episodes of free time, I did come across a few resources and by virtue of the frustration of having taken so long to learn to code in the easiest damn programming language to learn, I found myself scrutinizing allot of the tutorials I'd been passing by.
I noticed developers.google.com somewhere up there. That's just a no no. Sorry. Maybe some of the people here are more than "pretty smart" but there's a good chance it'll be over his head at first, and at first is a bad place to be in over your head when you're learning the fundamentals.
I also notice Invent with python. I personally would go for 2.x rather than 3 but that aside, for reasons I'm too tired to word, I didn't find it a good fit for me. I takes a "dive right in" approach and well, I never did learn to swim.
Udacity was the third suggestion I noticed. This is also a no no. I completed the cs101 udacity course which I'm sure is the course in question here, and I loved it! Really I learn crap load from it, but at every step I asked myself, would this had helped if it was the first place I went to to learn to code? No. There were allot of gaps I noticed when looking from a complete beginners perspective and even though the course claims to has no prerequisites, I would have hated if I started with that. However that was last year and I think it was only a few months old, so it may be allot different now, I haven't checked.
I read How to think like a computer scientist, A byte of python, and even the official docs. The only one I came across that made me say "&*#! why didn't I google that?" was learnpythonthehardway.
I do think it depends a great deal on the individual, and for me personally, that style of learning was just it. For one you learn from the bottom up. It's a compulsion for some to know that that know a thing before they're brave enough to move forward. In cases where a "leap" is the only way forward, the tutor pulls you across that divide by your ankles. You feel a sense of obligation to take to his instruction. And above all, it greatly emphasizes the "learn by doing" approach, in small steps, not big projects that you end up completing just to get through it but don't learn much from.
So that's my recommendation. But all that aside, my biggest point would be, just pick one do it. As you can see if you read that, my biggest flaw was simply the lack of devotion to one path.
Game programming if he still wants to do that is another question entirely I feel. Fundamentals are fundamentals. The only variable is how long it might take him to get passed it. Even with Python, some people just never get it.
Joshua Landau
Jun 13, 2013, 4:18:57 PM6/13/13
to Tomasz Rola, python-list, Eugen Leitl
On 13 June 2013 17:50, Tomasz Rola <rto...@ceti.pl> wrote:
> Of course kids are more interesting in things painted on
> screen, especially if they are colorful, move and make
> sounds at that. The next step would be a simple,
> interactive game.
>
> Which is why I would synthesize something neat yet
> simple from http://processing.org/tutorials/
> Of course kids are more interesting in things painted on
> screen, especially if they are colorful, move and make
> sounds at that. The next step would be a simple,
> interactive game.
>
> Which is why I would synthesize something neat yet
>
> Python is overkill for a kid. Ugh. Some people have just
> no common sense at all.
As someone who can only recently claim to be "not a kid", I will again
> Python is overkill for a kid. Ugh. Some people have just
> no common sense at all.
do my duty and counter this point.
GUI is boring. I don't give a damn about that. If I had it my way, I'd
never write any interfaces again (although designing them is fine).
Console interaction is faster to do and it lets me do the stuff I
*want* to do quicker.
Also - Python is pretty much the only language that *isn't* overkill;
once you take more than the first few steps a language that's
*consistent* will help more with learning, á mon avis, than these
"quicker" languages ever will. Python is consistent and simple.
Then, when you're better and you do want to do cool stuff,
Cython/occasionally PyPy/Numpy/Numba etc. let you get C-like speeds
learning no other languages at all (although you do need to get C
types down). That's the easy way out, not
Python-then-C-because-Python-is-slow or some nonsense like that.
Basically, "kid" is a *very* generic term and there are people who
like GUIs and there are people who like internals and there are
hundreds of other classifiers from all over the globe. Please don't
conflate groups if you can help it, as it's often just wrong.
Joshua Landau
Jun 13, 2013, 4:08:28 PM6/13/13
to rusi, python-list
On 13 June 2013 14:01, rusi <rusto...@gmail.com> wrote:
> Some views of mine (controversial!).
>
> Python is at least two things, a language and a culture.
> As a language its exceptionally dogma-neutral.
> You can do OO or FP, throwaway one-off scripts or long-term system
> building etc
>
> However as a culture it seems to prefer the OO style to the FP style.
> This is unfortunate given that OO is on the down and FP is on a rise.
> Some thoughts re OOP: http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-4.html
>
> So my suggestion is use some rigorous FPL like Haskell to learn/teach
> programming.
> After that you can switch to python or some other realistic language.
Hey - Haskell is realistic [1].
> Some views of mine (controversial!).
>
> Python is at least two things, a language and a culture.
> As a language its exceptionally dogma-neutral.
> You can do OO or FP, throwaway one-off scripts or long-term system
> building etc
>
> However as a culture it seems to prefer the OO style to the FP style.
> This is unfortunate given that OO is on the down and FP is on a rise.
> Some thoughts re OOP: http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-4.html
>
> So my suggestion is use some rigorous FPL like Haskell to learn/teach
> programming.
> After that you can switch to python or some other realistic language.
> Note: I have some serious reservations regarding Haskell
> http://blog.languager.org/2012/08/functional-programming-philosophical.html
> Nevertheless it seems to be the best there is at the moment.
>
> tl;dr: Haskell is in 2013 what Pascal was in 1970 -- good for
> programming pedagogy.
> http://mail.python.org/mailman/listinfo/python-list
[1] http://xmonad.org/
Steven D'Aprano
Jun 13, 2013, 8:44:11 PM6/13/13
to
On Thu, 13 Jun 2013 06:37:34 -0700, rusi wrote:
> Python-the-language has strengths that are undermined by the biases in
> the culture of Python.
This implies that there are strengths in Python-the-language which are
> Python-the-language has strengths that are undermined by the biases in
> the culture of Python.
not just missed or ignored by Python programmers immersed in the culture,
but actively (if unconsciously) fought against.
As someone immersed in that culture, and therefore at risk of being
unaware of my biases, I am *very* curious as to what you think they are,
and what strengths of Python you think I might be missing.
--
Steven
Cameron Simpson
Jun 13, 2013, 9:05:25 PM6/13/13
to pytho...@python.org
On 12Jun2013 21:47, Rick Johnson <rantingri...@gmail.com> wrote:
| On Wednesday, June 12, 2013 11:08:44 PM UTC-5, Chris Angelico wrote:
| > No. Definitely not. Programming does NOT begin with a GUI. It begins
| > with something *simple*, so you're not stuck fiddling around with the
| > unnecessary. On today's computers, that usually means console I/O
| > (actually console output, with console input coming along much later).
|
| Chris, you're a dinosaur, only thing is, somebody forgot to tell you.
|
| *Everything* these days revolves around graphical interfaces.
Oh good.
| On Wednesday, June 12, 2013 11:08:44 PM UTC-5, Chris Angelico wrote:
| > No. Definitely not. Programming does NOT begin with a GUI. It begins
| > with something *simple*, so you're not stuck fiddling around with the
| > unnecessary. On today's computers, that usually means console I/O
| > (actually console output, with console input coming along much later).
|
| Chris, you're a dinosaur, only thing is, somebody forgot to tell you.
|
| *Everything* these days revolves around graphical interfaces.
Please communicate entirely in animations from now on. This text
medium you're using is crude, low bandwidth, and not sparkly enough.
But regrettably, I think Rick may be on the money here. All children
want to write games. I did, my friend's son did, etc. But by starting
with something functional but crude, he will be forced to encounter
the basic tools of coding anyway.
Cheers,
--
Cameron Simpson <c...@zip.com.au>
This is not my farewell to you. My only wish is to fight as a soldier
in the battle of ideas. I shall continue to write under the heading of
'Reflections by comrade Fidel.' It will be just another weapon you can
count on. Perhaps my voice will be heard. I shall be careful.
- Fidel Castro Ruz, 18feb2008
Steven D'Aprano
Jun 13, 2013, 9:23:24 PM6/13/13
to
On Thu, 13 Jun 2013 17:37:34 +0200, Tomasz Rola wrote:
> If he (son) learns Haskell, he may as well stay with it, because it's
> quite decent lang as far as I can tell. And it's compiled, too.
So is Python.
> If he (son) learns Haskell, he may as well stay with it, because it's
> quite decent lang as far as I can tell. And it's compiled, too.
> I would also consider Racket, which is a Scheme superset. It too, comes
> with compiler/JIT, plus IDE, plus libraries plus I understand examples
> from "Structure and Interpretation of Computer Programs", (
> http://mitpress.mit.edu/sicp/ ) can be run on it. I have heard some
> folks are doing real life stuff with it, too and IDE might help beginner
> a lot (this one is very nice, not just magnified editor).
chef by putting food in a microwave and pushing the pre-set buttons.
--
Steven
Ben Finney
Jun 13, 2013, 10:43:18 PM6/13/13
to pytho...@python.org
Steven D'Aprano <steve+comp....@pearwood.info> writes:
> I consider IDEs to be an attractive nuisance. It's like learning to be a
> chef by putting food in a microwave and pushing the pre-set buttons.
+1 QotW
> I consider IDEs to be an attractive nuisance. It's like learning to be a
> chef by putting food in a microwave and pushing the pre-set buttons.
--
\ “With Lisp or Forth, a master programmer has unlimited power |
`\ and expressiveness. With Python, even a regular guy can reach |
_o__) for the stars.” —Raymond Hettinger |
Ben Finney
Ethan Furman
Jun 13, 2013, 9:44:54 PM6/13/13
to pytho...@python.org
On 06/13/2013 06:23 PM, Steven D'Aprano wrote:
>
> I consider IDEs to be an attractive nuisance. It's like learning to be a
> chef by putting food in a microwave and pushing the pre-set buttons.
+1 QOTW
>
> I consider IDEs to be an attractive nuisance. It's like learning to be a
> chef by putting food in a microwave and pushing the pre-set buttons.
rusi
Jun 13, 2013, 11:31:17 PM6/13/13
to
On Jun 14, 5:44 am, Steven D'Aprano <steve
[This is more of an example than a full answer]
Lets say I have a 'kid' -- son, niece, student, whatever -- and for
some reason, we, both me and 'kid', feel its important to master
regular expressions.
Now regular expressions are there everywhere -- vi, emacs, perl,
python, awk, egrep, lex, ragel ... -- and so *technically* they are
quite orthogonal to the programming language issue.
Let us also assume that as a programming language, I definitely prefer
python over perl, in particular, REs in perl and python are more or
less equipotent.
However once we go beyond the technical basics of REs to a cultural
question -- asking more intricate questions on a forum -- I expect the
following to happen.
If (s)he asks an RE question on a perl forum I expect answers that are
cute, one-liner, zany etc but in a SE sense promote bad programming.
As a (cultural) rebound from that, when the same is asked on a python
forum, (s)he may get the hi-power RE answer. He is more more likely to
get a lecture on why REs are bad.
Now from a programming/SE angle, this is fine -- certainly writing an
ugly, buggy, inefficient RE where a few lines of beautiful soup (say)
would do better is poor practice. However lets remember that mastering
RE for its own sake is our agenda in addition to mastering
programming.
In short, I am not interested in perl for its own sake, yet the path
to RE-mastery in perl-culture is shorter.
So as guardian to my ward I have a simple evaluation to make:
"learn perl + python, learn REs in both, learn to translate REs across
the two"
is more or less work than
"Do everything in python"
Common sense suggests that the second is the less-work option.
Experience (may) suggest otherwise.
So much for my toy example. Now to more directly answer your question.
Here's Richard O'Keefe on the Erlang mailing list. Note particularly
the COBOL-Scheme reference.
-----------------------------------------
Once upon a time (about 1992ish) in a land where the moles
have beaks and swim and the deer jump on their hind legs
(Australia), a certain computer science department (RMIT)
decided that Pascal had reached its use-by date. What shall
we do? What shall we replace it with? Set up a committee!
I was on the committee. We set up a short list.
(1) Scheme.
Tiny language, amazingly capable, REPL so you can try
things out, implementations for all the machines we
cared about. And Rob Hagan at Monash had shown that
you could teach students more COBOL with one semester
of Scheme and one semester of COBOL than you could
with three semesters of COBOL.
(2) Miranda.
The commercial precursor of Haskell.
Melbourne University were also looking at this (or had
already switched to it) which would make it easier to
pick up some of their students.
(3) Ada.
Close enough to Pascal that our staff were comfortable with
it and our material would not need major revision.
A better Pascal than Pascal.
Handled concurrency about as nicely as an imperative language
can.
Personal Note:
For years Ive taught programming using two languages, one FPL, one
imperative language.
FPL one of {Miranda, Gofer, Scheme, Haskell}
Imp. Lang one of {Pascal, C, Python}
If I had to do it again (and had the choice!) I would evaluate the
sets again. I would not go from 2 to 1.
------------------------------
tl;dr:
The shortest route to mastery of programming in some chosen language,
say python, may be to learn a bunch of contrasting, competing
languages. Which others and how much, needs care and experience to
decide.
Lets say I have a 'kid' -- son, niece, student, whatever -- and for
some reason, we, both me and 'kid', feel its important to master
regular expressions.
Now regular expressions are there everywhere -- vi, emacs, perl,
python, awk, egrep, lex, ragel ... -- and so *technically* they are
quite orthogonal to the programming language issue.
Let us also assume that as a programming language, I definitely prefer
python over perl, in particular, REs in perl and python are more or
less equipotent.
However once we go beyond the technical basics of REs to a cultural
question -- asking more intricate questions on a forum -- I expect the
following to happen.
If (s)he asks an RE question on a perl forum I expect answers that are
cute, one-liner, zany etc but in a SE sense promote bad programming.
As a (cultural) rebound from that, when the same is asked on a python
forum, (s)he may get the hi-power RE answer. He is more more likely to
get a lecture on why REs are bad.
Now from a programming/SE angle, this is fine -- certainly writing an
ugly, buggy, inefficient RE where a few lines of beautiful soup (say)
would do better is poor practice. However lets remember that mastering
RE for its own sake is our agenda in addition to mastering
programming.
In short, I am not interested in perl for its own sake, yet the path
to RE-mastery in perl-culture is shorter.
So as guardian to my ward I have a simple evaluation to make:
"learn perl + python, learn REs in both, learn to translate REs across
the two"
is more or less work than
"Do everything in python"
Common sense suggests that the second is the less-work option.
Experience (may) suggest otherwise.
So much for my toy example. Now to more directly answer your question.
Here's Richard O'Keefe on the Erlang mailing list. Note particularly
the COBOL-Scheme reference.
-----------------------------------------
Once upon a time (about 1992ish) in a land where the moles
have beaks and swim and the deer jump on their hind legs
(Australia), a certain computer science department (RMIT)
decided that Pascal had reached its use-by date. What shall
we do? What shall we replace it with? Set up a committee!
I was on the committee. We set up a short list.
(1) Scheme.
Tiny language, amazingly capable, REPL so you can try
things out, implementations for all the machines we
cared about. And Rob Hagan at Monash had shown that
you could teach students more COBOL with one semester
of Scheme and one semester of COBOL than you could
with three semesters of COBOL.
(2) Miranda.
The commercial precursor of Haskell.
Melbourne University were also looking at this (or had
already switched to it) which would make it easier to
pick up some of their students.
(3) Ada.
Close enough to Pascal that our staff were comfortable with
it and our material would not need major revision.
A better Pascal than Pascal.
Handled concurrency about as nicely as an imperative language
can.
Personal Note:
For years Ive taught programming using two languages, one FPL, one
imperative language.
FPL one of {Miranda, Gofer, Scheme, Haskell}
Imp. Lang one of {Pascal, C, Python}
If I had to do it again (and had the choice!) I would evaluate the
sets again. I would not go from 2 to 1.
------------------------------
tl;dr:
The shortest route to mastery of programming in some chosen language,
say python, may be to learn a bunch of contrasting, competing
languages. Which others and how much, needs care and experience to
decide.
Rick Johnson
Jun 13, 2013, 11:33:40 PM6/13/13
to
On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
> [...]
faster? Or is this merely just your "opinion"? I would be
ready and willing to compete in a "Pepsi challenge" to
disprove your claim if needed. For instance, if i want to
open a text file on my machine, i merely navigate to the
file via my file browser interface, using clicks along the
way, and then the final double click will open the text file
using it's default program. Are you telling me you can type
the address faster (much less remember the full path) than i
can point and click? And if you think you're going to cheat
by creating an "environment variable", well i can still win
by doing the same thing with a "shortcut".
> Also - Python is pretty much the only language that
> *isn't* overkill; once you take more than the first few
> steps a language that's *consistent* will help more with
> learning, a mon avis, than these "quicker" languages ever
neophyte. I'm sorry to burst your bubble whilst also raining
on your parade, but Python is NOT consistent. And the more i
learn about Python the more i realize just how inconsistent
the language is. Guido has the correct "base idea", however
he allowed the evolution to become a train wreck.
> [...]
the room. You can "prefer" console over GUI all day long but
that does not negate the fact that GUI's outperform the
console for many tasks. With the exception of text based
games, the console is as useful for game programming as a
cheese grater is for masturbation -- slightly amusing, but
mostly just painful!
> [...]
> GUI is boring. I don't give a damn about that. If I had it
> my way, I'd never write any interfaces again (although
> designing them is fine). Console interaction is faster to
> do and it lets me do the stuff I *want* to do quicker.
And are you willing to provide *proof* that the console is
> my way, I'd never write any interfaces again (although
> designing them is fine). Console interaction is faster to
> do and it lets me do the stuff I *want* to do quicker.
faster? Or is this merely just your "opinion"? I would be
ready and willing to compete in a "Pepsi challenge" to
disprove your claim if needed. For instance, if i want to
open a text file on my machine, i merely navigate to the
file via my file browser interface, using clicks along the
way, and then the final double click will open the text file
using it's default program. Are you telling me you can type
the address faster (much less remember the full path) than i
can point and click? And if you think you're going to cheat
by creating an "environment variable", well i can still win
by doing the same thing with a "shortcut".
> Also - Python is pretty much the only language that
> *isn't* overkill; once you take more than the first few
> steps a language that's *consistent* will help more with
> will. Python is consistent and simple.
Your statement is an oft cited misconception of the Python
neophyte. I'm sorry to burst your bubble whilst also raining
on your parade, but Python is NOT consistent. And the more i
learn about Python the more i realize just how inconsistent
the language is. Guido has the correct "base idea", however
he allowed the evolution to become a train wreck.
> [...]
> Basically, "kid" is a *very* generic term and there are
> people who like GUIs and there are people who like
> internals
Your statement is true however it ignores the elephant in
> people who like GUIs and there are people who like
> internals
the room. You can "prefer" console over GUI all day long but
that does not negate the fact that GUI's outperform the
console for many tasks. With the exception of text based
games, the console is as useful for game programming as a
cheese grater is for masturbation -- slightly amusing, but
mostly just painful!
Chris Angelico
Jun 14, 2013, 12:05:00 AM6/14/13
to pytho...@python.org
On Fri, Jun 14, 2013 at 1:33 PM, Rick Johnson
<rantingri...@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed. For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program.
Also - Show me an efficient way, with a GUI, to invoke any file with
<rantingri...@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed. For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program.
any program with any parameters, without cheating and using something
like Alt-F2 to enter a command line. Your solution must be utterly
generic. I need to be able to tail -F and tail -f a file.
ChrisA
Chris Angelico
Jun 14, 2013, 12:02:49 AM6/14/13
to pytho...@python.org
> For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click?
I have tab completion. Beat that, GUI.
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click?
ChrisA
Joshua Landau
Jun 14, 2013, 1:11:58 AM6/14/13
to Rick Johnson, python-list
I don't normally respond to trolls, but I'll make an exception here.
On 14 June 2013 04:33, Rick Johnson <rantingri...@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed. For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click? And if you think you're going to cheat
> by creating an "environment variable", well i can still win
> by doing the same thing with a "shortcut".
1) I said it's faster to implement, not faster to use.
2) Yes, I would win that test. Say I want to go to
"Projects/Programming Tidbits/FeedLess", I'd write "j Fee". Done. I'm
there. What was hard about that?
3) Gee, you think a graphical file manager is good? You should try
Ranger. Seriously, it's way better. (Seriously)
>> Also - Python is pretty much the only language that
>> *isn't* overkill; once you take more than the first few
>> steps a language that's *consistent* will help more with
>> learning, a mon avis, than these "quicker" languages ever
>> will. Python is consistent and simple.
>
> Your statement is an oft cited misconception of the Python
> neophyte. I'm sorry to burst your bubble whilst also raining
> on your parade, but Python is NOT consistent. And the more i
> learn about Python the more i realize just how inconsistent
> the language is. Guido has the correct "base idea", however
> he allowed the evolution to become a train wreck.
If you ignore stdlib, for a moment, lol.
If you include stdlib you're just wrong, but not humorously so.
>> [...]
>> Basically, "kid" is a *very* generic term and there are
>> people who like GUIs and there are people who like
>> internals
>
> Your statement is true however it ignores the elephant in
> the room. You can "prefer" console over GUI all day long but
> that does not negate the fact that GUI's outperform the
> console for many tasks. With the exception of text based
> games, the console is as useful for game programming as a
> cheese grater is for masturbation -- slightly amusing, but
> mostly just painful!
I'd like to see you write or do the equivalent of:
when-changed $FILE.coffee "coffee -c $FILE.coffee; xclip -selection
clipboard < $FILE.js; echo Update"
in a GUI. Really, I would.
Oh, and then make your result searchable with to all of your other
little one-liners, in a process that takes ½ a second to complete.
Nevermind that I was talking about console programs being quicker to
make this whole time, rather than quicker to use.
On 14 June 2013 04:33, Rick Johnson <rantingri...@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed. For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click? And if you think you're going to cheat
> by creating an "environment variable", well i can still win
> by doing the same thing with a "shortcut".
2) Yes, I would win that test. Say I want to go to
"Projects/Programming Tidbits/FeedLess", I'd write "j Fee". Done. I'm
there. What was hard about that?
3) Gee, you think a graphical file manager is good? You should try
Ranger. Seriously, it's way better. (Seriously)
>> Also - Python is pretty much the only language that
>> *isn't* overkill; once you take more than the first few
>> steps a language that's *consistent* will help more with
>> learning, a mon avis, than these "quicker" languages ever
>> will. Python is consistent and simple.
>
> Your statement is an oft cited misconception of the Python
> neophyte. I'm sorry to burst your bubble whilst also raining
> on your parade, but Python is NOT consistent. And the more i
> learn about Python the more i realize just how inconsistent
> the language is. Guido has the correct "base idea", however
> he allowed the evolution to become a train wreck.
If you include stdlib you're just wrong, but not humorously so.
>> [...]
>> Basically, "kid" is a *very* generic term and there are
>> people who like GUIs and there are people who like
>> internals
>
> Your statement is true however it ignores the elephant in
> the room. You can "prefer" console over GUI all day long but
> that does not negate the fact that GUI's outperform the
> console for many tasks. With the exception of text based
> games, the console is as useful for game programming as a
> cheese grater is for masturbation -- slightly amusing, but
> mostly just painful!
when-changed $FILE.coffee "coffee -c $FILE.coffee; xclip -selection
clipboard < $FILE.js; echo Update"
in a GUI. Really, I would.
Oh, and then make your result searchable with to all of your other
little one-liners, in a process that takes ½ a second to complete.
Nevermind that I was talking about console programs being quicker to
make this whole time, rather than quicker to use.
Steven D'Aprano
Jun 14, 2013, 2:13:47 AM6/14/13
to
On Thu, 13 Jun 2013 20:33:40 -0700, Rick Johnson wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>> never write any interfaces again (although designing them is fine).
>> Console interaction is faster to do and it lets me do the stuff I
>> *want* to do quicker.
>
> And are you willing to provide *proof* that the console is faster? Or is
> this merely just your "opinion"? I would be ready and willing to compete
> in a "Pepsi challenge" to disprove your claim if needed. For instance,
> if i want to open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the way, and then
> the final double click will open the text file using it's default
> program. Are you telling me you can type the address faster (much less
> remember the full path) than i can point and click?
If you can remember the full path in order to point and click, then I'm
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>> never write any interfaces again (although designing them is fine).
>> Console interaction is faster to do and it lets me do the stuff I
>> *want* to do quicker.
>
> And are you willing to provide *proof* that the console is faster? Or is
> this merely just your "opinion"? I would be ready and willing to compete
> in a "Pepsi challenge" to disprove your claim if needed. For instance,
> if i want to open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the way, and then
> the final double click will open the text file using it's default
> program. Are you telling me you can type the address faster (much less
> remember the full path) than i can point and click?
sure Joshua can remember the full path in order to type.
And as far as speed goes, well, that depends. If you have three files in
a directory, which in turn is next two three other subdirectories:
C:
+-- My Documents
+-- My Pictures
+-- My Videos
+-- amazing movie.avi
+-- amazing movie.mp4
+-- amazing movie - the sequel.avi
then, yes, I'm sure you pointing-and-clicking will beat the command line
to open "amazing movie - the sequal.avi". Trivial tasks like that play to
the strengths of GUI interfaces.
But, here's a slightly more challenging one: you have to navigate down
through ten directories, not one. Each directory you navigate through has
a dozen different subdirectories in it. When you finally reach the bottom-
most directory, where your target video file is, there are two thousand
other videos in the directory. (Some people's only filing system is "dump
everything in one place".) None of the video thumbnails are cached, and
your GUI will helpfully start loading thumbnails as you open the window
and scroll around. Your "Pepsi Challenge", should you choose to accept
it, it to find the target file, make a copy of the file in the same
directory, rename the original, and then open it in an application but
*not* the default application.
Are you still confident that point-and-click will win this race? I'm
not... I reckon this would be neck and neck, up to the point where your
GUI starts loading thumbnails, then the command line will leave you in
the dust. Even a weak, underpowered command line like command.com (or is
it cmd.exe? I always forget which is which).
On the other hand... if we don't know the name of the video, and have to
recognise it by sight, then a GUI has the advantage.
Here's another Pepsi Challenge for you:
There is a certain directory on your system containing 50 text files, and
50 non-text files. You know the location of the directory. You want to
locate all the text files in this directory containing the word
"halibut", then replace the word "halibut" with "trout", but only if the
file name begins with a vowel.
Still confident that you can do this faster with a GUI than a command
line interface? I reckon that a full-powered CLI like those available on
Linux will just about have finished the entire job before you've even
finished entering information into the GUI search dialog.
But in any case, there are certainly strengths and weaknesses of both
GUIs and text interfaces, and one should design programs around whichever
is best for the needs of the program and the user.
--
Steven
Jason Swails
Jun 14, 2013, 2:28:29 AM6/14/13
to Rick Johnson, python list
On Thu, Jun 13, 2013 at 11:33 PM, Rick Johnson <rantingri...@gmail.com> wrote:
On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
> [...]
> GUI is boring. I don't give a damn about that. If I had itAnd are you willing to provide *proof* that the console is
> my way, I'd never write any interfaces again (although
> designing them is fine). Console interaction is faster to
> do and it lets me do the stuff I *want* to do quicker.
faster? Or is this merely just your "opinion"? I would be
ready and willing to compete in a "Pepsi challenge" to
disprove your claim if needed. For instance, if i want to
open a text file on my machine, i merely navigate to the
file via my file browser interface, using clicks along the
way, and then the final double click will open the text file
using it's default program. Are you telling me you can type
the address faster (much less remember the full path) than i
can point and click? And if you think you're going to cheat
by creating an "environment variable", well i can still win
by doing the same thing with a "shortcut".
One of my favorite parts about the Mac over windows, actually, is that I can open up a console. Coupled with MacPorts or some other equivalent package manager, I have what amounts to a working Linux environment (almost). The "open" command is particularly useful (equivalent to double-clicking, with the ability to specify "-a <program name>" to invoke a right-click->select program->[scan through program list]->click much more easily.
Coupled with tab completion (as Chris mentioned), and a full history of visited directories, I can navigate my file system in a console much faster than I can navigate in the GUI. It matters little to my productivity how fast you can navigate a GUI.
But batch processing is, in general, much easier to do in the console in my experience. Two tasks I've wanted to do that were of general interest to computer users (not specifically my work) that I wouldn't have bothered in a GUI environment:
1) Autocrop a whole bunch of images (~100) to remove extraneous white space around all of the edges. In the console with imagemagick:
bash$ for image in *.png; do convert $image -trim tmp.png; mv tmp.png $image; done
2) Compress my library of 2000 jpegs, since I didn't need high-quality jpegs AND raw images from my camera on my disk consuming space:
bash$ for image in `find . -name "*.jpg"`; do convert $image -quality 70 tmp.jpg; mv tmp.jpg $image; done
Using the console I was able to do both tasks in ~20 seconds quite easily.
Your statement is an oft cited misconception of the Python
> Also - Python is pretty much the only language that
> *isn't* overkill; once you take more than the first few
> steps a language that's *consistent* will help more with
> learning, a mon avis, than these "quicker" languages ever
> will. Python is consistent and simple.
neophyte. I'm sorry to burst your bubble whilst also raining
on your parade, but Python is NOT consistent. And the more i
learn about Python the more i realize just how inconsistent
the language is. Guido has the correct "base idea", however
he allowed the evolution to become a train wreck.
You're right. NameError's should not be listed with the full traceback -- the last entry on the call stack is obviously the right way to treat this special-case exception [1]. BTW, this comment amounts to Contradiction. [2]
It's sometimes difficult to reconcile several of your comments...
> [...]
> Basically, "kid" is a *very* generic term and there areYour statement is true however it ignores the elephant in
> people who like GUIs and there are people who like
> internals
the room. You can "prefer" console over GUI all day long but
that does not negate the fact that GUI's outperform the
console for many tasks. With the exception of text based
games, the console is as useful for game programming as
[something not useful]
Just because you click through a GUI faster does not mean that everyone else does, too.
And I've developed some Tkinter-based apps (that you can even download if you were so interested)---I did all the development on the command-line using vim and git.
All the best,
Jason
Chris Angelico
Jun 14, 2013, 3:21:52 AM6/14/13
to pytho...@python.org
On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> Here's another Pepsi Challenge for you:
>
> There is a certain directory on your system containing 50 text files, and
> 50 non-text files. You know the location of the directory. You want to
> locate all the text files in this directory containing the word
> "halibut", then replace the word "halibut" with "trout", but only if the
> file name begins with a vowel.
That sounds extremely contrived, to be honest. Try this one: Massage a
<steve+comp....@pearwood.info> wrote:
> Here's another Pepsi Challenge for you:
>
> There is a certain directory on your system containing 50 text files, and
> 50 non-text files. You know the location of the directory. You want to
> locate all the text files in this directory containing the word
> "halibut", then replace the word "halibut" with "trout", but only if the
> file name begins with a vowel.
set of MySQL dump files (text, pure SQL) so they can be imported into
PostgreSQL. I'll leave out my Wednesday's encoding headaches (MySQL
produced so-called "UTF-8" output that contained "don\222t" - boggle!)
and restrict this challenge to one thing:
CREATE TABLE blah
(
blah INT(11) blah blah
);
All through the CREATE TABLE statements, integer fields are followed
by (11), and smallint fields by something else - (9) I think? - and
you have no guarantee that they'll be exactly these numbers, but they
will immediately follow the word INT.
Okay. I can hear some of you screaming "Regular expression!!", and
others yelling "Search across files, any good editor can do that!!". I
happened to use sed for the job. Bear in mind, there are heaps of
other files in the directory, so do this only on *.sql.
Any point-and-click solution to this is likely to end up cheating and
calling on some system that uses text strings (eg regexps). I'd like
to see any solution that proves me wrong, if only out of morbid
curiosity. I'm 100% confident that it won't be faster than me with
sed, or a Perl fanatic with a good regex.
ChrisA
Tim Chase
Jun 14, 2013, 6:41:20 AM6/14/13
to Chris Angelico, pytho...@python.org
On 2013-06-14 17:21, Chris Angelico wrote:
> On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
> On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
> > Here's another Pepsi Challenge for you:
> >
> > There is a certain directory on your system containing 50 text
> > files, and 50 non-text files. You know the location of the
> > directory. You want to locate all the text files in this
> > directory containing the word "halibut", then replace the word
> > "halibut" with "trout", but only if the file name begins with a
> > vowel.
>
> >
> > There is a certain directory on your system containing 50 text
> > files, and 50 non-text files. You know the location of the
> > directory. You want to locate all the text files in this
> > directory containing the word "halibut", then replace the word
> > "halibut" with "trout", but only if the file name begins with a
> > vowel.
>
> That sounds extremely contrived, to be honest.
I've actually done similar, moving sets of media files while renaming
& transforming them (id3v2 to set mp3 tags or modify
filenames/target-directories; exif/convert for .jpg files) along the
way and selecting them, along with container files (select playlists
for MP3s). Sometimes the media files are named poorly, but better
filename information can be extracted from internal metadata, or can
be combined into things like photo-sets (rather than "DSC314159.JPG",
I can at least have "2013-04-01 Mom's birthday party 314159.jpg"
where the date comes from EXIF data, and a fixed string is replaced.
The idea of operating in batch on any data is pretty much always a
command-line win.
-tim
Anssi Saari
Jun 14, 2013, 8:02:16 AM6/14/13
to
Decent GUIs *have* tab completion. Bad GUIs don't.
Oh wait. Is a GUI with tab completion a GUI at all or more of a weird
ass hybrid? What about a CLI that pops up a menu for completions?
Oh wait. Is a GUI with tab completion a GUI at all or more of a weird
ass hybrid? What about a CLI that pops up a menu for completions?
Alister
Jun 14, 2013, 11:35:21 AM6/14/13
to
for Thunar, accept a list of photographs & copy then to a new directory
with options to use exif data as part of the new name
--
Christoph, please remember that irony is not available between the
Canadian
and Mexican border.... you are confusing them again 8)
- Alan Cox on linux-kernel
Neil Cerutti
Jun 14, 2013, 12:01:44 PM6/14/13
to
On 2013-06-14, Steven D'Aprano <steve+comp....@pearwood.info> wrote:
> On Thu, 13 Jun 2013 20:33:40 -0700, Rick Johnson wrote:
>
>> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>>
>>> [...]
>>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>>> never write any interfaces again (although designing them is fine).
>>> Console interaction is faster to do and it lets me do the stuff I
>>> *want* to do quicker.
>>
>> And are you willing to provide *proof* that the console is faster? Or is
>> this merely just your "opinion"? I would be ready and willing to compete
>> in a "Pepsi challenge" to disprove your claim if needed. For instance,
>> if i want to open a text file on my machine, i merely navigate to the
>> file via my file browser interface, using clicks along the way, and then
>> the final double click will open the text file using it's default
>> program. Are you telling me you can type the address faster (much less
>> remember the full path) than i can point and click?
>
> If you can remember the full path in order to point and click,
> then I'm sure Joshua can remember the full path in order to
> type.
My favorite current challenge for an IDE designer is
> On Thu, 13 Jun 2013 20:33:40 -0700, Rick Johnson wrote:
>
>> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>>
>>> [...]
>>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>>> never write any interfaces again (although designing them is fine).
>>> Console interaction is faster to do and it lets me do the stuff I
>>> *want* to do quicker.
>>
>> And are you willing to provide *proof* that the console is faster? Or is
>> this merely just your "opinion"? I would be ready and willing to compete
>> in a "Pepsi challenge" to disprove your claim if needed. For instance,
>> if i want to open a text file on my machine, i merely navigate to the
>> file via my file browser interface, using clicks along the way, and then
>> the final double click will open the text file using it's default
>> program. Are you telling me you can type the address faster (much less
>> remember the full path) than i can point and click?
>
> If you can remember the full path in order to point and click,
> then I'm sure Joshua can remember the full path in order to
> type.
concatenating text files. This is a one-liner, even with cmd.exe,
but I don't even know how to do it in Explorer. I'd have to use X
number of text editing sessions.
> But in any case, there are certainly strengths and weaknesses
> of both GUIs and text interfaces, and one should design
> programs around whichever is best for the needs of the program
> and the user.
built-in stengths and weaknesses. I was going to write something
about them earlier, but I got bogged down when I thought of the
issue of accessibilty, which overtakes any such discussion.
--
Neil Cerutti
Jason Swails
Jun 14, 2013, 1:03:12 PM6/14/13
to Chris Angelico, python list
On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> Here's another Pepsi Challenge for you:
>
> There is a certain directory on your system containing 50 text files, and
> 50 non-text files. You know the location of the directory. You want to
> locate all the text files in this directory containing the word
> "halibut", then replace the word "halibut" with "trout", but only if the
> file name begins with a vowel.
That sounds extremely contrived, to be honest.
I agree that it sounds contrived, but I've found analogous tasks to be quite common in the program suite I work on, actually.
We have a set of regression tests for obvious reasons. To give an order of magnitude estimate here, there are over 1100 saved test files that get compared when we run the test suite.
When a change is made to the information reporting (for instance, if we added a new input variable) or version number that is printed in the output files, we have ourselves ~2K files. We then have to scan through all 2K files (some of which are ASCII, others of which are binary), typically armed with a regex that identifies the formatting change we just implemented and change the saved test files (all file names that end in .save) to the 'new' format. Our task is to find only those files that end in .save and replace only those files that differ only by the trivial formatting change to avoid masking a bug in the test suite. [I'm actually doing this now]
On the whole, it sounds quite similar to Steven's example (only significantly more files), and is something not even RR could do in a GUI faster than I can run a script.
Chris Angelico
Jun 14, 2013, 1:12:01 PM6/14/13
to pytho...@python.org
way the file dialog (under Debian Wheezy + Xfce + SciTE; no idea who's
responsible, probably Xfce) will fill in directory components as I
type. But that's functioning almost exclusively as CLI style; I type
in parts of the path and it does things. To take advantage of tab
completion, I ignore the GUI-style of "point to the thing you want and
click". There's no real way for point-and-click to work with tab
completion.
ChrisA
Chris Angelico
Jun 14, 2013, 1:14:17 PM6/14/13
to pytho...@python.org
On Sat, Jun 15, 2013 at 2:01 AM, Neil Cerutti <ne...@norwich.edu> wrote:
> My favorite current challenge for an IDE designer is
> concatenating text files. This is a one-liner, even with cmd.exe,
> but I don't even know how to do it in Explorer. I'd have to use X
> number of text editing sessions.
Good point! Or, more generally:
> My favorite current challenge for an IDE designer is
> concatenating text files. This is a one-liner, even with cmd.exe,
> but I don't even know how to do it in Explorer. I'd have to use X
> number of text editing sessions.
HOW, with a standard point-and-squirt UI, do you invoke one specific
program with two specific data files? Sometimes you can drag two files
onto one program, but usually that involves two separate invocations
of the program, once for each. In theory you could have a concatenator
app, but how do you tell it when you're finished one concatenation and
want to start another? Time delay? Seems clunky and prone to doing the
wrong thing.
ChrisA
Message has been deleted
Message has been deleted
Rick Johnson
Jun 16, 2013, 3:04:07 PM6/16/13
to
On Thursday, June 13, 2013 11:05:00 PM UTC-5, Chris Angelico wrote:
Chris, a GUI interface can be created for *ANY* command line
functionality. By utilizing the GUI you can be more
productive because a "point" and a "click" are always faster
than "peck-peck-peck" * INFINITY.
For instance, if i want to start a certain program (or func)
on the commandline, first i will need to know what commands
are available. To see these commands i must *FIRST* type a
command. On the windows box that command would be "help".
Now hopefully the command list will fit within the console's
buffer capacity, or else i need to enter a page buffer mode
(SOMEBODY KILL ME NOW!!!).
This is where the GUI shines!
When i choose to open my "system tools gui" (instead of the
antiquated text only console), a list of commands will be
displayed in a nice list box with scroll-bars that have near
unlimited capacity to scroll. All i need to do is "point"
and "click" and this "magical" piece of software runs
another GUI program for that specific task or tool.
> Also - Show me an efficient way, with a GUI, to invoke any
> file with any program with any parameters, without
> cheating and using something like Alt-F2 to enter a
> command line. Your solution must be utterly generic. I
> need to be able to tail -F and tail -f a file.
Just because you lack the graphical tools on your machine,
or the skill to create those graphical tools on your
machine, does not mean the rest of us are as incapable.
Note: The following solution requires you to have a windows
OS, if you are using anything else, then you should be geeky
enough to roll your own solution!
## BEGIN SCRIPT ##
# Python Version < 3.0 only!
import sys, os
import Tkinter as tk
import tkSimpleDialog, tkMessageBox
msg1 = 'Greetings master, by what method shall i execute "{0}"?'
msg2 = """\
And the master sayeth:
"{0}"
So it is written, so shall it be done"""
ivalue = "some/path/to/nowhere.txt -opt1=foo -opt2=bar"
def prompt_master():
argv = sys.argv
path = argv[1]
fname = os.path.basename(path)
msg = msg1.format(fname)
argstr = tkSimpleDialog.askstring('',
msg,
initialvalue=ivalue,
parent=root
)
if argstr:
tkMessageBox.showinfo('', msg2.format(argstr),parent=root)
os.system('{0} {1}'.format(path, argstr))
root.destroy()
if __name__ == '__main__':
root = tk.Tk()
root.withdraw()
prompt_master()
root.mainloop()
## END SCRIPT ##
Save that code in a file named "PepsiChallenge.py", then
throw that script in your "Send To" folder and it
"magically" becomes accessible from the "SendTo" command of
the windows context menu. If you don't know where to find
your windows "send to" folder then ask my good friend
Google.
To use, simply open your windows file browser, navigate to a
file icon, right click the file, and send it to the
PepsiChallenge script.
By doing this we've harnessed the power of an existing GUI
without actually writing all the GUI code. But more
importantly we've won the challenge :-P"
*school-bell*
Chris, a GUI interface can be created for *ANY* command line
functionality. By utilizing the GUI you can be more
productive because a "point" and a "click" are always faster
than "peck-peck-peck" * INFINITY.
For instance, if i want to start a certain program (or func)
on the commandline, first i will need to know what commands
are available. To see these commands i must *FIRST* type a
command. On the windows box that command would be "help".
Now hopefully the command list will fit within the console's
buffer capacity, or else i need to enter a page buffer mode
(SOMEBODY KILL ME NOW!!!).
This is where the GUI shines!
When i choose to open my "system tools gui" (instead of the
antiquated text only console), a list of commands will be
displayed in a nice list box with scroll-bars that have near
unlimited capacity to scroll. All i need to do is "point"
and "click" and this "magical" piece of software runs
another GUI program for that specific task or tool.
> Also - Show me an efficient way, with a GUI, to invoke any
> file with any program with any parameters, without
> cheating and using something like Alt-F2 to enter a
> command line. Your solution must be utterly generic. I
> need to be able to tail -F and tail -f a file.
or the skill to create those graphical tools on your
machine, does not mean the rest of us are as incapable.
Note: The following solution requires you to have a windows
OS, if you are using anything else, then you should be geeky
enough to roll your own solution!
## BEGIN SCRIPT ##
# Python Version < 3.0 only!
import sys, os
import Tkinter as tk
import tkSimpleDialog, tkMessageBox
msg1 = 'Greetings master, by what method shall i execute "{0}"?'
msg2 = """\
And the master sayeth:
"{0}"
So it is written, so shall it be done"""
ivalue = "some/path/to/nowhere.txt -opt1=foo -opt2=bar"
def prompt_master():
argv = sys.argv
path = argv[1]
fname = os.path.basename(path)
msg = msg1.format(fname)
argstr = tkSimpleDialog.askstring('',
msg,
initialvalue=ivalue,
parent=root
)
if argstr:
tkMessageBox.showinfo('', msg2.format(argstr),parent=root)
os.system('{0} {1}'.format(path, argstr))
root.destroy()
if __name__ == '__main__':
root = tk.Tk()
root.withdraw()
prompt_master()
root.mainloop()
## END SCRIPT ##
Save that code in a file named "PepsiChallenge.py", then
throw that script in your "Send To" folder and it
"magically" becomes accessible from the "SendTo" command of
the windows context menu. If you don't know where to find
your windows "send to" folder then ask my good friend
Google.
To use, simply open your windows file browser, navigate to a
file icon, right click the file, and send it to the
PepsiChallenge script.
By doing this we've harnessed the power of an existing GUI
without actually writing all the GUI code. But more
importantly we've won the challenge :-P"
*school-bell*
Chris Angelico
Jun 16, 2013, 5:52:16 PM6/16/13
to pytho...@python.org
On Mon, Jun 17, 2013 at 5:04 AM, Rick Johnson
<rantingri...@gmail.com> wrote:
> Chris, a GUI interface can be created for *ANY* command line
> functionality. By utilizing the GUI you can be more
> productive because a "point" and a "click" are always faster
> than "peck-peck-peck" * INFINITY.
>
Okay... I'm trying to get my head around what you've done here. Isn't
<rantingri...@gmail.com> wrote:
> Chris, a GUI interface can be created for *ANY* command line
> functionality. By utilizing the GUI you can be more
> productive because a "point" and a "click" are always faster
> than "peck-peck-peck" * INFINITY.
>
it simply that you've made a way to, with what looks like a
point-and-click interface, let the user type in a command line? Or
even worse, force them to edit a file to change the command used? That
already exists - as I mentioned, several desktop environments have
Alt-F2 to let you type in any program and run it. That's no more using
a GUI than bringing up a terminal is.
ChrisA
Rick Johnson
Jun 16, 2013, 6:33:29 PM6/16/13
to
On Sunday, June 16, 2013 4:52:16 PM UTC-5, Chris Angelico wrote:
> Okay... I'm trying to get my head around what you've done
> here. Isn't it simply that you've made a way to, with what
> looks like a point-and-click interface, let the user type
> in a command line?
> [...]
> Okay... I'm trying to get my head around what you've done
> here. Isn't it simply that you've made a way to, with what
> looks like a point-and-click interface, let the user type
> in a command line?
> That's no more using a GUI than bringing up a terminal is.
Yes, a Graphical Interface will need the occasional "peck-peck" input from the user, the only difference from a text based interface is the INFINITY multiplier. The Graphical Interface prefers the point and click, but NOT exclusively! The Graphical Interface allows you apply the most efficient method by which to solve a problem -- again, that might be "peck-peck" or "point-click", OR, a combination of both. Depends on the situation really.
Alister
Jun 17, 2013, 5:11:22 PM6/17/13
to
been " use the correct tool for the job"
I believe that most programmers would probably follow the aproch of :-
1) write the code to perform the task
2) write a wrapper to present the user with a suitable interface
stage 2 could be either a GUI or a CLUE (Command Line User Interface :-)
) or possibly even both depending on the application.
--
An age is called Dark not because the light fails to shine, but because
people refuse to see it.
-- James Michener, "Space"
alien...@gmail.com
Jul 27, 2013, 8:25:38 AM7/27/13
to
Hi,
I am an IT and Learning Research professor. I wrote a set of lessons that became a beginning programming book for my two sons. They loved it because is it was simple, hands on, and funny. It covers the basics of programming, introducing; software design, planning a game, making/getting free assets, version systems, and packaging. This course takes the beginner from ground zero to making arcade style games complete with sound, music, graphics, and an installation package in 21 lessons. It also includes vast resources in the index. It is called; "Start Here: Python 3x Programming Made Fun and Easier," and can be found at http://www.quantumsight.mobi or http://www.toonzcat.com/book.html This site also introduces graphics for web sites, animation, and games.
J.S.G, PhD
I am an IT and Learning Research professor. I wrote a set of lessons that became a beginning programming book for my two sons. They loved it because is it was simple, hands on, and funny. It covers the basics of programming, introducing; software design, planning a game, making/getting free assets, version systems, and packaging. This course takes the beginner from ground zero to making arcade style games complete with sound, music, graphics, and an installation package in 21 lessons. It also includes vast resources in the index. It is called; "Start Here: Python 3x Programming Made Fun and Easier," and can be found at http://www.quantumsight.mobi or http://www.toonzcat.com/book.html This site also introduces graphics for web sites, animation, and games.
J.S.G, PhD
0 new messages