Multiple people have asked me about Python and my review of Learning Python. To answer their questions and those from people who didn't write, I drafted this response.
First, about the book. It is clearly put together by someone who has been teaching Python to people. I would say the audience has been experienced programmers, which at least for me, is good.
Now, why Python? Is it the “language of the future”? I think so. It makes a lot of sense in a lot of areas. Let me try to address them.
Ease of learning: Python is a small language. That is, the syntax is simple and the number of commands is fairly low.
Powerful: the power in Python (much like C) comes from its library. While the language and its syntax aren't complicated, calling the right function to do a task is what makes it powerful. There are a lot of functions available, but you can acquire knowledge of them as they are needed. For example, if you want to do CGI programming, the functions available are powerful and grouped so you can find them.
Being interpreted, you can quickly try things.
Python is extensible: if you have something you need to add or something that must execute quickly, you can easily add code to do it. Using C for things that need to be fast makes sense.
Python won't teach you any bad habits. There are virtually no “gotchas” in the syntax, and I have yet to find a case where you need to write a cute workaround to deal with a language limitation.
Python is object-oriented, but in a nice way. I have dabbled with C++ but have never actually done object-oriented programming. Python encourages modular and object-oriented programming, but doesn't require it. Thus, you can write a quick-and-dirty solution to a one-time problem, but you can also write solutions to big problems in an easy-to-read, easy-to-debut, easy-to-maintain way. I contrast this with Perl, where you are encouraged to use the quick-and-dirty solution and must go out of your way to create an object-oriented solution.
Perl is a logical outgrowth of an assortment of UNIX tools including tr, sed and awk, as well as shell scripting. While Perl seems familiar to anyone who has used these tools, it makes no sense for someone not familiar with these tools to consider Perl. You can't even define the syntax of Perl, because it doesn't really have any. Python, on the other hand, is well-designed from a formal language sense as well as a programming sense.
I hope this helps explain where Python fits or could fit in your life.
—Phil Hughes email@example.com
I have been reading your interview with Linus whilst waiting for our Internet connection to the outside world to be restored—very, very fun read. I have no idea whether the world of Linuxers is interested in this kind of “human interest” stuff or not, but I know that it's great to hear this regular person talk about himself, how he grew up, his ordinary life, etc. and not just the usual Linux advocacy stuff, which Linus seems to avoid, thankfully. This may be because he's less awed by it than everyone else, since he put it together—wonderful modesty on his part. Truly enjoyable journalism on yours.
—David Penn firstname.lastname@example.org
Thanks very much for the great short article, “Stupid Programming Tricks” by Jason Kroll in October's Linux Journal. It introduced me to the world of SVGAlib. I enjoyed his shapes.c program and even had fun changing it on my own.
For the last month, I've been muddling through trying other stuff, but had been eagerly awaiting the more impressive-looking stuff you alluded to in last month's article. Alas, as I'm drooling through my hot-off-the-presses edition of this month's LJ, I can't find any mention of console graphics.
Do you plan on continuing the article in the future?
—Patrick A. Kirchner email@example.com
Tricks was inadvertently dropped from layout in the November issue. It resumed in December and will continue to be a regular feature in upFRONT —Editor
Upon reading the interview with Linus in the November 1999 issue, we've noticed that Microsoft has produced a new class of computational analysis problems.
NP Completeness: all non-deterministic polynomial problems are equivalent, we know we can solve them all, but not how long it will take.
NT Completeness: all Windows NT boxes are essentially alike, we know they will all crash eventually; the question is, how soon and what data will they take with them when they go?
Thanks for a world-class magazine about a world-class phenomenon.
—Phil Salkie, firstname.lastname@example.org Jennifer Hamilton, email@example.com
Ahhh, typos can sometimes be fun. Sorry for the error but not for the laugh. Thanks for writing —Editor
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
- Preparing Data for Machine Learning
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Be Kind, Buffer!
- Understanding Firewalld in Multi-Zone Configurations
- Simple Server Hardening
- Bash Shell Script: Building a Better March Madness Bracket
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)