What you suggested is keeping a more critical eye on corporations than government.
Sigh. Not at all. I talked about corporations. You heard criticism of one institution and automatically assumed a particular polar opposition in which criticism of the first institution must be understood as relative praise of the other.
By the way, the rhetorical trick of conflating criticism of one thing with praise of something else only works if your target is afraid of supporting the something else. I LIKE government. Ha. The same way I like people, corporations, and unleashed dogs I meet at the park.
What I assumed is that... particular place and time.
Why would I disagree with that? If you put that on a piece of paper, 95% of the American electorate would sign it.
Weight is extremely important and was probably the primary target -- hence the name "Air". As for the thickness, yes, it does matter. When your briefcase is shoved between your feet in coach, or stuck between your body and the side of a subway car, or crammed full of books and papers, it does matter how thick your laptop is. If image is important to you (which it probably is if you buy Apple) or important to your career (which it definitely is if you don't have to fly coach) then, well, I'm pretty poor at that kind of thing myself, but I know that slimmer is better. So in that case...
People with really thin briefcases and large piles of money?
The Air isn't a notebook; it's a wireless portable screen & keyboard for your network (& limited stand-alone use). You walk in, sit down, open it up, and work on files stored on the network. It's not aiming at a market segment; it's aiming at a paradigm.
It sounds like you're talking about the thin client network computing paradigm that people have been pitching since... I'm not sure when, but at least the early nineties. That may or may not have been your intent, but regardless: the Air has absolutely nothing to do with network computing. The Air runs a full OS and has plenty of processing power. You won't have any trouble installing as much software as you want. It even has a decent amount of space for data. It doesn't cater to:
Exchanging data on physical media.
Local storage of massive amounts of data, such as all of your work files or entertainment media.
Frankly, there's nothing new about this way of working, except for people who are accustomed to carrying around hundreds of gigs of media files. The Air fully supports the way most people already live and work. At my current job, we all have a laptop, and most of us have a desktop, too. I've been there for nine months and haven't seen a single person use optical media, except for a few people who bring music CDs to work instead of ripping them to a player. We store email and working copies of files on our hard drives, and everything else on servers. Now that I think about it, none of us use wired ethernet for our laptops, either. (The only reason email is stored on our local disks is to encourage its deletion, for the standard corporate legal reasons.)
I admit that most of the people I work with would still call a laptop without an ethernet port or an optical media drive "useless", even though they never use them. Perception lags behind reality in this case. The Air is aimed at people who are in touch with the way they live and aren't scared of losing features they stopped using years ago.
Trust the server (to an appropriate extent). Trust the client, which is under your physical control. Trust the certification authorities. Trust your certs for the certification authorities. Trust secure protocols to tie everything together. All of those things can be reasonably accomplished, and voila, you have a reasonably secure system.
If I don't carry my own client (e.g., web browser) around with me, then I have to trust whatever client I pick up wherever I want want access: at my friend's house, the library, a coffeeshop, etc. What I would need is an implementation of security protocols running on my storage device. That way it could validate whatever client I plugged it into and flash a little green light signifying that the piece of hardware I picked up off the park bench is actually running approved software! What's that called again? Oh yeah, trusted computing. Good luck getting that to work with anything that doesn't have a corporate sponsor -- like the server in your closet, or your unlocked cell phone. If it ever works at all, that is.
Or you could just carry around a client and your own hardware, which is a much simpler and more secure scenario.
"Quite" downloadable? Maybe "somewhat" downloadable or "technically" downloadable. I don't really have time for games these days, so it was exciting when I decided to blow a whole weekend playing the new games everyone was talking about. I bought the Orange Box on Friday night. When I saw how much still remained to be downloaded on Saturday morning, I just about lost it. So much for that weekend -- I blew the next weekend playing Half-Life 2 and Portal.
What a bizarre response. I suggest keeping a critical eye on corporations, and you think that means turning an uncritical eye toward the government? What kind of dangerous weirdo goes through life looking for a social organization worthy of their absolute trust?
I haven't even seen the movie you're talking about. I'm a liberal capitalist (that's what Americans call an "economic conservative," by the way, and has little to do with the American word "liberal") and I like corporations. I like people, too, but I won't buy a Rolex out of a briefcase. A sucker mentality doesn't benefit anyone except parasites.
The guy wants Apple to ship a working DTrace. Why should they? To regain community goodwill and get absolution from an official DTrace developer. He left the door open for that. That's the carrot. By publicizing statements on his blog and getting it submitted to Slashdot, he has proved how much trouble he can stir up. By understating the case, he reserves the threat of stating it plainly if they take no action. That's the stick. Now Apple has to weigh community goodwill against DRM dollars and decide whether to ship a working DTrace. Whereas, if he had immediately shoved the carrot up his ass and started flailing around with the stick, Apple would have shrugged their shoulders and moved on.
And some would argue that corporations are valuable economic engines that have built-in antisocial tendencies that can never be eradicated, but must be constantly monitored and kept in check. Corporations are powerful entities that resist those efforts, making it a struggle.
The struggle between "good" entities and "evil" ones is a mythical recasting of the everyday struggle between good and evil elements of every person. People are impure, institutions are impure. Corporations are a valuable kind of institution, which is why we have laws enabling their existence, yet it would be foolish to turn a blind eye to everything they do, or assume that whatever they want to do must be right in some way we don't understand.
The MBA is a computer for people with smooth hands.
You might want to consider a less disturbing way of saying... whatever creepy shit you're trying to say. I'm going to go sit in the bathroom until this queasy feeling goes away.
If I need a compiler to try out my theory, but every "particular" compiler is useless, then I'm stuck unless I can use a bunch of compilers at the same time, or maybe download and install the Platonic ideal corresponding to "compiler." See, I'm getting the hang of it!
Seriously, particular knowledge isn't bad. It isn't polluting. The fact remains that you can't get a decent CS education without hands-on work, and whatever tools you use for practical work will be "particular" tools. A certain level of technical competence is necessary to experience the relationship between theory and practice, and it should be designed into every CS curriculum.
Besides, the line between "particular" and "general" is impossible to draw. Using gdb to debug a C program on an embedded processor and using the Eclipse Java debugger to debug a Java GUI are remarkably similar. Set breakpoints, examine the stack, watch variables, skip the next 142 executions of this breakpoint, whoops! can't see much in code compiled without debugging info. A debugger may seem very particular, but debuggers are remarkably pervasive throughout programming and remarkably similar to each other. Using one compiler is similar to using the next. Doing code generation that targets one ISA will prepare you to do code generation that targets another ISA. Using one regular expression library is remarkably similar to using another.
All of these things may sound ridiculously banal, but building real systems is remarkably banal, even when you're building them to test exciting theories. You don't deal with the banal by struggling proudly and miserably through it, you deal with it by mastering it so thoroughly you never have to think about it again.
Not any more than physics is theoretical learning. Computer science goes in two directions: developing theoretical models to help understand real systems, and making new systems with the benefit of theoretical insight. In addition to theory, you have to learn measurement, experimentation, and ways of building systems. Traditionally, the discipline of "computer science" includes mathematicians who happen to work on problems remotely motivated by computer science, but we shouldn't attempt to excuse even those very few people from practical work. First, we can't figure out who they're going to be ahead of time; many who aspire to it will end up doing practical work. Second, many of those who land the coveted research positions have to teach practical CS courses. Third, if they're so damned convinced they're going to be theoreticians, a math major is better preparation anyway.
Looking past the humorous notion that academics could agree about anything, they certainly don't agree that universities are in the business of "get[ting] people to be able to go onto a Masters and PhD and be able to do actual research." Professors *know* what their students are going to do after university, they *know* most of them aren't going to be researchers, and they don't believe in preparing students for an imaginary future -- nor do they believe that students who are not future researchers should be excluded from universities. Quite a few academics believe that ideally, almost everyone would attend university. The closest your statement comes to the truth is this: Most professors (though not all by any stretch) believe that the same skills essential for research are essential for living an educated, critical, responsible life.
P.S. Try picking up a copy of the Chronicle of Higher Education sometime, and you'll see that American professors do quite a bit of arguing about the proper role of universities, and very few of them conform to your characterization of academics.
(P.P.S. Perhaps you wanted to specifically refer to a particular type of German institution? The English word "university" will not get your meaning across if you really mean Universität. A Fachhochschule is a university. But even if that's what you meant, there is no general agreement among academics, even German ones, that the German system is ideal.)
Except when it's been JIT compiled to native code. And except when it's translated by hardware directly into microcode, which is the same thing that happens to "native" code on the same platform.
The notion that Java can is a suitable C/C++ replacement for everything but drivers is sadly common
That's ridiculous. Where did you pull that silly strawman from? Looking back to the GP, he says that for 10% of the tasks he has faced, Java isn't a suitable replacement for C or C++. Why don't you look over this thread and find someone willing to profess that belief?
Sometimes you want to name them. Other times you don't. (I'm sure you wouldn't want to think up a unique name for each iteration block in your program.) Limiting lambdas to a single expression in Python (and enforcing read-only closures) limits some of their applicability and power for abstractions
I think we're very close to being on the same page here, but I wonder whether you will agree to the following: There are two ways to put it. Python lambdas are crippled; or, Python often forces you to define a class or a named function when you would rather use an anonymous lambda expression. The second way is less prejudicial and just as accurate. In the vast majority of cases, you don't forgo the lambda; you write a few extra lines of code, introduce a superfluous name, and enjoy the same power as languages with good lambda statements, at a slight cost of elegance. In the few cases where the readability cost is so high that you choose a different program structure instead, it makes sense to say that Python has less power. Those cases are rare, so (in my mind) the primary consequence of Python's crappy lambdas is a decrease in readability.
Make a named function and cover up the name with your finger;-) I did say fake. It's visual clutter and imposes a certain amount of cognitive overhead; no arguments about that.
"I don't really know much about Python. I only stole its object system for Perl 5. I have since repented." Larry Wall
Python's object system is working just fine. By contrast, the decision to scrap Perl 5's object system was entirely uncontroversial. I think that says everything that needs to be said about Perl 5 OO, and it comes straight from the Perl community itself.
But in case elaboration is desired, you don't see Python programmers going around saying, "Here, look at this. I really didn't 'get' Python classes until I read this amazing article," and then a week later, "I think I understood classes for a while last week. It was pretty cool, but you'd have to be crazy to use that stuff unless you had a really nasty problem." The two models may be the same at some level, but Perl's was expressed so poorly that simply explaining it for mere mortals was considered a major achievement. I could teach Python's object system to any of my colleagues in an afternoon, using the morning to brush up on the technicalities and plan my presentation. If I could do that with Perl, I'd be some kind of Perl God (like Damien Conway). Given that the fatal flaw with Perl 5 OO was its obscurity, and the biggest asset of Python OO is its lucidity, that quote from Larry Wall is, like many other things he says, absolutely shameful unless interpreted in whatever special ironic context he said it in.
(The difference between Python lambda fakery and Perl object fakery epitomizes the difference between the two languages. Python falls back on simple, universally-understood language features to provide a somewhat clunky, verbose, yet clear solution; Perl falls back on language wizardry to provide an obscure but concise solution. In most cases Perl achieves a much better tradeoff than it did in the case of objects.)
I prefer to hire people who are good at programming to write and maintain code I care about.
Me too; I'm a professional software developer. I was just pointing out that the "Python is for experts" slogan you may have heard from Pythonistas is half ironic; it's about Python being usable by people who are *not* experts in software but who *are* experts in their own field, whatever that may be. (I don't know how well that works in practice, being surrounded by software experts myself.)
perhaps it's appropriate to judge the design of Python in terms of how it supports important features on which to build larger and more elegant abstractions.
Closures and lambdas can be faked using objects and named functions. It's admittedly awkward, but at least it's intelligible. The code can be read and understood without being a Python language junky. (Is there even such a thing as a Python language junky?)
Compare that to Perl5 OO. Perl5 OO is dog food, yet Perl 5 library authors consistently use it to define their library interfaces. All those libraries may toss the OO and rely on hashes of closures behind the scenes -- I haven't checked -- but library programmers evidently find it advisable not to share their elegant abstractions with users. Instead, they use objects, which (in Perl5) are wonky, bizarre, and understood by practically no one who isn't a Perl language guru. The fact that library authors define their interfaces in terms of constructs that few people understand seems like an admission that Perl has its own problems creating elegant abstractions.
plenty of people seem to think that Python is a language that scales up for experts
Actually, the idea is that you can know enough about Python to work competently with Python code and still have enough brainspace left over to be an expert in something besides programming. Try THAT with Perl.... I mean, try that sometime when you're not ten times as smart as I am:-(
A rough rule of thumb - It is twice as hard to unravel existing code as to write it again from scratch.
You've misremembered this saying in a crucial way. The more common (and more correct, IMO) wording is, "It's twice as hard to read existing code as it was to write it in the first place." Reading the existing code only takes twice as long as it took the original programmer to write *those lines* of code in the first place. It doesn't matter how many false starts and bug-fixes were involved. However, unless you assume that you're smarter than the original programmer, you have to assume that you will go through a similar pattern of false starts and bug-fixes.
Plus, the rule of thumb only applies to the first working version of code. Allow me to illustrate with a rather extreme metaphor. Compare the effort required in understanding just the definitions and proofs in an undergraduate real analysis textbook (skipping the rest of the text) against the effort required to recreate the theory yourself. Reading just the definitions and proofs is a feasible way of learning undergraduate analysis (some people actually do it that way) because the theory has been refined over centuries into an elegant system.
As with mathematics, the more effort is invested into refining and refactoring code, the easier it becomes to understand. Every time I revisit a module to fix a bug or add a feature, I spend a few moments reorienting myself and often discover a way to clarify the code. "What was I thinking? Looking at this module after some time away from it, the structure of the code doesn't help me remember the logic at all. Hmmm, but if I... then the logic becomes more evident." If you compare the first version of my code to the form it converges on, the first version has less functionality and would therefore be easier to rewrite from scratch, but the second version is easier to understand.
Honestly, though, unless you can get your hands on an old-timer who knows the code, you can't plan on ever grokking the program theory of the old code. There's no alternative but to keep the old code running and do as few bug fixes and enhancements as absolutely necessary. The old code has its own logic, but as soon as you start messing with it, it will turn into exactly the incoherent mess that you perceive it to be. If you don't mess it up, it has value as a working product and a reference implementation. It gives you breathing space so you can figure out how to live without it. Maybe you replace it with a new product that fills the same role. (Obviously if you're going to put in the effort of building a new product, it shouldn't be a rewrite of the same functionality -- it should be a better product that takes advantage of new ideas, new hardware, etc.) Maybe you refocus the company around a different set of products.
This has a science-fiction feel to it, though. Why do people consider this an important question? Surely it's just as silly as people getting all excited about their post-apocalyptic fantasies where they morph from average guys into civilization-rebuilding supermen? Just like the US and the USSR went to great lengths to avoid the Cold War going nuclear, a company is going to pay whatever is necessary to keep one guy around who knows the old code, or at least pay him to consult. The new programmers can call him on the phone and ask questions like, "I need to enhance the product to handle non-ASCII ISO-8859-1 characters. Is it a big job or a trivial one? What are the modules that probably need to be fixed?" and "It gets really slow when more than ten clients connect at the same time. Why would that be?" After he has explained his thinking on enough questions like that, the new programmers will have absorbed enough of his understanding that it won't be legacy code any longer.
If a company is stupid enough to keep off handing big, valuable codebases to new teams without guaranteeing access to previous developers, then a better question for their developers is, "What's the job market like?"
I also despise the XP directive to not comment code, which Fowler promotes.
I think Martin Fowler (and everybody else with a lick of sense) actually agrees with you. As I understand it, the XP objection to writing comments has been overblown by a few XP proponents and a horde of XP detractors; what you find in the mainstream XP writings is a twofold argument that writing comments should not be the first response to unclear code:
Clarify your code before resorting to comments. If a section of code is complicated enough to need comments, it was probably written suboptimally the first time through, when the programmer's understanding is incomplete. If you write comments before cleaning up the code, the comments end up being an apology for a convoluted first-stab implementation. This (as I understand it) is Fowler's main complaint about lengthy code comments: they're a bad code smell in themselves and often indicate poorly organized code that should be scrapped, not documented. A quick rewrite with the benefit of hindsight will greatly improve the code clarity, perhaps eliminating the need for comments. Unfortunately, this bit of advice pisses programmers off because it assumes that they don't clean up code as they go along. Some programmers do so instinctively, and the rest are fed up with being told to.
Why write a comment when you can express it as a test and kill two birds with one stone? This tends to piss people off because it assumes, as many other part of XP do, that the programming group is following XP wholeheartedly. That means that every programmer who works on a piece of code is familiar with all the tests for that code and will refer to them when he needs information about the code. This is actually a very uncommon way of working, so the advice that depends on it is useless to most programmer. In the context of a full commitment to extreme programming, though, the advice makes perfect sense.
After applying these two principles (and ignoring the second if it doesn't apply,) I think XPers are happy to add whatever comments are useful. There are some XPers who take the "comments are bad" principle and make it EXTREME!!!!!!! (insert image of snowboarding Mountain Dew drinker, which dates XP pretty accurately,) and eXtreme Programming is an unfortunate name that positively *invites* confusions like these, where the most extreme statements made by any self-proclaimed XPer are taken to be the true XP way. The strict "no comments" rule is a minority viewpoint and not one advocated (AFAIK) by the originators of XP and the most common XP resources (the Extreme Programming Explained series, extremeprogramming.org, etc.)
An open system is great until people start exploiting it for all the "wrong" reasons.
It's still great even then. Sticks, stones, knives, wheels, writing, domesticated horses, the postal system, electricity, narcotics, light bulbs, and email are all used for bad purposes, but they're used to far greater good effect than evil. I'm sure criminals will have a field day with the OLPC, but people will be too busy managing the positive effects to care. It's very hard to design morality into tools, especially with code, yet tools tend to have positive effects. Even explosives might break even, given their use in constructing dams, railroads, and other infrastructure that helps protect people against regional and temporal fluctuations in agricultural output.
Anyway, I imagine a 419 scammer would use exactly the same tools as a small e-commerce site: CRM, mailing lists, maybe some basic filtering to do triage on incoming email. The only difference is that they would populate their mailing lists by buying email addresses in bulk instead of asking customers to opt in. Well, plus they need a program to convert everything they type into all caps. So I agree that no one should write a program like that:-)
I'm not even sure that 419 scamming is really such a bad thing considering the context. At least the kids doing it aren't fighting in rebel armies or eking out a premodern living somehow. Eventually the economy will have to grow and modernize, and when that time comes, investors will probably be wishing there were more people with basic computer literacy, i.e., more people who worked on 419 scams instead of making an honest living in factories or on farms.
But why does he persist in web consulting if that's where those types are? He could be working with saner people in an area less rife with hype. It's not like he's doing it for the money... is it? If he's doing it just because the web is the trendy place to be, then he's using the same heuristic the fakers use, which is a bad mistake if he can't tolerate working with them.
Sugar and Hildon are both small, simple desktops based on GTK, so hopefully it will turn out to be no great effort to adapt Hildon programs for Sugar and vice-versa. Let's face it, we do a much better job at developing applications that we use ourselves. How can I develop an application for children? I've mostly ignored them since I was one myself, and if conventional wisdom is correct, adults are doomed to underestimate them, even when we are forewarned of this danger. But I know what I like -- simple study tools and educational games are fun to play on public transit and other dead time, or just ostentatiously improving oneself in a big comfy chair at the local coffeehouse. If they can also be used by children on the OLPC, well, that's a hell of a warm fuzzy, and a good line to use on chicks. (Can it be... a massive convergence of the interests of narcissistic hipgeeks and developing-world children? Count me IN!)
Mongrel is a Ruby web application container mostly written in Ruby, except for the HTTP parser is written in C/Ragel. It has very good performance, and the Ragel state machine definition was derived directly from the BNF in the HTTP specification, so it also has extremely strict standards compliance.
fastthread is a Ruby library which "hot-fixes" the Ruby standard library to provide optimized versions of its thread synchronization primitives. It was mainly intended to improve performance, but as a side-effect it also worked around some long-standing bugs in the core Ruby classes which resulted in memory leaks and interpreter crashes under high load.
I have to ask: why is a guy with his talent and skills looking for consulting jobs doing web development? Isn't that an entirely different skill set, not to mention a much more common and lower-paid one? Aren't there better jobs available for people with his skills? I ask because I've always thought consulting (the non-flashy, non-exploitative kind) might be something to try after I have stable finances and ten or fifteen years of experience. I never thought people with heavy technical skills like that were going around building web sites.
Slashdot Mirror
By the way, the rhetorical trick of conflating criticism of one thing with praise of something else only works if your target is afraid of supporting the something else. I LIKE government. Ha. The same way I like people, corporations, and unleashed dogs I meet at the park.
Why would I disagree with that? If you put that on a piece of paper, 95% of the American electorate would sign it.Exactly
It sounds like you're talking about the thin client network computing paradigm that people have been pitching since... I'm not sure when, but at least the early nineties. That may or may not have been your intent, but regardless: the Air has absolutely nothing to do with network computing. The Air runs a full OS and has plenty of processing power. You won't have any trouble installing as much software as you want. It even has a decent amount of space for data. It doesn't cater to:
Frankly, there's nothing new about this way of working, except for people who are accustomed to carrying around hundreds of gigs of media files. The Air fully supports the way most people already live and work. At my current job, we all have a laptop, and most of us have a desktop, too. I've been there for nine months and haven't seen a single person use optical media, except for a few people who bring music CDs to work instead of ripping them to a player. We store email and working copies of files on our hard drives, and everything else on servers. Now that I think about it, none of us use wired ethernet for our laptops, either. (The only reason email is stored on our local disks is to encourage its deletion, for the standard corporate legal reasons.)
I admit that most of the people I work with would still call a laptop without an ethernet port or an optical media drive "useless", even though they never use them. Perception lags behind reality in this case. The Air is aimed at people who are in touch with the way they live and aren't scared of losing features they stopped using years ago.
Trust the server (to an appropriate extent). Trust the client, which is under your physical control. Trust the certification authorities. Trust your certs for the certification authorities. Trust secure protocols to tie everything together. All of those things can be reasonably accomplished, and voila, you have a reasonably secure system.
If I don't carry my own client (e.g., web browser) around with me, then I have to trust whatever client I pick up wherever I want want access: at my friend's house, the library, a coffeeshop, etc. What I would need is an implementation of security protocols running on my storage device. That way it could validate whatever client I plugged it into and flash a little green light signifying that the piece of hardware I picked up off the park bench is actually running approved software! What's that called again? Oh yeah, trusted computing. Good luck getting that to work with anything that doesn't have a corporate sponsor -- like the server in your closet, or your unlocked cell phone. If it ever works at all, that is.
Or you could just carry around a client and your own hardware, which is a much simpler and more secure scenario.
What a bizarre response. I suggest keeping a critical eye on corporations, and you think that means turning an uncritical eye toward the government? What kind of dangerous weirdo goes through life looking for a social organization worthy of their absolute trust?
I haven't even seen the movie you're talking about. I'm a liberal capitalist (that's what Americans call an "economic conservative," by the way, and has little to do with the American word "liberal") and I like corporations. I like people, too, but I won't buy a Rolex out of a briefcase. A sucker mentality doesn't benefit anyone except parasites.
The guy wants Apple to ship a working DTrace. Why should they? To regain community goodwill and get absolution from an official DTrace developer. He left the door open for that. That's the carrot. By publicizing statements on his blog and getting it submitted to Slashdot, he has proved how much trouble he can stir up. By understating the case, he reserves the threat of stating it plainly if they take no action. That's the stick. Now Apple has to weigh community goodwill against DRM dollars and decide whether to ship a working DTrace. Whereas, if he had immediately shoved the carrot up his ass and started flailing around with the stick, Apple would have shrugged their shoulders and moved on.
And some would argue that corporations are valuable economic engines that have built-in antisocial tendencies that can never be eradicated, but must be constantly monitored and kept in check. Corporations are powerful entities that resist those efforts, making it a struggle.
The struggle between "good" entities and "evil" ones is a mythical recasting of the everyday struggle between good and evil elements of every person. People are impure, institutions are impure. Corporations are a valuable kind of institution, which is why we have laws enabling their existence, yet it would be foolish to turn a blind eye to everything they do, or assume that whatever they want to do must be right in some way we don't understand.
Seriously, particular knowledge isn't bad. It isn't polluting. The fact remains that you can't get a decent CS education without hands-on work, and whatever tools you use for practical work will be "particular" tools. A certain level of technical competence is necessary to experience the relationship between theory and practice, and it should be designed into every CS curriculum.
Besides, the line between "particular" and "general" is impossible to draw. Using gdb to debug a C program on an embedded processor and using the Eclipse Java debugger to debug a Java GUI are remarkably similar. Set breakpoints, examine the stack, watch variables, skip the next 142 executions of this breakpoint, whoops! can't see much in code compiled without debugging info. A debugger may seem very particular, but debuggers are remarkably pervasive throughout programming and remarkably similar to each other. Using one compiler is similar to using the next. Doing code generation that targets one ISA will prepare you to do code generation that targets another ISA. Using one regular expression library is remarkably similar to using another.
All of these things may sound ridiculously banal, but building real systems is remarkably banal, even when you're building them to test exciting theories. You don't deal with the banal by struggling proudly and miserably through it, you deal with it by mastering it so thoroughly you never have to think about it again.
P.S. Try picking up a copy of the Chronicle of Higher Education sometime, and you'll see that American professors do quite a bit of arguing about the proper role of universities, and very few of them conform to your characterization of academics.
(P.P.S. Perhaps you wanted to specifically refer to a particular type of German institution? The English word "university" will not get your meaning across if you really mean Universität. A Fachhochschule is a university. But even if that's what you meant, there is no general agreement among academics, even German ones, that the German system is ideal.)
But in case elaboration is desired, you don't see Python programmers going around saying, "Here, look at this. I really didn't 'get' Python classes until I read this amazing article," and then a week later, "I think I understood classes for a while last week. It was pretty cool, but you'd have to be crazy to use that stuff unless you had a really nasty problem." The two models may be the same at some level, but Perl's was expressed so poorly that simply explaining it for mere mortals was considered a major achievement. I could teach Python's object system to any of my colleagues in an afternoon, using the morning to brush up on the technicalities and plan my presentation. If I could do that with Perl, I'd be some kind of Perl God (like Damien Conway). Given that the fatal flaw with Perl 5 OO was its obscurity, and the biggest asset of Python OO is its lucidity, that quote from Larry Wall is, like many other things he says, absolutely shameful unless interpreted in whatever special ironic context he said it in.
(The difference between Python lambda fakery and Perl object fakery epitomizes the difference between the two languages. Python falls back on simple, universally-understood language features to provide a somewhat clunky, verbose, yet clear solution; Perl falls back on language wizardry to provide an obscure but concise solution. In most cases Perl achieves a much better tradeoff than it did in the case of objects.)
Me too; I'm a professional software developer. I was just pointing out that the "Python is for experts" slogan you may have heard from Pythonistas is half ironic; it's about Python being usable by people who are *not* experts in software but who *are* experts in their own field, whatever that may be. (I don't know how well that works in practice, being surrounded by software experts myself.)Compare that to Perl5 OO. Perl5 OO is dog food, yet Perl 5 library authors consistently use it to define their library interfaces. All those libraries may toss the OO and rely on hashes of closures behind the scenes -- I haven't checked -- but library programmers evidently find it advisable not to share their elegant abstractions with users. Instead, they use objects, which (in Perl5) are wonky, bizarre, and understood by practically no one who isn't a Perl language guru. The fact that library authors define their interfaces in terms of constructs that few people understand seems like an admission that Perl has its own problems creating elegant abstractions.
Actually, the idea is that you can know enough about Python to work competently with Python code and still have enough brainspace left over to be an expert in something besides programming. Try THAT with Perl.... I mean, try that sometime when you're not ten times as smart as I amFor some code, the time required to read and understand it is inversely proportional to the time invested in writing it.
Plus, the rule of thumb only applies to the first working version of code. Allow me to illustrate with a rather extreme metaphor. Compare the effort required in understanding just the definitions and proofs in an undergraduate real analysis textbook (skipping the rest of the text) against the effort required to recreate the theory yourself. Reading just the definitions and proofs is a feasible way of learning undergraduate analysis (some people actually do it that way) because the theory has been refined over centuries into an elegant system.
As with mathematics, the more effort is invested into refining and refactoring code, the easier it becomes to understand. Every time I revisit a module to fix a bug or add a feature, I spend a few moments reorienting myself and often discover a way to clarify the code. "What was I thinking? Looking at this module after some time away from it, the structure of the code doesn't help me remember the logic at all. Hmmm, but if I ... then the logic becomes more evident." If you compare the first version of my code to the form it converges on, the first version has less functionality and would therefore be easier to rewrite from scratch, but the second version is easier to understand.
This has a science-fiction feel to it, though. Why do people consider this an important question? Surely it's just as silly as people getting all excited about their post-apocalyptic fantasies where they morph from average guys into civilization-rebuilding supermen? Just like the US and the USSR went to great lengths to avoid the Cold War going nuclear, a company is going to pay whatever is necessary to keep one guy around who knows the old code, or at least pay him to consult. The new programmers can call him on the phone and ask questions like, "I need to enhance the product to handle non-ASCII ISO-8859-1 characters. Is it a big job or a trivial one? What are the modules that probably need to be fixed?" and "It gets really slow when more than ten clients connect at the same time. Why would that be?" After he has explained his thinking on enough questions like that, the new programmers will have absorbed enough of his understanding that it won't be legacy code any longer.
If a company is stupid enough to keep off handing big, valuable codebases to new teams without guaranteeing access to previous developers, then a better question for their developers is, "What's the job market like?"
I think Martin Fowler (and everybody else with a lick of sense) actually agrees with you. As I understand it, the XP objection to writing comments has been overblown by a few XP proponents and a horde of XP detractors; what you find in the mainstream XP writings is a twofold argument that writing comments should not be the first response to unclear code:
Clarify your code before resorting to comments. If a section of code is complicated enough to need comments, it was probably written suboptimally the first time through, when the programmer's understanding is incomplete. If you write comments before cleaning up the code, the comments end up being an apology for a convoluted first-stab implementation. This (as I understand it) is Fowler's main complaint about lengthy code comments: they're a bad code smell in themselves and often indicate poorly organized code that should be scrapped, not documented. A quick rewrite with the benefit of hindsight will greatly improve the code clarity, perhaps eliminating the need for comments. Unfortunately, this bit of advice pisses programmers off because it assumes that they don't clean up code as they go along. Some programmers do so instinctively, and the rest are fed up with being told to.
Why write a comment when you can express it as a test and kill two birds with one stone? This tends to piss people off because it assumes, as many other part of XP do, that the programming group is following XP wholeheartedly. That means that every programmer who works on a piece of code is familiar with all the tests for that code and will refer to them when he needs information about the code. This is actually a very uncommon way of working, so the advice that depends on it is useless to most programmer. In the context of a full commitment to extreme programming, though, the advice makes perfect sense.
After applying these two principles (and ignoring the second if it doesn't apply,) I think XPers are happy to add whatever comments are useful. There are some XPers who take the "comments are bad" principle and make it EXTREME!!!!!!! (insert image of snowboarding Mountain Dew drinker, which dates XP pretty accurately,) and eXtreme Programming is an unfortunate name that positively *invites* confusions like these, where the most extreme statements made by any self-proclaimed XPer are taken to be the true XP way. The strict "no comments" rule is a minority viewpoint and not one advocated (AFAIK) by the originators of XP and the most common XP resources (the Extreme Programming Explained series, extremeprogramming.org, etc.)
Anyway, I imagine a 419 scammer would use exactly the same tools as a small e-commerce site: CRM, mailing lists, maybe some basic filtering to do triage on incoming email. The only difference is that they would populate their mailing lists by buying email addresses in bulk instead of asking customers to opt in. Well, plus they need a program to convert everything they type into all caps. So I agree that no one should write a program like that :-)
I'm not even sure that 419 scamming is really such a bad thing considering the context. At least the kids doing it aren't fighting in rebel armies or eking out a premodern living somehow. Eventually the economy will have to grow and modernize, and when that time comes, investors will probably be wishing there were more people with basic computer literacy, i.e., more people who worked on 419 scams instead of making an honest living in factories or on farms.
But why does he persist in web consulting if that's where those types are? He could be working with saner people in an area less rife with hype. It's not like he's doing it for the money... is it? If he's doing it just because the web is the trendy place to be, then he's using the same heuristic the fakers use, which is a bad mistake if he can't tolerate working with them.
Sugar and Hildon are both small, simple desktops based on GTK, so hopefully it will turn out to be no great effort to adapt Hildon programs for Sugar and vice-versa. Let's face it, we do a much better job at developing applications that we use ourselves. How can I develop an application for children? I've mostly ignored them since I was one myself, and if conventional wisdom is correct, adults are doomed to underestimate them, even when we are forewarned of this danger. But I know what I like -- simple study tools and educational games are fun to play on public transit and other dead time, or just ostentatiously improving oneself in a big comfy chair at the local coffeehouse. If they can also be used by children on the OLPC, well, that's a hell of a warm fuzzy, and a good line to use on chicks. (Can it be... a massive convergence of the interests of narcissistic hipgeeks and developing-world children? Count me IN!)