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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide