PyCon DC 2003
Paul Graham gave the keynote address on the programming language he envisions we'll be using in a hundred years. He says speculating this is not far-fetched, because programming already has existed for almost fifty years and has changed remarkably little. In a hundred years we'll still be writing programs in text files of some sort, and there will still be something called Fortran.
Graham says the languages that will survive the evolutionary change are those with the fewest number of axioms (primitives), because they are the most flexible. As hardware becomes ever more powerful, "inefficient" but flexible programming practices become feasible, and the languages that do this are thriving because they make work easier for programmers. For instance, Python's flexible data types are more flexible than C's or Java's strong types. Graham calls his search for flexibility a search for creative ways to "waste" CPU cycles in the future.
Graham recommends an even higher-level abstraction for data types. For instance, there's no need for a separate string primitive because a string can be represented as a character array (list). So let strings be dealt with through library routines rather than being built into the language. Arrays aren't necessary because they are simply a special case of mappings (dictionaries). His most radical suggestion is the elimination of numeric types, because a number N can be represented by an array of length N. There even are proofs that mathematical operations, such as adding and multiplying, can be performed on arrays as easily as on special numeric types--even negative and fractional numbers, I'm told. Don't worry about this type surgery infecting Python: Guido wasn't buying it. And Graham says Python already is closer to his ideal than most languages are.
Graham concluded by saying it's great that programming languages are being written now by programmers rather than by professors, because programmers have practical needs that professors tend to ignore. Somebody also asked what the killer application will be in a hundred years. The answer: games with skins, of course.
Every Python conference offers one talk that has the biggest effect on me. At Python9 it was the Webware talk; at Python10 it was Tim Berners-Lee's talk on web-izing Python and RDF. Here at PyCon it was the Twisted tutorial. Twisted's developers were out in force, both at the sprint and with an entire track of refereed papers. Previously I had seen the Twisted web site and thought, "confusing, too big a learning curve, nothing I need", but hearing it explained in person really helped. Twisted is a modular platform for building internet applications, essentially an OO level that integrates Python's networking libraries and combines them with common internet services. It uses a single-threaded, non-blocking form of I/O, which they claim is significantly faster than multithreaded or multiprocess paradigms. Twisted has a few basic classes:
The network event loop
TCP, SSL, UNIX domain sockets, etc.
An interchange format for data (HTTP, SSH, DNS, etc.)
Creates a protocol-transport instance for a new client connection
Generates data at the rate a Consumer needs it
Your program-specific logic; aka "business logic"
Encapsulates all of the above
The dæmon that runs your application
One of Twisted's main features is the separation of transport from protocol. That makes changing a program's transport a simple two-line process, including one line for the import. It's useful for debugging programs from an alternate I/O source or for adapting to unforeseen circumstances.
As for the kinds of applications Twisted supports, somebody once said, "All applications eventually evolve to the point that you can read e-mail from them." Twisted can do that, as well as provide an SSH interface, a DNS server, a MUD game server and whatever else your application might want. The libraries are only an import statement away.
Why does Twisted have an SSH server? Why do people climb mountains? Because they're there; because they can. And it turns out that Twisted's SSH is faster than OpenSSH, because the latter forks twice for each connection. Why use Twisted's DNS rather than BIND? It's much smaller and simpler, so it's less prone to security alerts. Why use Twisted Web rather than Apache? The configuration file is much easier, employing ordinary Python method calls rather than a special configuration syntax.
For GUI programming, alternate reactors play well with various GUI event loops (GTK, Qt and so on). There are also libraries for accessing DBI-compliant databases (MySQL, etc); they are necessary because Twisted is single-threaded. So, if you use the standard database libraries, they will do blocking I/O and freeze all the other connections. There is also a library for running your business logic in a separate thread, in case you have to do blocking I/O for any other reason.
Twisted Web has a simple transaction model. A URL such as /foo/bar is translated to:
site.getChild('foo', request).getChild('bar', request).render()
foo and bar are twisted.resource.Resource objects. You define .getChild() and .render().
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- BitTorrent Inc.'s Sync
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- New Container Image Standard Promises More Portable Apps
- The Humble Hacker?
- The Death of RoboVM
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The US Government and Open-Source Software
- Open-Source Project Secretly Funded by CIA
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide