When I start to watch a video on the web, and the icon for Video DownloadHelper doesn't get colorful, I generally don't watch the video. I do this even if I have no desire to actually save that particular video.
If a video cannot be saved, then whoever made it, and whoever is in it, cannot be held accountable for its contents. If there is any controversy, then the video can simply disappear from the web. Non-savable videos are a form of history that can be revised at any time.
Not letting me save a video tells me that you may want to kill it. If you don't think that it's good enough to become a permanent part of our social consciousness, then I will assume that it's not good enough for me to spend my time watching.
Tuesday, December 1, 2009
Friday, July 24, 2009
Microsoft code release forced by GPL?
Wednesday, July 22, 2009
The Microsoft code releases don't matter
I understand people being excited that Microsoft has used the GPL, but from a historical perspective, their behavior in these two cases are consistent with decades of previous behavior on the part of Microsoft.
Microsoft has pretty much always been willing to have their systems interact with systems from other vendors, as long as the Microsoft technology is in the dominant position.
For example, Active Directory is happy to provide LDAP services for address book or authentication functionality to other systems, but won't authenticate against another vendor's LDAP server.
Active Directory is also happy to provide Kerberos services to non-Windows systems, but getting Microsoft systems to work with someone else's Kerberos servers is much more difficult.
The Unix Services for Windows are the same game. They make it easier for you to use Unix servers in a Windows infrastructure, but they aren't nearly as useful if you want to use a Windows server in a Unix infrastructure.
This week's code releases, one making Linux work better under the Microsoft hypervisor, and the other making Moodle work with Live@edu, merely continue this trend. In the first case, they are helping Linux to work better in a Microsoft infrastructure, and in the second, they are helping Moodle to work better in a Microsoft infrastructure. Neither of these code releases help any Microsoft product work better in a non-Microsoft infrastructure.
What would be significant is if Microsoft changed their behavior and offered more support for running Microsoft products in a non-Microsoft environment. For example, code contributions to xen or kvm that improved the execution of Windows guests.
But that's not what happened. Microsoft released code that makes it easier for you to run a heterogeneous environment so long as it's being controlled by Microsoft technology. They still very much want to be in control of you and your infrastructure. These code releases are non-events.
Microsoft has pretty much always been willing to have their systems interact with systems from other vendors, as long as the Microsoft technology is in the dominant position.
For example, Active Directory is happy to provide LDAP services for address book or authentication functionality to other systems, but won't authenticate against another vendor's LDAP server.
Active Directory is also happy to provide Kerberos services to non-Windows systems, but getting Microsoft systems to work with someone else's Kerberos servers is much more difficult.
The Unix Services for Windows are the same game. They make it easier for you to use Unix servers in a Windows infrastructure, but they aren't nearly as useful if you want to use a Windows server in a Unix infrastructure.
This week's code releases, one making Linux work better under the Microsoft hypervisor, and the other making Moodle work with Live@edu, merely continue this trend. In the first case, they are helping Linux to work better in a Microsoft infrastructure, and in the second, they are helping Moodle to work better in a Microsoft infrastructure. Neither of these code releases help any Microsoft product work better in a non-Microsoft infrastructure.
What would be significant is if Microsoft changed their behavior and offered more support for running Microsoft products in a non-Microsoft environment. For example, code contributions to xen or kvm that improved the execution of Windows guests.
But that's not what happened. Microsoft released code that makes it easier for you to run a heterogeneous environment so long as it's being controlled by Microsoft technology. They still very much want to be in control of you and your infrastructure. These code releases are non-events.
Sunday, June 28, 2009
Book Review: The Preparation of Programs for an Electronic Digital Computer
I've recently finished reading The Preparation of Programs for an Electronic Digital Computer. This book is an incredible resource for anyone interested in the history of computing and programming.
First published in 1951, a reprint is available from The Charles Babbage Institute. Often referred to as the first programming textbook, this book is reputed to have been very influential in the early days of computing, being affectionately known as WWG, after the initials of its authors.
WWG describes a computer called the EDSAC, built in Cambridge, England, along with the techniques that had been developed for programming it.
The EDSAC had only been operational for 2 years when WWG was published, so it's a fascinating peek into both the thinking of some of the very first programmers, and also into how quickly some of our standard programming techniques and problems were discovered.
Interpretive routines (what we might call "interpreters" or "virtual machines" these days) were used to make it easier to program with floating point numbers and complex numbers. Although the languages interpreted were very low level, they were meant to be written in by humans, so it also seems reasonable to also call these Domain Specific Languages. It's significant to me that these ideas were developed so early. Modifying our environment in order to fit our needs and wants is a fundamental human characteristic, but doing it purely within software seems like a breakthrough to me.
It's also interesting how quickly programmers started having problems with errors in their programs. The book contains "tracing routines" which will run a program at a tiny fraction of its normal speed, but print out what instructions the program is executing. They can even be configured to trace only certain sections of the code. These routines clearly took a great deal of effort to develop, and I can only imagine this effort being justified by a high rate of programming errors in the early programs.
Other techniques that this book proves to be very old include jump tables and binary/decimal conversions for I/O.
Although the EDSAC used single address instructions, WWG spends a little bit of space discussing other designs, including one where each instruction includes the address of the next instruction to be executed. Used on a storage medium like drum memory or acoustic delay memory where you need to wait for the correct data to become available, this could reduce waiting times. From a data structure perspective, this idea is interesting because it turns the code into a primitive sort of linked list threading its way through memory.
There's a whole section devoted to repetition. There are even subroutines specifically for the purpose of repeating a piece of code a given number of times. Apparently executing a loop the wrong number of times was also a problem right from the start.
It's also interesting how quickly conventions were developed around documentation and program design at Cambridge.
The program listings in the book show, next to each instruction, what instructions jump to that instruction. Apparently the difficulties of tracking jumps were recognized early and this was an effective aid in their management.
The book also contains documentation for a fairly extensive subroutine library. Subroutines were heavily relied upon to save labor, reduce mistakes, and allow the programmer to think about smaller parts of the program at once. This last purpose, explicitly stated in the book, foreshadows structured programming.
If you want to try out the EDSAC, check out the India simulator, which you can
run in your browser or download (alternate site).
This EDSAC simulator only runs on Windows (and old Macs) and doesn't come with source code, but has some very good documents about how the EDSAC worked.
First published in 1951, a reprint is available from The Charles Babbage Institute. Often referred to as the first programming textbook, this book is reputed to have been very influential in the early days of computing, being affectionately known as WWG, after the initials of its authors.
WWG describes a computer called the EDSAC, built in Cambridge, England, along with the techniques that had been developed for programming it.
The EDSAC had only been operational for 2 years when WWG was published, so it's a fascinating peek into both the thinking of some of the very first programmers, and also into how quickly some of our standard programming techniques and problems were discovered.
Interpretive routines (what we might call "interpreters" or "virtual machines" these days) were used to make it easier to program with floating point numbers and complex numbers. Although the languages interpreted were very low level, they were meant to be written in by humans, so it also seems reasonable to also call these Domain Specific Languages. It's significant to me that these ideas were developed so early. Modifying our environment in order to fit our needs and wants is a fundamental human characteristic, but doing it purely within software seems like a breakthrough to me.
It's also interesting how quickly programmers started having problems with errors in their programs. The book contains "tracing routines" which will run a program at a tiny fraction of its normal speed, but print out what instructions the program is executing. They can even be configured to trace only certain sections of the code. These routines clearly took a great deal of effort to develop, and I can only imagine this effort being justified by a high rate of programming errors in the early programs.
Other techniques that this book proves to be very old include jump tables and binary/decimal conversions for I/O.
Although the EDSAC used single address instructions, WWG spends a little bit of space discussing other designs, including one where each instruction includes the address of the next instruction to be executed. Used on a storage medium like drum memory or acoustic delay memory where you need to wait for the correct data to become available, this could reduce waiting times. From a data structure perspective, this idea is interesting because it turns the code into a primitive sort of linked list threading its way through memory.
There's a whole section devoted to repetition. There are even subroutines specifically for the purpose of repeating a piece of code a given number of times. Apparently executing a loop the wrong number of times was also a problem right from the start.
It's also interesting how quickly conventions were developed around documentation and program design at Cambridge.
The program listings in the book show, next to each instruction, what instructions jump to that instruction. Apparently the difficulties of tracking jumps were recognized early and this was an effective aid in their management.
The book also contains documentation for a fairly extensive subroutine library. Subroutines were heavily relied upon to save labor, reduce mistakes, and allow the programmer to think about smaller parts of the program at once. This last purpose, explicitly stated in the book, foreshadows structured programming.
If you want to try out the EDSAC, check out the India simulator, which you can
run in your browser or download (alternate site).
This EDSAC simulator only runs on Windows (and old Macs) and doesn't come with source code, but has some very good documents about how the EDSAC worked.
Tuesday, October 7, 2008
Glomek's guide to good programing
Well, I started writing a post to Stack Overflow, and it just kept coming. By the time I was done, it was longer than it should have been, and after posting I noticed that the original asker had said "please provide one skill" (emphasis added). Anyways, I thought that it might be interesting enough to include on my blog. Enjoy.
Deliberate style decisions. Having all of your code formatted the same way will make maintenance easier.
Once And Only Once. Try to have each piece of "how to do X" knowledge only represented once. Try to have each piece of information only stored in one place.
Abstraction. A good abstraction is not just an abbreviation for typing. It is a tool to think with, an idea that stands on its own.
Modules. Hide design decisions inside of modules to make changing your mind easier.
Push complexity into data when it will let you simplify the code. Complicated data is better than complicated code. Data is easy to reason about. It sits there. Code is difficult to reason about. It has a dynamic environment and behavior that change while it is executing.
The Unix Way. Small, simple building blocks which can be combined in arbitrary ways are more useful than large, super functional building blocks that can only be used in a couple of ways.
Data Directed Programming. Lots of problems get easier to solve when you handle them by looking up a piece of code (closure, object, function pointer, execution token, whatever) in a data structure and executing it.
Functional programming. Not all problems can or should be solved in a purely functional style (IMHO), but when practical, purely functional code can be easier to write correctly and easier to debug than imperative code. Only introduce mutable state when there is a payoff in increased modularity.
Imperative programming. Learn how to write imperative code. You may need to read old books in order to do this since everyone is all into objects and functions these days, but you will write imperative code, and being good at it matters. Dijkstra wrote quite a bit about how to design an imperative program and how to prove that it does what it should. I highly recommend the book Structured Programming.
Use meaningful identifiers.
Don't be afraid to pull out the big guns when faced with a big problem. It's amazing how often I see someone spend a ton of effort trying to make a small tool do the job of a big tool, because the big tool is "too hard," when using the big tool would actually be much easier.
Don't be afraid to use old fashioned techniques when they fit your problem. I still occasionally use Control/Break processing, a trick that I learned from a Cobol book.
Learn how to type.
Master your text editor.
Master your command shell.
Deliberate style decisions. Having all of your code formatted the same way will make maintenance easier.
Once And Only Once. Try to have each piece of "how to do X" knowledge only represented once. Try to have each piece of information only stored in one place.
Abstraction. A good abstraction is not just an abbreviation for typing. It is a tool to think with, an idea that stands on its own.
Modules. Hide design decisions inside of modules to make changing your mind easier.
Push complexity into data when it will let you simplify the code. Complicated data is better than complicated code. Data is easy to reason about. It sits there. Code is difficult to reason about. It has a dynamic environment and behavior that change while it is executing.
The Unix Way. Small, simple building blocks which can be combined in arbitrary ways are more useful than large, super functional building blocks that can only be used in a couple of ways.
Data Directed Programming. Lots of problems get easier to solve when you handle them by looking up a piece of code (closure, object, function pointer, execution token, whatever) in a data structure and executing it.
Functional programming. Not all problems can or should be solved in a purely functional style (IMHO), but when practical, purely functional code can be easier to write correctly and easier to debug than imperative code. Only introduce mutable state when there is a payoff in increased modularity.
Imperative programming. Learn how to write imperative code. You may need to read old books in order to do this since everyone is all into objects and functions these days, but you will write imperative code, and being good at it matters. Dijkstra wrote quite a bit about how to design an imperative program and how to prove that it does what it should. I highly recommend the book Structured Programming.
Use meaningful identifiers.
Don't be afraid to pull out the big guns when faced with a big problem. It's amazing how often I see someone spend a ton of effort trying to make a small tool do the job of a big tool, because the big tool is "too hard," when using the big tool would actually be much easier.
Don't be afraid to use old fashioned techniques when they fit your problem. I still occasionally use Control/Break processing, a trick that I learned from a Cobol book.
Learn how to type.
Master your text editor.
Master your command shell.
Wednesday, September 24, 2008
When clock speeds stop increasing
I look forward to the day when clock speeds stop going up.
When the day comes, I'll be able to buy a computer and keep using it for five, ten, maybe even twenty years. The last several computer purchases that I have made were driven not by any problems with my current machine, but by the fact that new software keeps needing faster and faster computers. Once the computers stop getting faster, the speed requirements from software should stop going up.
Most developers will not be moving to an arbitrary-number-of-threads model. They may use a few threads for things like doing something asynchronously or keeping the UI responsive. This means that doubling the number of cores in a chip won't help most applications past 4 or 8 cores.
Right now, the constantly increasing clock speeds help to hide terrible code. If something is too slow on today's computers, don't worry about it. It'll run fine on the computers that will be out in 18 months. Once the clock speeds stop increasing, developers will need to start caring about efficiency again. The quality of a piece of code might start mattering more than the time to market. We'll finally get software that is focused on performing its core function well instead of on adding every last bell and whistle that the marketing department can think up while implementing all of them poorly.
Open Source software will catch up to proprietary software. The only way for proprietary vendors to stay ahead of Open Source software is to write new code faster than the Open Source community does. One common way of writing code faster is to worry less about its quality and efficiency. Once the proprietary authors need to worry about efficiency, they won't be able to turn out crap as fast as they do now.
When the day comes, I'll be able to buy a computer and keep using it for five, ten, maybe even twenty years. The last several computer purchases that I have made were driven not by any problems with my current machine, but by the fact that new software keeps needing faster and faster computers. Once the computers stop getting faster, the speed requirements from software should stop going up.
Most developers will not be moving to an arbitrary-number-of-threads model. They may use a few threads for things like doing something asynchronously or keeping the UI responsive. This means that doubling the number of cores in a chip won't help most applications past 4 or 8 cores.
Right now, the constantly increasing clock speeds help to hide terrible code. If something is too slow on today's computers, don't worry about it. It'll run fine on the computers that will be out in 18 months. Once the clock speeds stop increasing, developers will need to start caring about efficiency again. The quality of a piece of code might start mattering more than the time to market. We'll finally get software that is focused on performing its core function well instead of on adding every last bell and whistle that the marketing department can think up while implementing all of them poorly.
Open Source software will catch up to proprietary software. The only way for proprietary vendors to stay ahead of Open Source software is to write new code faster than the Open Source community does. One common way of writing code faster is to worry less about its quality and efficiency. Once the proprietary authors need to worry about efficiency, they won't be able to turn out crap as fast as they do now.
Wednesday, September 10, 2008
Wither imperative programming?
I write imperative code. Code with reassignment statements. Code that mutates data structures. Code with side effects. There. I said it.
In fact, it's even worse than that. Most of the time, the primary purpose of my code is the side effects. I don't write much code to figure stuff out. Sometimes I do, and when I do I try to program in a purely functional style as much as I can. But the fact is, most of the time, most of my programs exist for the purpose of doing something, not figuring something out.
Sometimes I structure my code using objects. Sometimes I just make libraries that each contain related utility functions. Sometimes I use closures. Whatever route I take, there are almost always important parts that are shamelessly imperative.
I mentioned in my last post that I mostly read old books. This is partly out of interest in history, partly because I have a greater interest in the subjects that were popular in the 1960s and 1970s than the subjects that are popular now, and partly because some of them are just great books that happen to be old. But I recently noticed something else that distinguishes my old books from my new books. The old ones talk about imperative programming!
They talk about how to use assignment statements and side effects, and how to write loops that contain assignment statements and side effects, and how to think about this code and how to write it and how to convince yourself (with a formal proof, if necessary) that it does what you want it to. I don't know of any recently published books that discuss this stuff. Do you?
Why is this? Are recent authors under some kind of delusion that because imperative programming is difficult we aren't doing it, and thus there's no need to talk about how to do it? Are the academics so focused on type systems and concurrency and functional programming that they no longer consider imperative programming interesting enough to write about?
In fact, it's even worse than that. Most of the time, the primary purpose of my code is the side effects. I don't write much code to figure stuff out. Sometimes I do, and when I do I try to program in a purely functional style as much as I can. But the fact is, most of the time, most of my programs exist for the purpose of doing something, not figuring something out.
Sometimes I structure my code using objects. Sometimes I just make libraries that each contain related utility functions. Sometimes I use closures. Whatever route I take, there are almost always important parts that are shamelessly imperative.
I mentioned in my last post that I mostly read old books. This is partly out of interest in history, partly because I have a greater interest in the subjects that were popular in the 1960s and 1970s than the subjects that are popular now, and partly because some of them are just great books that happen to be old. But I recently noticed something else that distinguishes my old books from my new books. The old ones talk about imperative programming!
They talk about how to use assignment statements and side effects, and how to write loops that contain assignment statements and side effects, and how to think about this code and how to write it and how to convince yourself (with a formal proof, if necessary) that it does what you want it to. I don't know of any recently published books that discuss this stuff. Do you?
Why is this? Are recent authors under some kind of delusion that because imperative programming is difficult we aren't doing it, and thus there's no need to talk about how to do it? Are the academics so focused on type systems and concurrency and functional programming that they no longer consider imperative programming interesting enough to write about?
Subscribe to:
Posts (Atom)
