E.W. Dijkstra Archive: Answers to questions from students of Software Engineering (EWD1305): "The programmer should not ask how applicable the techniques of sound programming are, he should create a world in which they are applicable;"
Python 3000 Status Update (Long!): "Python 3.0 will break backwards compatibility. Totally. We're not even aiming for a specific common subset. (Of course there will be a common subset, probably quite large, but we're not aiming to make it convenient or even possible to write significant programs in this subset. It is merely the set of features that happen to be unchanged from 2.6 to 3.0.)
Python 2.6, on the other hand, will maintain full backwards compatibility with Python 2.5
...
The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows:
The conversion tool produces high-quality source code, that in many cases is indistinguishable from manually converted code. Still, it is strongly recommended not to start editing the 3.0 source code until you are ready to reduce 2.6 support to pure maintenance (i.e. the moment when you would normally move the 2.6 code to a maintenance branch anyway)."
Pimp My Code, Part 14: Be Inflexible!: "You've probably seen some variant of this, but I'll show you my version. In coding, you have many dimensions in which you can rate code:
- Brevity of code
- Featurefulness
- Speed of execution
- Time spent coding
- Robustness
- Flexibility
Now, remember, these dimensions are all in opposition to one another. You can spend a three days writing a routine which is really beautiful AND fast, so you've gotten two of your dimensions up, but you've spent THREE DAYS, so the 'time spent coding' dimension is WAY down.
So, when is this worth it? How do we make these decisions?
The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to:
'START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING.'"
I'm a proud seat-putter-downer and occasional pee-sitting-downer and now there is scientific proof supporting my stance... err... seat:
The Science Creative Quarterly » THE SOCIAL NORM OF LEAVING THE TOILET SEAT DOWN: A GAME THEORETIC ANALYSIS:"Seat Up" may be more efficient, but "Seat Down" results in a more natural social balance.
"Discussion and conclusions
For “mankind”, the analysis in this paper has the following appeal: Once again, it has been found that the social norm of leaving the toilet seat down is inefficient; hence, “mankind” may feel vindicated.
For “womankind”, the analysis in this paper is appealing for the following reason: It has been shown that the social norm of leaving the seat down is a trembling-hand perfect equilibrium. Hence, this norm is not likely to go away, at least in the near future."
This could be really cool, if it's true...
For a long long time now, I've been asking people (any one who has the unfortunate luck to get me rambling about my hair brained pseudo-scientific daydreams), "Why don't we hear more about crazy inventors trying to capture and reuse some of the waste heat that nearly every human activity and technology produces?!" I've always gotten answers like "... well, in this house, we obey the laws of thermodynamics!". Well, Borealis Exploration Limited, seems to think this concept isn't so crazy. I read this on the Internet so that mean it's true :P
Power Chips plc: "Power Chips™, which use thermionics to convert heat directly into electricity, will be one of the first industrial applications of nanotechnology. These small, solid-state devices promise to improve current power generation and waste heat recovery techniques. Power Chips will deliver up to 70-80% of the maximum (Carnot) theoretical efficiency for heat pumps (conventional power generation equipment operates at up to 40% Carnot efficiency).
Power Chips plc has devised 'Power Chips' which generate electricity by using heat to move electrons from one side of a vacuum diode to the other. The system, currently under development, contains no moving parts or motors and can be either miniaturized or scaled to very large sizes for use in a variety of applications. Whether it is to recover energy from the waste heat of traditional engines and turbines, or to replace them completely with a compact and efficient solid-state system, Power Chips present product engineers and project managers with a broad array of design options.
We are actively seeking licensees and development partners for a number of specific applications of Power Chip technology. Our current development efforts are centered around increasing power density of research prototypes and refining manufacturing processes to complete production prototypes.
More detailed information on Power Chips can be found by reviewing our patent portfolio in the Technology section of this site. If you have specific questions about your potential application for Power Chips, feel free to contact us."
This is an excerpt i stole from an email i sent to a good friend of mine who, i really hope, doesn't mind receiving my raving, seemingly unprovoked, rants!
"... On a separate note, let me ask, how do you like [social networking site A]? I really like it. I think it's a thousand times better then [social networking site B] but it still drives me nuts! I wanted to share the info that you gave me in your [social networking site A] message with [another member of social networking site A], but there is no way to forward!
Not only do i have to open my email, and then follow a link, and then sign into [social networking site A] just to read the damn message, but then i need to copy and paste it to forward it to someone?! and i can't send to multiple recipients through [social networking site A] so i need to come back to my email!
It's so dumb! They are trying to drive traffic to their site by providing services that enhances social communication on the Internet and that's great ... but for the love of crap, [social networking site A], don't try to force me to use your site _instead_ of email, when you could integrate with the original social networking tool, that we all, already rely on and have relied on since the early 90's!!!
When someone messages me and you want to notify me via email, SEND ME THE FUCKING MESSAGE BODY TOO!!! I will still visit your site and see your bloody ads while i use the services and features that go above and beyond email, and actually _require_ your system! but whenever you can, for fuck sakes, TRY TO MAKE MY EXISTING TOOLS BETTER, don't fucking try to cripple them!!!
... ok, sorry, i just had to get that out...
it's kinda related to some of the stuff we (a few friends of mine) are working on. We might be trying to [do something] around fixing the lack of integration between social sites. I'm pretty excited about it! I've been thinking about this for a long time, even before i realized all my friends were using [social networking site B] and how terrible [social networking site B] is. Now that everyone seems to be jumping onto [social networking site A], and i'm forced to use their tools in the way they intended, i'm even more motivated to fix some of this stuff."
Google Testing Blog: TotT: Stubs Speed up Your Unit Tests: "By substituting custom objects for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.
A variety of different terms are used to refer to these “custom objects”. In an effort to clarify the vocabulary, Gerard Meszaros provides the following definitions:
* Test Double is a generic term for any test object that replaces a production object.
* Dummy objects are passed around but not actually used. They are usually fillers for parameter lists.
* Fakes have working implementations, but take some shortcut (e.g., InMemoryDatabase).
* Stubs provide canned answers to calls made during a test.
* Mocks have expectations which form a specification of the calls they do and do not receive."
ORDER OF THE SCIENCE SCOUTS OF EXEMPLARY REPUTE AND ABOVE AVERAGE PHYSIQUE
The "talking science" badge.
Required for all members. Assumes the recipient conducts himself/herself in such a manner as to talk science whenever he/she gets the chance. Not easily fazed by looks of disinterest from friends or the act of "zoning out" by well intentioned loved ones.
The "I blog about science" badge.
In which the recipient maintains a blog where at least a quarter of the material is about science. Suffice to say, this does not include scientology.
The "arts and crafts" badge.
Because you can't have a bunch of badges without an arts and crafts badge. This one assumes the recipient has all manner of "craftiness" with a sciencegeek twist.
The "I bet I know more computer languages than you, and I'm not afraid to talk about it" badge.
It could get ugly when two or more of these recipients get together.
I recently spammed my friends and co-workers with a success story and commented about how Python could be the salvation of a certain project with a particularly gnarled PHP based front end.
I was cautioned by a wise and pragmatistic friend:
Why not suggest Lisp?
http://www.paulgraham.com/avg.html
Latching on to a single language / platform / religion does not guarantee success or salvation.
All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in itOk, so what? Any dynamic language meets this definition power. Perl, Ruby, Python, maybe even PHP (just to list a few of the popular kids). What makes one any more desirable than the others? Religion?
--Paul Graham http://www.paulgraham.com/avg.html
Religion: The collective customs and traditions of a body of people that have formed an organization or an institution to pursue the study of a specific teaching or belief.Perl has a underlying philosophy: "There's more than one way to do it" (Which Ruby has adopted).
PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely convenient solution.
--Rasmus Lerdorf (the creator of PHP)
I've been called a whiner. It is true, and I'd like to apologize right now. I'm not sorry I'm a whiner, but I am sorry that my vocal nature isn't positive more often than it's negative.
My company is, apparently, looking for web-developers. I think we need software developers regardless of web experience. Most web developers have bad habits that are hard to break. I don't think we should be in the business of programming web pages. We should be programming tools for building web pages. We should be hiring web-designers who can be trained to use the tools that our software team develops and our software team should be watching and listening to the needs of our web-designers.
When I see how fast we turn projects around, I'm not unhappy but, I'm not satisfied. When I see the code that we produce I think, "This isn't so great. Man, we could do so much better". This code comes mostly from juniors but also from our seniors (this includes myself). Most of our code is most often seen only by the author until it needs to be fixed or reused.
When I make an implementation choice and I ask peers for feedback I sometimes get "That sounds good, lets do that". Other times I hear "Well, why don't you do it this way..." and we have a discussion (usually very productive). The prior is not due to my ability to produce flawless design, but more usually due to the peer's overloading or lack of investment in the details of that particular project. The later is something that should happen to every implementation decision made by every coder.
I know I'm not the greatest tester (most developers are terrible testers) but I get frustrated when fixing the most basic of bugs that weren't found until weeks or months after the fact. I get especially frustrated when they are bugs in my own code and more so again when it was my own testing that didn't catch it.
I really do think we have the potential to be the best at what we do. All we need is to just do it, and do it right!
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
This Man was sitting atop a mountain, legs in lotus position, palms gently resting towards the sky, in quiet meditation. If you asked this Man what he was doing he would respond, at great length, about the nature of his mediation. He would tell you that his mediation was of a truly zen nature. He would tell you that his meditation gave him terrific mental powers. He would tell you that his mediation gave him memory beyond memory.
Many years ago this Man's memory was said to be quite awful. Many people said this about him, at many times, in many places. After many years of forgetting many things, he decided to change for the better. He began meditation upon this mountain.
If, by some magical ability, you were able to go up that mountain and go to that Man and, without interrupting his meditation, enter his very mind, you would immediately be struck by his inner monologue: "... don't forget the mayonnaise... don't forget the mayonnaise... don't forget the mayonnaise...".
I know this Man.
M.
