I find myself asking quite often, "why is Python specifically a Perl rival and visa versa?" In other words, why do the two sets of language advocates spend so much time talking to each other in heated tones?
Because they have completely opposite philosophies, but are often competing for very similar application domains. People think of Perl as the language for handy little quick-and-dirty scripts, but personally, I reach for Python and don't find it to be at all inferior. What really makes both of these languages effective for this purpose is the rich set of freely-available library modules that each has.
Don't take this to mean that I think Python is only appropriate for quick-and-dirty stuff, though - I've found that the process of transforming one of my quick Python hacks into a more powerful generalized tool goes quite smoothly...
hmm...Stolen from MacOS, not innovated by Windows. Also, everyone expects Drag and Drop to just work (another MacOS innovation). Sounds like what you all really want is what OS X promises to be. Just hope Apple delivers it on time...
Oh, I don't claim that MS's system is their innovation. Merely that they got it roughly right, and that their system (unlike comparable systems on unix) is ubiquitous enough that programmers actually bother to use it.
What we need to overcome those limitations are well-thought-out and documented ways of handling structured data. A *nix version of Visio, for instance, could spew all the information you need about the diagram as a text stream and, as long as the format and structure of that stream are documented, you would have all the functionality that OLE provides.
Sure. But for that to work, I have to write code that parses whatever data format Visio provides. With OLE, I just made some function calls to get the information I needed. Why make Visio to 'compile' the data structures representing drawing down to some stream of bytes, and make me write code to rebuild my own version of the structure from that stream, when (with the right API), I can just talk to Visio and query the structure it's storing internally?
Of course, Visio could provide a library that I could link to for parsing its output. But why do it that way, when the component model offered by Windows is powerful enough to do what I needed in the case I described, and also allows applications to do useful stuff like embedding and displaying arbitrary objects from other applications?
While your comparison is very nice, it's quite moot. Comparing X to Windows is akin to comparing VNC to Windows. X is a remote display protocol and that's about it. Yes, cut-and-paste and drag-and-drop were added for no real reason, but if you ignore that, all it is is a protocol to display graphics across a network.
The fact that this is all it is is precisely the problem with it. Or rather, it's precisely the problem with the unix community's failure to develop anything higher-level on top of it.
The problem with *NIX (and he really doesn't mean *NIX - there's quite enough shared code in a console-only system, the problem is with the X apps he named) is that X windows is just an overgrown framebuffer, not an actual graphics and development kit. If you look at something like BeOS, it provides a whole bunch of "servers" (a microkernel design) that handle different functions, but X windows was an overgrown framebuffer stuck on top of a command line to provide a clock, a load monitor, and a terminal.
True. When I read this:
The Unix approach of not deciding policy is "a defense system for hackers," since that way nobody has to take responsibility for a bad decision.
I couldn't help but think of X. The lousiness of that system is the best example of the problems that come when you avoid policy decisions. And the awful arguments made in X's favor whenever the topic of its suckiness comes up in Slashdot are certainly consistent with the idea that this avoidance of policy decisions is a 'hacker defense system'.
Probably the best example of what Miguel is talking about is the difference between what you can do with cut-and-paste in X and what you can do with cut-and-paste in Windows:
X has more or less followed the Unix paradigm where 'everything is a file' - which really means that everything is a flat, unstructured lump of text. Or at least, this the only way that most programs have to interface with external data. This is fine when the data you're dealing with is relatively unstructured: A csv file is tolerable for, say, a list of phone numbers, and simple text oriented tools like sed/awk/grep/perl are okay for most of the operations you'll want to do on such a file.
But once you move to a graphical environment and thus aquire the ability to effectively represent much more structured data to the user, you need to provide higher-level interfaces to that data. Those text-oriented tools will be pretty much worthless if the file you're dealing with contains a description of a structured drawing. As a result of X's adoption of the Unix approach, all you can really cut-and-paste in X is (surprise!) flat, unstructures text strings.
In Windows, on the other hand, you can cut much more structured data to the clipboard. You can rip out a piece of a Visio drawing and stick it into Word, and it will retain all of its structure. This is because Windows provides facilities that make it relatively easy for programs to expose higher-level interfaces to the data they generate. This permits a degree of application interoperability that X apps can only dream of.
This pays dividends far beyond cutting and pasting: strong application interoperability means that you can easily access and 'reuse' an existing application's functionality. An example out of my own experiences as a Windows developer, a few years back: I once spent a month working on a project whose goal was to build a graphical scripting tool for a specialized purpose: Users would draw out simple flowcharts, then our tool would generate code from these flowcharts. Rather than build our own flowchart-drawing tool, we were able to use Visio: We designed a set of custom Visio shapes that users could use to draw flowcharts. Then, the development environment we'd built would send users into Visio whenever they wanted to edit charts. When the user was done editing, the development environment would talk to Visio via OLE automation, pull out a highly structured description about the flowchart (basically, a list of all the symbols and their types (including some parameters that the user could specify, such as the conditional expression for a decision symbol), and of the links between symbols) and build a simple C++ representation of the chart that the code generator could then take as input. My job on the project was to build the layer that talked to Visio and built the code generator's input data structure, so I dealt pretty heavily with OLE. It worked out great for us, saving us an enormous amount of development time. And we ended up with a much higher-quality final product - instead of building our own mediocre tool for graphically editing flowcharts (which we would have probably ended up having to do if we were working in unix/w X), we were able to provide the user with the much more powerful, mature facilities of Visio.
I liked Miguel's comments. I'm glad to see that someone is willing to stand up and say that while the emperor may not be completely naked, he should probably put on some pants...
..once again realizing it not what's in the box that matters, but the box itself.
There's a lot more to the cube than just a cool-looking box:
Small size: How many people actually make use of all the space in their cases? Damned few.
Easy connection: The integrated power/signal cable(s?) cut down on the rats nest of wiring that most computers require.
Fanless. I.e. quiet.
None of these are directly related to what's "inside" the box (since by inside you're probably referring to speed and capacity of various components), but all have a significant impact on user experience.
It comes down to $$$ in the end, like most things. Spiders don't click on adverts. People, while they may not always shop or whatever, DO see these adverts. If a site cannot say that on all the pageviews it gets that they aren't actual PEOPLE staring at their ads then that site may well lose ad revenue.
The problem isn't that the hits generated by the spider don't count as 'real' hits. These can be filtered out, and even if they couldn't, they're going to be a tiny percentage of hits on any site that gets enough traffic to make any money from advertising.
The real problem from the ad-space seller's point of view is that when you use a search engine, you view fewer pages at the target site: You search at the engine, then jump straight to the page of interest at the target site, for one page view. But if you go straight to the target site, you generate one page view for the front page, maybe a view for the search form page (if there's no form on the front page), one or more for the search results page(s), and one for your final destination - a total of at least 3 page views, and potentially more.
So what's the big deal? If online shop A refused to let shop-bot B see its prices, then A's products will simply not be listed on site B. People who go there for price comparisons will never choose to buy from A since it won't even be listed. Who's the loser here?
Think long term, from eBay's perspective. Right now, they're the best known internet auction site, by a wide margin. If someone wants to buy or sell via an auction mechanism, there's a good chance they'll go to eBay.
But what happens if comparison sites like Bidder's Edge become popular? Then people go to Bidder's Edge first when they're looking to buy something, dramatically increasing the likelihood that they'll end up somewhere other than eBay - on a comparison shopping site, eBay won't stand out nearly so much as it does in, say, popular media. So yeah, while having their auctions listed on Bidder's Edge may provide eBay with some short-term benefit, in the long term, it diminishes the value of eBay's name recognition.
So what eBay wants to do is to kill sites like Bidder's Edge before they get off the ground. How to do that? By keeping their own listings out of Bidder's Edge. Since eBay is by far the biggest and best-known online auction house, being unable to list eBay acutions dramatically decreases the usefulness of Bidder's Edge. So people won't go there, and the site never develops a following.
You can achieve the same in C++/Java by creating a point class.
I'm well aware of that - I've done exactly what I described in C++. My point wasn't about ML (or any other functional language) vs. imperative languages, but rather, strong typing (which C++ has) vs. weak.
But in either case, creating the (x,y) pair as (y,x) is still possible. I don't see how a language can guarantee to stop all errors. It doesn't know what you are trying to achieve. If what you were trying to do was flip the graphic by reversing x and y, then the language won't know that, and won't flag up an error if you fail to do this in you function.
That's funny. I don't see where I or anyone else claimed that a language would 'stop all errors'. A technique need not stop all errors to be worthwhile. The fact that perfection is impossible is no excuse not to seek improvements.
As for your example of reversing x & y in the parameters to the point constructor: Good point, but if you've spent enough time dealing with geometry, the (x, y, z) ordering of coordinates is instinctive, and thus you're far less likely to make this mistake than to confuse (x, y, width, height) with (x, width, y, height). And if you want to 'transpose' a graphic (which is what reversing x & y would do), well, why not encapsulate that functionality into a method on your graphic class? That way you only have to get it right once, then never think about it again.
This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers.
Actually, this is a perfect example of why the first stages of developing a piece of software should be to think about the types of data you're going to be handling, and building low-level code for manipulating these pieces of data in a convenient fashion that maps well to the way you think about them. In the above example, it sounds like you're doing 2-D graphics. That being the case, one of your first steps should have been to define a 'point' data type, which stores an (x, y) pair, build constructors and accessors for this type. Then, your rect procedure would take two points (or a point and a vector (which might have the same internal representation, but are conceptually different, and thus given distinct types)) rather than 4 integers, and the particular error you're describing becomes impossible.
We've got better development languages now, no language will probably be much better than C at protable assembly, and above all:
"There is no silver bullet." - Fred Brooks
I think Brooks is probably a bit depressed at the nonsense that intellectually lazy people justify by quoting him out of context. Have you read "No Silver Bullet" recently? Do you remember what he really meant, in the line you quoted above? What he was saying in his essay was that there was no single technology that would lead to an order of magnitude improvement in programmer productivity. He sure as hell wasn't saying that better languages couldn't improve productivity. A language that doubled productivity wouldn't be a "silver bullet", by his definition. But so what? Doubling productivity is still an enormous improvement.
The irony is just too wonderful..people on a site like this bouncing off the ceiling cause they couldn't filter out a writer they don't like.
There's no irony here. Just as my right to swing my fist ends at your nose, your right to free speech does not imply a requirement that anyone listen to you. While plenty of people here advocate free speech, nobody advocates coercing someone into listening to crap they aren't interested in.
However, that does not mean we should give up trying to innovate at the "lower levels." What if car manufacturers quit making better engines and only focused on making more comfortable seats and installing better stereos?
You're basically putting words into his mouth. Of course there's room for making improvements at the low levels. But there's little or no value in having most computer scientists and programmers focus on those sorts of improvements. Ask yourself this:
How many jobs does the world have for engineers who design automobiles?
Emulation can get better than the real thing. I can recall an article on slashdot not that long ago which talked about running an omptimizing alpha emulator on an alpha machine. Because of the nature of the optimizing it was faster. I forget what the project was called...
Actually, I think it was an HP project, called Dynamo. There's been at least one Slashdot article about it.
Re:I used to bookmark the "critical" decision poin
on
Movies Online?
·
· Score: 1
I basically kept a 'stack' of bookmarks, to make it easier to backtrack - if I came to a bad end, I'd just pop the last bookmark off the stack, and try the other fork. Thanks to those books, I knew how to traverse a tree data structure before I even knew how to program.
If I remember correctly, Transmeta used a highly optimised (read: streamlined) 128-BIT CORE. That's double 64 bits last time I checked.
You remember sorta correctly. A Crusoe instruction word is 128 bits. This does not make it a 128 bit processor. Each of those 128 bit instruction words contains four seperate 32 bit instructions. Crusoe's integers and memory addresses are still 32 bits. Thus, Crusoe is really more like four 32 bit processors running in parallel.
Can anyone tell me what it's really supposed to do. "Enterprise Resource Planning" isn't very descriptive. What do you do, type in the number of employees you have and it calculates how many sodas to buy for the company picnic? (sodas, ERP, get it?)
In essence, ERP software is used to store and manipulate all the administrative data a company has to deal with - timeclock data, payroll, HR information (job titles, insurance, dependants, etc.), inventory management, org charts. Tons of stuff, really.
There's nothing special about the idea of using software to deal with these things. But what's interesting about ERP software packages is that they attempt to be nearly off-the-shelf solutions for problems that previously involved a lot of custom software. I say 'nearly' because the process of getting a company to use SAP (to pick the software I spent a year working with) still involves a lot of customization. But with SAP, that customization typically involves a lot more cut-and-dried configuration, and a lot less programming. The idea is that the $10 million, 20-person SAP implementation will be a lot cheaper than building a custom system from the ground up.
I'm not sure that this approach lives up to the hype. In practice, a great deal of effort has to go into documenting requirements, regardless of whether you're using off-the-shelf software or custom stuff. And working out how to configure SAP to meet those requirements isn't a whole lot easier than designing custom software - sure, the requirements map nicely to SAP's built-in code and data models much of the time, but you almost always find yourself dealing with requirements that SAP can't handle nicely, and end up resorting to messy hacks to make things sorta-work.
In the end, I'm not convinced that you come out ahead in terms of bang/buck when you use a package like this.
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
Which does lead me to a question for you C++ gurus. Is calling a method the same as calling a C funtion in terms of the call/return processing? If so, then 11223may have a point regarding efficiency (read bloat). A lot of the class methods I have seen so far are itty-bitty.
Yes, C++ method invocation uses the same mechanism as a C function call.
This does not necessarily lead to slower code, depending on the compiler. Most decent optimizing compilers can transform calls to itty-bitty functions into inline code. C++ has a keyword you can use to declare a function or method inline. I don't think the compiler is required to honor it, though.
The point is, that it's a robot taking over in an area, where human expertise was thought to be prevalent.
Not really. Most chain fast-food stores reduced cooking to a robotic series of actions long ago. This robot wouldn't have a place in a diner or anyplace where it's acknowledged that the customer and the people behind the counter are humans with human idiosyncracies.
What strange to me is how programming is looked at as an end in itself and not a medium for creation. I would have expected raves about implementing great ideas.
You've got a good point here, but I suspect that many good writers are as interested in an excuse to play with language as in telling any particular story. And I'm guessing that most artists tend to enjoy the media in which they work at a very low, physical level, and actually draw inspiration from that enjoyment.
On more than one occasion, while noodling around with and learning a new tool, ostensibly 'for its own sake', I've found the stuff I was working on starting to take a useful form. I take it further in that direction, and end up with a polished, useful piece of software.
In my experience (not an empirical study by any means) individuals without degrees tend to be unaware of what the don't know.
I think there's a good bit of truth to this. About the time I entering my sophmore year in a CS degree program, I was starting to get cocky, and to think that there wasn't much in the programming world left that could surprise me. Then I took a course in functional programming (for context, let me mention that the languages I knew at the time were C, Pascal, and QuickBasic), which basically turned my head inside out, and made me realize how much there was that I was ignorant of.
On the other hand though, a lot of the stuff that self-taught people are likely to be unaware of just isn't used so much in the real world. It happens I'm actually using the skills I aquired in that functional programming course in my current job, but that's something of a fluke - most people will never find a real need to move out of the imperative paradigm.
Your average 13 year old napster user isn't going to drive out and buy a cd when he can get the entire contents for free with a few clicks.
Your average 13 year old Napster user is likely stuck with a 56K modem, far too slow to effectively download much in any reasonable amount of time. And aside from that, he doesn't have the discretionary income to buy the CDs, anyways.
When it comes to the record company's primary concern (profit), there's just one question to be answered: Does using Napster / gnutella / whatever cause people to spend less money than they would have without it?
I'll let you guess my answer to that question from this tidbit: Last week week I downloaded gnutella and started using it (I've never used Napster). The next day I went out, went to 3 different music stores and spent a total of $70 on CDs. This was the first time in at least 6 months I've spent any money on music.
Of course, you can argue that it doesn't matter how I or anyone else behave when we have these tools available: It's morally wrong to 'steal' intellectual property, you'll say. But the wording of the US Constitution on this matter makes it clear that IP law exists for practical, not moral reasons: "to promote progress in the useful arts", not "to protect an author's natural right to control distribution of his writings", or somesuch. Therefore, the fact that I spend more money after aquiring gnutella means that enforcing copyright law in this case would have in fact contradicted the spirit and intent of that law.
Or at least, the spirit and intent of the original copyright laws. The spirit and intent of the DMCA is to put as much power as possible into Disney/Sony/TW/et al's hands.
You're saying that you get moderated down a lot on slashdot by 'calling bluffs', and implying that the moderators are hiding a lot of truths from themselves and can't bear to have those truths pointed out to them.
But wait, look: You posted this with a +1 bonus. If you get moderated down so much for 'telling the truth', how did you aquire enough karma to post with that bonus?
So basically, your complaints about getting moderated down are just a bunch of petulant, disingenuous whining.
You're right, Meyer's article would get moderated down a great deal if posted as a comment here. Some of that moderation might be due to the fact that he's saying things many people here would disagree with. But most of it would be because the article is basically garbage. A big chunk of his argument boils down to "ESR likes guns, and RMS is rude to people who disagree with him, therefore open source software is unethical."
And on those relatively rare occasions when you do get moderated down, the reasons are usually similar - sometimes its because you challenge dogma, but mostly its because you've done a poor job of making any point. To claim otherwise is incredibly self-aggrandizing.
Slashdot Mirror
Because they have completely opposite philosophies, but are often competing for very similar application domains. People think of Perl as the language for handy little quick-and-dirty scripts, but personally, I reach for Python and don't find it to be at all inferior. What really makes both of these languages effective for this purpose is the rich set of freely-available library modules that each has.
Don't take this to mean that I think Python is only appropriate for quick-and-dirty stuff, though - I've found that the process of transforming one of my quick Python hacks into a more powerful generalized tool goes quite smoothly...
Oh, I don't claim that MS's system is their innovation. Merely that they got it roughly right, and that their system (unlike comparable systems on unix) is ubiquitous enough that programmers actually bother to use it.
And I am pinning a lot of hope on MacOS X.
What we need to overcome those limitations are well-thought-out and documented ways of handling structured data. A *nix version of Visio, for instance, could spew all the information you need about the diagram as a text stream and, as long as the format and structure of that stream are documented, you would have all the functionality that OLE provides.
Sure. But for that to work, I have to write code that parses whatever data format Visio provides. With OLE, I just made some function calls to get the information I needed. Why make Visio to 'compile' the data structures representing drawing down to some stream of bytes, and make me write code to rebuild my own version of the structure from that stream, when (with the right API), I can just talk to Visio and query the structure it's storing internally?
Of course, Visio could provide a library that I could link to for parsing its output. But why do it that way, when the component model offered by Windows is powerful enough to do what I needed in the case I described, and also allows applications to do useful stuff like embedding and displaying arbitrary objects from other applications?
The fact that this is all it is is precisely the problem with it. Or rather, it's precisely the problem with the unix community's failure to develop anything higher-level on top of it.
True. When I read this:
I couldn't help but think of X. The lousiness of that system is the best example of the problems that come when you avoid policy decisions. And the awful arguments made in X's favor whenever the topic of its suckiness comes up in Slashdot are certainly consistent with the idea that this avoidance of policy decisions is a 'hacker defense system'.Probably the best example of what Miguel is talking about is the difference between what you can do with cut-and-paste in X and what you can do with cut-and-paste in Windows:
But once you move to a graphical environment and thus aquire the ability to effectively represent much more structured data to the user, you need to provide higher-level interfaces to that data. Those text-oriented tools will be pretty much worthless if the file you're dealing with contains a description of a structured drawing. As a result of X's adoption of the Unix approach, all you can really cut-and-paste in X is (surprise!) flat, unstructures text strings.
This pays dividends far beyond cutting and pasting: strong application interoperability means that you can easily access and 'reuse' an existing application's functionality. An example out of my own experiences as a Windows developer, a few years back: I once spent a month working on a project whose goal was to build a graphical scripting tool for a specialized purpose: Users would draw out simple flowcharts, then our tool would generate code from these flowcharts. Rather than build our own flowchart-drawing tool, we were able to use Visio: We designed a set of custom Visio shapes that users could use to draw flowcharts. Then, the development environment we'd built would send users into Visio whenever they wanted to edit charts. When the user was done editing, the development environment would talk to Visio via OLE automation, pull out a highly structured description about the flowchart (basically, a list of all the symbols and their types (including some parameters that the user could specify, such as the conditional expression for a decision symbol), and of the links between symbols) and build a simple C++ representation of the chart that the code generator could then take as input. My job on the project was to build the layer that talked to Visio and built the code generator's input data structure, so I dealt pretty heavily with OLE. It worked out great for us, saving us an enormous amount of development time. And we ended up with a much higher-quality final product - instead of building our own mediocre tool for graphically editing flowcharts (which we would have probably ended up having to do if we were working in unix
I liked Miguel's comments. I'm glad to see that someone is willing to stand up and say that while the emperor may not be completely naked, he should probably put on some pants...
There's a lot more to the cube than just a cool-looking box:
None of these are directly related to what's "inside" the box (since by inside you're probably referring to speed and capacity of various components), but all have a significant impact on user experience.
The problem isn't that the hits generated by the spider don't count as 'real' hits. These can be filtered out, and even if they couldn't, they're going to be a tiny percentage of hits on any site that gets enough traffic to make any money from advertising.
The real problem from the ad-space seller's point of view is that when you use a search engine, you view fewer pages at the target site: You search at the engine, then jump straight to the page of interest at the target site, for one page view. But if you go straight to the target site, you generate one page view for the front page, maybe a view for the search form page (if there's no form on the front page), one or more for the search results page(s), and one for your final destination - a total of at least 3 page views, and potentially more.
Think long term, from eBay's perspective. Right now, they're the best known internet auction site, by a wide margin. If someone wants to buy or sell via an auction mechanism, there's a good chance they'll go to eBay.
But what happens if comparison sites like Bidder's Edge become popular? Then people go to Bidder's Edge first when they're looking to buy something, dramatically increasing the likelihood that they'll end up somewhere other than eBay - on a comparison shopping site, eBay won't stand out nearly so much as it does in, say, popular media. So yeah, while having their auctions listed on Bidder's Edge may provide eBay with some short-term benefit, in the long term, it diminishes the value of eBay's name recognition.
So what eBay wants to do is to kill sites like Bidder's Edge before they get off the ground. How to do that? By keeping their own listings out of Bidder's Edge. Since eBay is by far the biggest and best-known online auction house, being unable to list eBay acutions dramatically decreases the usefulness of Bidder's Edge. So people won't go there, and the site never develops a following.
I'm well aware of that - I've done exactly what I described in C++. My point wasn't about ML (or any other functional language) vs. imperative languages, but rather, strong typing (which C++ has) vs. weak.
But in either case, creating the (x,y) pair as (y,x) is still possible. I don't see how a language can guarantee to stop all errors. It doesn't know what you are trying to achieve. If what you were trying to do was flip the graphic by reversing x and y, then the language won't know that, and won't flag up an error if you fail to do this in you function.
That's funny. I don't see where I or anyone else claimed that a language would 'stop all errors'. A technique need not stop all errors to be worthwhile. The fact that perfection is impossible is no excuse not to seek improvements.
As for your example of reversing x & y in the parameters to the point constructor: Good point, but if you've spent enough time dealing with geometry, the (x, y, z) ordering of coordinates is instinctive, and thus you're far less likely to make this mistake than to confuse (x, y, width, height) with (x, width, y, height). And if you want to 'transpose' a graphic (which is what reversing x & y would do), well, why not encapsulate that functionality into a method on your graphic class? That way you only have to get it right once, then never think about it again.
Better nobody's wife and children. Which is far more likely if both families are driving a reasonable passenger car than if both are driving SUVs.
Bullets are made of lead, but they're commonly jacketed in steel. Which is most certainly subject to magnetic fields.
Actually, this is a perfect example of why the first stages of developing a piece of software should be to think about the types of data you're going to be handling, and building low-level code for manipulating these pieces of data in a convenient fashion that maps well to the way you think about them. In the above example, it sounds like you're doing 2-D graphics. That being the case, one of your first steps should have been to define a 'point' data type, which stores an (x, y) pair, build constructors and accessors for this type. Then, your rect procedure would take two points (or a point and a vector (which might have the same internal representation, but are conceptually different, and thus given distinct types)) rather than 4 integers, and the particular error you're describing becomes impossible.
We've got better development languages now, no language will probably be much better than C at protable assembly, and above all:
"There is no silver bullet." - Fred Brooks
I think Brooks is probably a bit depressed at the nonsense that intellectually lazy people justify by quoting him out of context. Have you read "No Silver Bullet" recently? Do you remember what he really meant, in the line you quoted above? What he was saying in his essay was that there was no single technology that would lead to an order of magnitude improvement in programmer productivity. He sure as hell wasn't saying that better languages couldn't improve productivity. A language that doubled productivity wouldn't be a "silver bullet", by his definition. But so what? Doubling productivity is still an enormous improvement.
There's no irony here. Just as my right to swing my fist ends at your nose, your right to free speech does not imply a requirement that anyone listen to you. While plenty of people here advocate free speech, nobody advocates coercing someone into listening to crap they aren't interested in.
You're basically putting words into his mouth. Of course there's room for making improvements at the low levels. But there's little or no value in having most computer scientists and programmers focus on those sorts of improvements. Ask yourself this:
How many jobs does the world have for engineers who design automobiles?
And how many for mechanics who repair them?
Emulation can get better than the real thing. I can recall an article on slashdot not that long ago which talked about running an omptimizing alpha emulator on an alpha machine. Because of the nature of the optimizing it was faster. I forget what the project was called...
Actually, I think it was an HP project, called Dynamo. There's been at least one Slashdot article about it.
I basically kept a 'stack' of bookmarks, to make it easier to backtrack - if I came to a bad end, I'd just pop the last bookmark off the stack, and try the other fork. Thanks to those books, I knew how to traverse a tree data structure before I even knew how to program.
You remember sorta correctly. A Crusoe instruction word is 128 bits. This does not make it a 128 bit processor. Each of those 128 bit instruction words contains four seperate 32 bit instructions. Crusoe's integers and memory addresses are still 32 bits. Thus, Crusoe is really more like four 32 bit processors running in parallel.
In essence, ERP software is used to store and manipulate all the administrative data a company has to deal with - timeclock data, payroll, HR information (job titles, insurance, dependants, etc.), inventory management, org charts. Tons of stuff, really.
There's nothing special about the idea of using software to deal with these things. But what's interesting about ERP software packages is that they attempt to be nearly off-the-shelf solutions for problems that previously involved a lot of custom software. I say 'nearly' because the process of getting a company to use SAP (to pick the software I spent a year working with) still involves a lot of customization. But with SAP, that customization typically involves a lot more cut-and-dried configuration, and a lot less programming. The idea is that the $10 million, 20-person SAP implementation will be a lot cheaper than building a custom system from the ground up.
I'm not sure that this approach lives up to the hype. In practice, a great deal of effort has to go into documenting requirements, regardless of whether you're using off-the-shelf software or custom stuff. And working out how to configure SAP to meet those requirements isn't a whole lot easier than designing custom software - sure, the requirements map nicely to SAP's built-in code and data models much of the time, but you almost always find yourself dealing with requirements that SAP can't handle nicely, and end up resorting to messy hacks to make things sorta-work.
In the end, I'm not convinced that you come out ahead in terms of bang/buck when you use a package like this.
Yes, C++ method invocation uses the same mechanism as a C function call.
This does not necessarily lead to slower code, depending on the compiler. Most decent optimizing compilers can transform calls to itty-bitty functions into inline code. C++ has a keyword you can use to declare a function or method inline. I don't think the compiler is required to honor it, though.
Not really. Most chain fast-food stores reduced cooking to a robotic series of actions long ago. This robot wouldn't have a place in a diner or anyplace where it's acknowledged that the customer and the people behind the counter are humans with human idiosyncracies.
You've got a good point here, but I suspect that many good writers are as interested in an excuse to play with language as in telling any particular story. And I'm guessing that most artists tend to enjoy the media in which they work at a very low, physical level, and actually draw inspiration from that enjoyment.
On more than one occasion, while noodling around with and learning a new tool, ostensibly 'for its own sake', I've found the stuff I was working on starting to take a useful form. I take it further in that direction, and end up with a polished, useful piece of software.
I think there's a good bit of truth to this. About the time I entering my sophmore year in a CS degree program, I was starting to get cocky, and to think that there wasn't much in the programming world left that could surprise me. Then I took a course in functional programming (for context, let me mention that the languages I knew at the time were C, Pascal, and QuickBasic), which basically turned my head inside out, and made me realize how much there was that I was ignorant of.
On the other hand though, a lot of the stuff that self-taught people are likely to be unaware of just isn't used so much in the real world. It happens I'm actually using the skills I aquired in that functional programming course in my current job, but that's something of a fluke - most people will never find a real need to move out of the imperative paradigm.
Your average 13 year old Napster user is likely stuck with a 56K modem, far too slow to effectively download much in any reasonable amount of time. And aside from that, he doesn't have the discretionary income to buy the CDs, anyways.
When it comes to the record company's primary concern (profit), there's just one question to be answered: Does using Napster / gnutella / whatever cause people to spend less money than they would have without it?
I'll let you guess my answer to that question from this tidbit: Last week week I downloaded gnutella and started using it (I've never used Napster). The next day I went out, went to 3 different music stores and spent a total of $70 on CDs. This was the first time in at least 6 months I've spent any money on music.
Of course, you can argue that it doesn't matter how I or anyone else behave when we have these tools available: It's morally wrong to 'steal' intellectual property, you'll say. But the wording of the US Constitution on this matter makes it clear that IP law exists for practical, not moral reasons: "to promote progress in the useful arts", not "to protect an author's natural right to control distribution of his writings", or somesuch. Therefore, the fact that I spend more money after aquiring gnutella means that enforcing copyright law in this case would have in fact contradicted the spirit and intent of that law.
Or at least, the spirit and intent of the original copyright laws. The spirit and intent of the DMCA is to put as much power as possible into Disney/Sony/TW/et al's hands.
This is incredibly ironic.
You're saying that you get moderated down a lot on slashdot by 'calling bluffs', and implying that the moderators are hiding a lot of truths from themselves and can't bear to have those truths pointed out to them.
But wait, look: You posted this with a +1 bonus. If you get moderated down so much for 'telling the truth', how did you aquire enough karma to post with that bonus?
So basically, your complaints about getting moderated down are just a bunch of petulant, disingenuous whining.
You're right, Meyer's article would get moderated down a great deal if posted as a comment here. Some of that moderation might be due to the fact that he's saying things many people here would disagree with. But most of it would be because the article is basically garbage. A big chunk of his argument boils down to "ESR likes guns, and RMS is rude to people who disagree with him, therefore open source software is unethical."
And on those relatively rare occasions when you do get moderated down, the reasons are usually similar - sometimes its because you challenge dogma, but mostly its because you've done a poor job of making any point. To claim otherwise is incredibly self-aggrandizing.