I am quite faimilar with axiomatic set theory and foundations of mathematics. The point remains that in terms of arithmetic of numeric symbols that is largely an issue of definitions (how do we define a number, how do we define addition of numbers, how do we define equality of numbers) and following the (not inconsiderable) groundwork of defintions (and there are actually a few ways to approach this - there are at least two different set theoretic defintions on natural numbers, you can approach it simply with Peano axioms, or you could comne in via a category theoretic approach) the explanation of why 1+1=2 follows very efficiently and almost directly from the definitions.
Intelligent Design seems to operate on the oz theory that since we can't see behind the curtain we should take what we see in front of the curtain on face value...We find something we don't understand, somebody attributes it to the divine intervention, then we figure it out.
It goes further than that. Intelligent design relies on linguistic "sleight of hand" and distraction in the very construction of their arguments. It is akin, in many ways, to the various "logical proofs of the existence of God" - it's all about slipping some subtle hidden assumptions into your definitions while railing on about a set of largely indisputable axioms to distract from this slieght of hand.
For Intelligent Design so much hangs on definitions or, more importantly, the lack thereof. Proponents spend a lot of time pounding the table and making arguments, but here are a few terms they use that are really never properly defined: "Intelligent", "Irreducible", "Design", "Complexity". You'll note that almost all their arguments hinge on vague, implicit, and imprecise definitions of these terms. There is much effort spent of verbal distraction to make sure you never really notice that, for instance, complexity is not really defined or measurable, or that intelligence is impossible to clearly delineate from unintilligent in any meaningful way. What does designed even mean in the manner it is used by ID proponents? How do we measure the degree of design?
Fisher's Deduction: The more issues a person shoehorns down into an artificial liberal/conservative dichotomy, the more certain you can be that the person is an American.
In math, explaining why "1 + 1 = 2" is a very long process too (and not trivial)
Actually, generally, once you've defined what you mean by each of those symbols explaining why "1 + 1 = 2" is quite short and trivial (amounting to "by definition"). Explaining why the arithmetic thus constructed from your definitions is consistently applicable to the physical world... now that's a little harder.
Jedidiah.
Re:The hypocrisy of "sustainable"
on
Chinese Eco-Cities
·
· Score: 2, Insightful
Sure there's a lot of pretentious people who talk about environmental issues or sustainability to be trendy and don't know what they're talking about. Pick any subject and you can find such people. Sustainability does make a certain amount of sense, and just because there are some people who promote a rather hollow shell version of the concept doesn't mean there isn't a real concept with ood sense and reasoning behind it.
Anything "sustainable" (or "organic") is guaranteed to be expensive.
And that is usually the case for one of two reasons:
(1) To get a better profit margin selling mostly the same stuff to pretentious gits, or (2) Because what had previously been pushed into negative externalities has been introduced into the transaction proper and has increased the cost by better accounting for the true cost of the item.
The first one is about labels and not about sustainability at all, the second is more what sustainability is all about: trying to allow the market to better account for the true costs of producing (and disposing) of things, rather than having the market ignore "hidden" costs that are increasingly coming back to bite us later.
Jedidiah.
Re:We can all breathe a bit easier
on
Chinese Eco-Cities
·
· Score: 5, Informative
Why per capita? Why not per square foot?
Or why not per dollar of GDP? Measuring pollution by GDP actually represents an interesting metric of production efficiency, and on that scale China is very poor indeed, although the US and Canada are at best middling (on par with nations like Brazil, Sri Lanks and Mexico. It's Japan and various European countries that fare best.
Rather than trying to save energy, we should find ways to produce more energy cheaply without causing pollution. Expensive energy is the root cause of global poverty and reduced quality of life. Cover the deserts with solar panels.. make energy dirt cheap.
This is about both saving energy (by making more efficient use of it) and producing more energy (new energy generation for the city to make it self sufficient). Put most succinctly it is about sustainability. Efforts to "save" energy are not about stopping doing things, but about doing possibly even more than we do now, just doing it all more efficiently so that it doesn't use more energy.
To put it in terms of a rough economic analogy, it's like figuring out how to spend your money more wisely so you can get more out of it. Sure you could simply keep spending flagrantly with ever increasing expenses and just take out larger and larger loans, but eventually you have to sit down and work out what your current income level really is, and then see how you can spend that most efficiently. That doesn't mean you stop trying to get a raise, it just means you try and get "living within your means" as a basepoint.
Sustainability and efficiency do make sense, no matter what your standpoint. I think you're simply constructing a straw man with claims that "The supposed environmentalist "final solution" is to eliminate people" and generally implying that energy self sufficiency is about giving things up, rather than what it is really about: doing even more with what we already have.
You know what would fill that void perfectly? A 10" PowerBook Tablet. Considering that OS X has supported graphics tablets since forever, and they've still got that good handwriting recognition from the Newton, it seems logical to me...
To be honest I was quietly expecting Apple to do something like that with the iMac range - you essentially have something very much like the G5 iMacs with wireless keyboard and mouse and simply add the ability to pick the the up off it's stand carry it somewhere else and use it is tablet with writing recognition. The stand/base can act as a dock for power (and potentially any wired devices you care to attach).
One of the biggest issues with Tablets is that as much as handwriting recognition has improved it is still a low and inefficient way to enter text. If you can make it an optional secondary interface (for when just want to go and sit on the couch and make some notes, dabble, etc.) with the keyboard as the primary option when entering lots of text... well you just might have something.
A couple of things. First it's been tried and it failed, miserably. There are many complicated reasons for why it failed as badly as it did, and of course the failure of New Math doesn't mean some sort of reform of the math syllabus might not be beneficial, but I think it shows you really need to be rather careful about all of this.
As a mathematician I can tell you that there's something I would call "mathematical maturity" - it's a hard thng to pin down and different people develop it at different rates, but it tends to amount to an ability to really grasp various abstract concepts at a deep conceptual level (rather than just as surface definitions). From my experience teaching math, and those of people I know, I would suggest that large chunks f the program you outline require a little more mathematical maturity than is generally deevloped by most people at the required age.
Secondly:...high school curriculum struggles to expand into higher dimensions. Why not replace all of this with a proper introduction to linear algebra? Teach kids how to work directly with inner products and cross products instead of bothering with angles and classical trigonometry.
So you're worried about the inability to expand into hiher dimensions and you want to teach them cross products? Tell me how to take a cross product of vectos in anything other than 3 dimensions. I think what you're after is Geometric Algebra which defines a vector product as a combination of inner (dot) and outer (wedge) products. As soon as you have outer products and exterior algebras working early in the piece then generalisation to hgher dimensions becomes easy.
Next, that doesn't obviate the need for trigonometry in any real way. In case you hadn't noticed trigonometric functions are quite fndamental for a great deal of mathematics.
Whilw that is true, when the interstate system was first put in it was a good thing. The fact that the US government hasn't moved on and is continuing to subsidise the highway system is, I agree, disappointing. Of course other countries, like Japan and France, whose governments have invested in high speed rail systems find themselves a little better positioned, but run the risk of becoming equally tied to projects.
Last I checked most software developers make less then 6M/yr, with overhead, more like 250k. So you're talking about replacing 480K jobs, with 20K jobs. Sounds great to me, they just have to work 24 times as hard.
Or possibly, by having all the work collectively pooled as a common resource the programmers won't have to reinvent the wheel every time they want to do something and save themselves considerable amounts of work.
I'm not saying the plan is great, or that the numbers all stack up nicely, but your claim that it would take 20k programmers with pooled source code 24 times as much effort to produce the same level of output as 480k programmers all working largely independently with little or no significant code sharing or reuse... well you're kind of missing the reason why open source has managed to produce as much as it has (considering the amount of people and time actually devoted to it).
Heck, while we're at it, why not put automotive companies out of business by having government-funded and operated initiatives to build and sell cheap or free cars in regional co-ops?
Now there's a great apples to apples comparison. Let's try and consider some other analogies. What if the government went around spending money to build some sort of interstate highway system? That's just going to put all the private toll highways out of business and be a complete waste of money. What about government providing funding to develop an open standard for computer network communications? Again, an obvious waste of money.
Yes governments spend money badly sometimes. Yes, even when the general idea is right money still ends up in pork that doesn't really serve the original goals (witness that lovely new bridge in Alaska). That doesn't mean that all government expenditure is necessarily bad (unless you have a particular dogmatic ideological bent), and that certainly doesn't mean that government expenditure on common infrastructure items doesn't have significant worthwhile gains. It doesn't necessarily shut out the private sector, but it does ensure that the initial infrastructure is there which, in turn, can provide a significant productivity boost for the country in general. We can, of course, debate what amounts to common infrastructure which will provide sufficient gains to warrant the expenditure, but that was the kind of detail which the article was actually arguing with respect to some software.
I bet that TT's management is kicking itself that it didn't switch to the GPL sooner. If TT would have switched to the GPL before Gnome got off to a concrete start this whole discussion would be academic now.
You know I really don't think that's true. Sure we might not have a GNOME environment based on GTK+, but given the deep differences in philosophy between GNOME and KDE I think we would simply be facing a decision between KDE and some project that forked from KDE early on (around 2.0 I would be guessing) to follow the same design approach that GNOME has now.
If you desperately want to think of it that way, fine. C++ is an extension of C. It is C extended to allow object oriented semantics and syntax. Spec# is an extension of C# . It is C# esntended to allow formal specification semantics and syntax.
I guess there are people who refer to things written in C++ as being "written in C", but generally it gives a somewhat false impression. It'll do as an explanation for people who aren't aware what the extended functionality supplies and what the resulting implications are for te software. It is, at best, just a quick explanation you provide for people who don't really know what they're talking about though.
It's probably closser to SPARK, but yes, it's the same general idea though in this case with the little more emphasis on static analysis and theorem proving. Eiffel is great though - I wish more people would use it, or something similar like SPARK, JML, Spec# etc.
No, it's written in Sing# which is an extension of Spec# which is an extension of C#. People really ought to pay more attention to Spec# - it's a nice extension of C# that allows for more formality if and when you require it. It's in the same class of language as SPARK which is an extension of Ada, JML which extends Java with specification semantics, BitC, Extended ML, HasCASL, and I guess to a lesser extent things like Eiffel and D.
Think of it this way: static types and type signatures for functions allow you to specify things about the software that the compiler can statically check and make sure there aren't any silly errors. The languages listed above (to varying degrees) allow for more exacting specification about the software, and hence you can (with the right tools) do far more comprehensive static checking and ensure various properties of the software. The difference is that, with most of these languages, the amount of specification is optional - you can be as exacting as you want where you need it, and not bother where you don't. It's like a dynamically typed language that lets you declare and use static types (and check them)just for those areas of code where it matters (except you start with static types and can provide more exacting specification where it matters). It's well worth checking out.
As far as I can see, the language in question is not exactly "new" anymore, being C#.
Actually its an extended version of Spec# which is in turn an extension of C#. It might help to acquaint yourself with what that actually means. The first significant different is that Spec# allows for explicit pre and post conditions and other formal specificiation syntax, and hence allows for model checking, extended static checking, and formal proof if required.
It's more like someone writing an OS in BitC because it can be formally verified and hence be more secure. It does make sense, and there is good logic behind it. Comparing it to an OS in Java is just silly. Comparing it to an OS written in Java using JML and associated theorem provers is getting a little closer. Of course that doesn't address the issue of designing the OS to be more secure and reliable from the outset, and not just relying on formal verification.
If you actually bothered to read some of the material on Singularity you would see that it is an ambitious, but remarkably interesting and promising project. It is also, I would expect, something that will permanently remain buried in MS research like so many other projects. I would be interested in seeing a good open source equivalent though - such a project might have some hope of surviving.
I spent 3 seconds on the arstechnica article posted and see that Microsoft has two options 1) Ship a boatload at once, then have a period where none are available 2) Stream out the shipments so that a constant, but limited supply are available
I think you forgot
3) Actually wait till your manufacturing process is geared up and you have a large available supply before doing the launch.
They want to get it out before December so they can take advantage of the Christmas buying rush. Post Christmas sales will be much slower. That would imply a "ship just short of a boatload, then have a limited supply through January" would be the logical option. If they want to try and keep a steady supply then the Christmas sales spike is going to throw that out, so release whenever manufacturing and available supply are in place makes sense.
And that's why I'm looking forward to being able to do smart --install package in the not too distant future. Sure, some distros use RPM and yum databases, some use RPM and apt-rpm, some use DEB and apt databases, and then there's tgz formats... except smart, as a dependency resolver and installation system has pluggable backends. Not only is its dependency resolution system better than apt or yum, it can run against yum-rpm, or apt-rpm, or apt-deb, or even slackware tgz databases, so while different distros can use different packaging and repository systems, the user can have the same installation frontend regardless of what distro she uses.
Of course some distros will still want to go their own way (I'm sure Gentoo will continue to be what it is), but I think it is reasonable to hope and ask the major distros to, regardless of how they want to package and store, make smart available as the client to install software. Hopefully that will be the result in the not too distant future. It helps if more people know about and advocate smart of course...
I can't honestly tell you what you're doing wrong, but X11 works fine for me with no flicker - but then I have nVidia and I hear their Linux drivers are far superior to the ATI ones. The biggest issues I ever had with X11 was with XFree86 and their inability to actually do anything, and the resulting stangantion. Now that Xorg has effectiovely taken over as the premiere OSS X11 implementation things are starting to move again and we can expect to see plenty of improvements down the line.
In the end X11 is a protocol, not an application - there are lots of different implementations. X11 can definitely be a stunning graphical environemnt: IRIX used to use X and you can hardly say SGI was all about shitty quality graphics. You seem to be suffering under a poor driver for your Xserver. Wanting to scrap X11 because of this is like wanting to scrap HTML because there's a page that takes a while to load, or wanting to scrap KDE because someone wroite a crappy application for it.
Almost all the hatred of X11 is largely misdirected. Scrapping X11 is not going to magically make everythign better. Using a better X11 implementation (again, check out Keith Packard's work, which is slowly making it's way into Xorg) is the answer for the problems you're raising, and we don't lose the network transparency which, to be frank, is a truly wonderful thing.
I suggest you actually take some time to learn about what X11 is and how it works before you call to scrap it. There are some legitimate complaints that can be made about X11, but I don't think they're sufficient to start from scratch, and they certainly aren't anything like the ill-informed arguments you are touting.
The whole X server thing. Its a great idea, and has lasted for a long time, but I think its done. The only saving grace I think it has is the ability to remotely run an application and display it and interface it locally. The downside is that local applications are pretty much like remote applications. The graphics are not smooth and jerky at times. They flicker, and just are not as good as graphics on MS Windows or OS X or even a console game. I think X should die.
You are aware that the ability of X11 todisplay remote applications transparently has no significant effect on local applications right? Local applications effectively uses shared memory, the same way OS X and Windows works. Will people please get through their thick heads that the remote capabilitis of X11 have nothing to do with their percieved performance issues of X11. Getting rid of X11's network transparency will not suddenly stop the "flickering". If you want to do that, try messing with Keith Packards kdrive and similar - yes they are still X11, but a different implementation of the X11 protocol that's smoother and has a lot of the facnier effects you might expect.
sed - Powerful and versitile awk - For what sed doesn't do easily perl - For what awk doesn't do easily
You can probably add 2 more items to your list by noting that perl -pe make s a great replacement for sed, and perl -F[PATTERN] -ane makes a great replacement for awk -F[PATTERN], and thus removing awk and sed. Perl gives you all the power and flexibility, and is nice enoug to provide commandline switches to take all the hassle out of common operations.
(For reference "-pe" effectively wraps whatever perl code you write in a while(){...; print;}, and "-F[PATTERN] -ane" wraps your code in while(){@F = split(/PATTERN/,$_);...})
A cute trick: if your only working 1 directory change deep then instead of using pushd and popd you can just use "~-" which is a bash alias for "previous working directory". cd to where you want to be directly, and when you're done just cd ~- to get back to where you were.
I find that sed and awk are two tools I use the most. Not so much for sys admin stuff...but, I get all kinds of fscked up files that need to be cleaned up for insertion into an Oracle database instance.
I used to use awk and sed a lot, but these days I just use perl on the command line - perl -pe has better/more flexible regex than sed and is just as fast for any simple commandline munging. You can do anything awk does while you're at it. Never underestimate perl -i~ -F[PATTERN] -ape for getting things done.
One thing's for sure: Improvements in software quality will be harder to come by if everybody's attitude continues to be "Bugs are inevitable. Formal proofs are beyond us. Let's keep doing it the old way."
Actually I think the thing that needs to be realised is that verification is not some binary thing where you either do a full exhaustive proof of everything, or do nothing at all. There's a vast sliding scale and you can do as much or as little as you need to do for the given project. We already regularly do a certain amount of verification against a specification! Static types and type signatures for functions and methods are specifications for the method and compiling to see if you get any type errors is verification against that spec. You can be a little more detailed in your specification and maybe have proper pre and postconditions instead of just a type signature. There are tools to do extended static checks (beyond the basic type checks) based on such extra information. You can try and construct formal proofs based on a more detailed specification - you don't have to prove everything, you can just prove certain properties that are important. You can do a top down approach starting with a formal specification and produce the code by progressive refinement, verifying each step along the way. You can do as much or as little suits you.
We need to realise that being rigorous about your code is not some "all or nothing" thing. If I write a word processor I probably won't care about specifying the GUI in much detail (if at all), but I might add some formal annotations to a few of the backend routines to, for instance, allow me to prove and verify that files won't ever be corrupted even if the program crashes, or that the print preview is guaranteed to produce an image of exactly what will be printed.
Yes, bugs are inevitable to some extent, and complete formal verification can be more costly than the project requires. That doesn't absolve you from being able to make explicit formal assurances for certain aspects of the program that are important. Software in general would be far better if more software engineers bothered to learn enough about formal specification to use as much as they need in the areas where it is appropriate, rather than just writing off the whole concept as too hard.
Slashdot Mirror
I am quite faimilar with axiomatic set theory and foundations of mathematics. The point remains that in terms of arithmetic of numeric symbols that is largely an issue of definitions (how do we define a number, how do we define addition of numbers, how do we define equality of numbers) and following the (not inconsiderable) groundwork of defintions (and there are actually a few ways to approach this - there are at least two different set theoretic defintions on natural numbers, you can approach it simply with Peano axioms, or you could comne in via a category theoretic approach) the explanation of why 1+1=2 follows very efficiently and almost directly from the definitions.
Jedidiah.
Intelligent Design seems to operate on the oz theory that since we can't see behind the curtain we should take what we see in front of the curtain on face value...We find something we don't understand, somebody attributes it to the divine intervention, then we figure it out.
It goes further than that. Intelligent design relies on linguistic "sleight of hand" and distraction in the very construction of their arguments. It is akin, in many ways, to the various "logical proofs of the existence of God" - it's all about slipping some subtle hidden assumptions into your definitions while railing on about a set of largely indisputable axioms to distract from this slieght of hand.
For Intelligent Design so much hangs on definitions or, more importantly, the lack thereof. Proponents spend a lot of time pounding the table and making arguments, but here are a few terms they use that are really never properly defined: "Intelligent", "Irreducible", "Design", "Complexity". You'll note that almost all their arguments hinge on vague, implicit, and imprecise definitions of these terms. There is much effort spent of verbal distraction to make sure you never really notice that, for instance, complexity is not really defined or measurable, or that intelligence is impossible to clearly delineate from unintilligent in any meaningful way. What does designed even mean in the manner it is used by ID proponents? How do we measure the degree of design?
Jedidiah.
Fisher's Deduction: The more issues a person shoehorns down into an artificial liberal/conservative dichotomy, the more certain you can be that the person is an American.
Jedidiah.
In math, explaining why "1 + 1 = 2" is a very long process too (and not trivial)
Actually, generally, once you've defined what you mean by each of those symbols explaining why "1 + 1 = 2" is quite short and trivial (amounting to "by definition"). Explaining why the arithmetic thus constructed from your definitions is consistently applicable to the physical world... now that's a little harder.
Jedidiah.
Sure there's a lot of pretentious people who talk about environmental issues or sustainability to be trendy and don't know what they're talking about. Pick any subject and you can find such people. Sustainability does make a certain amount of sense, and just because there are some people who promote a rather hollow shell version of the concept doesn't mean there isn't a real concept with ood sense and reasoning behind it.
Anything "sustainable" (or "organic") is guaranteed to be expensive.
And that is usually the case for one of two reasons:
(1) To get a better profit margin selling mostly the same stuff to pretentious gits, or
(2) Because what had previously been pushed into negative externalities has been introduced into the transaction proper and has increased the cost by better accounting for the true cost of the item.
The first one is about labels and not about sustainability at all, the second is more what sustainability is all about: trying to allow the market to better account for the true costs of producing (and disposing) of things, rather than having the market ignore "hidden" costs that are increasingly coming back to bite us later.
Jedidiah.
Why per capita? Why not per square foot?
Or why not per dollar of GDP? Measuring pollution by GDP actually represents an interesting metric of production efficiency, and on that scale China is very poor indeed, although the US and Canada are at best middling (on par with nations like Brazil, Sri Lanks and Mexico. It's Japan and various European countries that fare best.
Jedidiah.
Rather than trying to save energy, we should find ways to produce more energy cheaply without causing pollution. Expensive energy is the root cause of global poverty and reduced quality of life. Cover the deserts with solar panels.. make energy dirt cheap.
This is about both saving energy (by making more efficient use of it) and producing more energy (new energy generation for the city to make it self sufficient). Put most succinctly it is about sustainability. Efforts to "save" energy are not about stopping doing things, but about doing possibly even more than we do now, just doing it all more efficiently so that it doesn't use more energy.
To put it in terms of a rough economic analogy, it's like figuring out how to spend your money more wisely so you can get more out of it. Sure you could simply keep spending flagrantly with ever increasing expenses and just take out larger and larger loans, but eventually you have to sit down and work out what your current income level really is, and then see how you can spend that most efficiently. That doesn't mean you stop trying to get a raise, it just means you try and get "living within your means" as a basepoint.
Sustainability and efficiency do make sense, no matter what your standpoint. I think you're simply constructing a straw man with claims that "The supposed environmentalist "final solution" is to eliminate people" and generally implying that energy self sufficiency is about giving things up, rather than what it is really about: doing even more with what we already have.
Jedidiah.
You know what would fill that void perfectly? A 10" PowerBook Tablet. Considering that OS X has supported graphics tablets since forever, and they've still got that good handwriting recognition from the Newton, it seems logical to me...
To be honest I was quietly expecting Apple to do something like that with the iMac range - you essentially have something very much like the G5 iMacs with wireless keyboard and mouse and simply add the ability to pick the the up off it's stand carry it somewhere else and use it is tablet with writing recognition. The stand/base can act as a dock for power (and potentially any wired devices you care to attach).
One of the biggest issues with Tablets is that as much as handwriting recognition has improved it is still a low and inefficient way to enter text. If you can make it an optional secondary interface (for when just want to go and sit on the couch and make some notes, dabble, etc.) with the keyboard as the primary option when entering lots of text... well you just might have something.
Jedidiah.
A couple of things. First it's been tried and it failed, miserably. There are many complicated reasons for why it failed as badly as it did, and of course the failure of New Math doesn't mean some sort of reform of the math syllabus might not be beneficial, but I think it shows you really need to be rather careful about all of this.
...high school curriculum struggles to expand into higher dimensions. Why not replace all of this with a proper introduction to linear algebra? Teach kids how to work directly with inner products and cross products instead of bothering with angles and classical trigonometry.
As a mathematician I can tell you that there's something I would call "mathematical maturity" - it's a hard thng to pin down and different people develop it at different rates, but it tends to amount to an ability to really grasp various abstract concepts at a deep conceptual level (rather than just as surface definitions). From my experience teaching math, and those of people I know, I would suggest that large chunks f the program you outline require a little more mathematical maturity than is generally deevloped by most people at the required age.
Secondly:
So you're worried about the inability to expand into hiher dimensions and you want to teach them cross products? Tell me how to take a cross product of vectos in anything other than 3 dimensions. I think what you're after is Geometric Algebra which defines a vector product as a combination of inner (dot) and outer (wedge) products. As soon as you have outer products and exterior algebras working early in the piece then generalisation to hgher dimensions becomes easy.
Next, that doesn't obviate the need for trigonometry in any real way. In case you hadn't noticed trigonometric functions are quite fndamental for a great deal of mathematics.
Jedidiah.
Whilw that is true, when the interstate system was first put in it was a good thing. The fact that the US government hasn't moved on and is continuing to subsidise the highway system is, I agree, disappointing. Of course other countries, like Japan and France, whose governments have invested in high speed rail systems find themselves a little better positioned, but run the risk of becoming equally tied to projects.
Jedidiah.
Last I checked most software developers make less then 6M/yr, with overhead, more like 250k. So you're talking about replacing 480K jobs, with 20K jobs. Sounds great to me, they just have to work 24 times as hard.
Or possibly, by having all the work collectively pooled as a common resource the programmers won't have to reinvent the wheel every time they want to do something and save themselves considerable amounts of work.
I'm not saying the plan is great, or that the numbers all stack up nicely, but your claim that it would take 20k programmers with pooled source code 24 times as much effort to produce the same level of output as 480k programmers all working largely independently with little or no significant code sharing or reuse... well you're kind of missing the reason why open source has managed to produce as much as it has (considering the amount of people and time actually devoted to it).
Jedidiah.
Heck, while we're at it, why not put automotive companies out of business by having government-funded and operated initiatives to build and sell cheap or free cars in regional co-ops?
Now there's a great apples to apples comparison. Let's try and consider some other analogies. What if the government went around spending money to build some sort of interstate highway system? That's just going to put all the private toll highways out of business and be a complete waste of money. What about government providing funding to develop an open standard for computer network communications? Again, an obvious waste of money.
Yes governments spend money badly sometimes. Yes, even when the general idea is right money still ends up in pork that doesn't really serve the original goals (witness that lovely new bridge in Alaska). That doesn't mean that all government expenditure is necessarily bad (unless you have a particular dogmatic ideological bent), and that certainly doesn't mean that government expenditure on common infrastructure items doesn't have significant worthwhile gains. It doesn't necessarily shut out the private sector, but it does ensure that the initial infrastructure is there which, in turn, can provide a significant productivity boost for the country in general. We can, of course, debate what amounts to common infrastructure which will provide sufficient gains to warrant the expenditure, but that was the kind of detail which the article was actually arguing with respect to some software.
Jedidiah.
I bet that TT's management is kicking itself that it didn't switch to the GPL sooner. If TT would have switched to the GPL before Gnome got off to a concrete start this whole discussion would be academic now.
You know I really don't think that's true. Sure we might not have a GNOME environment based on GTK+, but given the deep differences in philosophy between GNOME and KDE I think we would simply be facing a decision between KDE and some project that forked from KDE early on (around 2.0 I would be guessing) to follow the same design approach that GNOME has now.
Jedidiah.
If you desperately want to think of it that way, fine. C++ is an extension of C. It is C extended to allow object oriented semantics and syntax. Spec# is an extension of C# . It is C# esntended to allow formal specification semantics and syntax.
I guess there are people who refer to things written in C++ as being "written in C", but generally it gives a somewhat false impression. It'll do as an explanation for people who aren't aware what the extended functionality supplies and what the resulting implications are for te software. It is, at best, just a quick explanation you provide for people who don't really know what they're talking about though.
Jedidiah.
It's probably closser to SPARK, but yes, it's the same general idea though in this case with the little more emphasis on static analysis and theorem proving. Eiffel is great though - I wish more people would use it, or something similar like SPARK, JML, Spec# etc.
Jedidiah.
This is just a research OS written in C#.
No, it's written in Sing# which is an extension of Spec# which is an extension of C#. People really ought to pay more attention to Spec# - it's a nice extension of C# that allows for more formality if and when you require it. It's in the same class of language as SPARK which is an extension of Ada, JML which extends Java with specification semantics, BitC, Extended ML, HasCASL, and I guess to a lesser extent things like Eiffel and D.
Think of it this way: static types and type signatures for functions allow you to specify things about the software that the compiler can statically check and make sure there aren't any silly errors. The languages listed above (to varying degrees) allow for more exacting specification about the software, and hence you can (with the right tools) do far more comprehensive static checking and ensure various properties of the software. The difference is that, with most of these languages, the amount of specification is optional - you can be as exacting as you want where you need it, and not bother where you don't. It's like a dynamically typed language that lets you declare and use static types (and check them)just for those areas of code where it matters (except you start with static types and can provide more exacting specification where it matters). It's well worth checking out.
Jedidiah.
As far as I can see, the language in question is not exactly "new" anymore, being C#.
Actually its an extended version of Spec# which is in turn an extension of C#. It might help to acquaint yourself with what that actually means. The first significant different is that Spec# allows for explicit pre and post conditions and other formal specificiation syntax, and hence allows for model checking, extended static checking, and formal proof if required.
It's more like someone writing an OS in BitC because it can be formally verified and hence be more secure. It does make sense, and there is good logic behind it. Comparing it to an OS in Java is just silly. Comparing it to an OS written in Java using JML and associated theorem provers is getting a little closer. Of course that doesn't address the issue of designing the OS to be more secure and reliable from the outset, and not just relying on formal verification.
If you actually bothered to read some of the material on Singularity you would see that it is an ambitious, but remarkably interesting and promising project. It is also, I would expect, something that will permanently remain buried in MS research like so many other projects. I would be interested in seeing a good open source equivalent though - such a project might have some hope of surviving.
Jedidiah.
I spent 3 seconds on the arstechnica article posted and see that Microsoft has two options
1) Ship a boatload at once, then have a period where none are available
2) Stream out the shipments so that a constant, but limited supply are available
I think you forgot
3) Actually wait till your manufacturing process is geared up and you have a large available supply before doing the launch.
They want to get it out before December so they can take advantage of the Christmas buying rush. Post Christmas sales will be much slower. That would imply a "ship just short of a boatload, then have a limited supply through January" would be the logical option. If they want to try and keep a steady supply then the Christmas sales spike is going to throw that out, so release whenever manufacturing and available supply are in place makes sense.
False dichotomies are silly.
Jedidiah.
And that's why I'm looking forward to being able to do smart --install package in the not too distant future. Sure, some distros use RPM and yum databases, some use RPM and apt-rpm, some use DEB and apt databases, and then there's tgz formats... except smart, as a dependency resolver and installation system has pluggable backends. Not only is its dependency resolution system better than apt or yum, it can run against yum-rpm, or apt-rpm, or apt-deb, or even slackware tgz databases, so while different distros can use different packaging and repository systems, the user can have the same installation frontend regardless of what distro she uses.
Of course some distros will still want to go their own way (I'm sure Gentoo will continue to be what it is), but I think it is reasonable to hope and ask the major distros to, regardless of how they want to package and store, make smart available as the client to install software. Hopefully that will be the result in the not too distant future. It helps if more people know about and advocate smart of course...
Jedidiah.
I can't honestly tell you what you're doing wrong, but X11 works fine for me with no flicker - but then I have nVidia and I hear their Linux drivers are far superior to the ATI ones. The biggest issues I ever had with X11 was with XFree86 and their inability to actually do anything, and the resulting stangantion. Now that Xorg has effectiovely taken over as the premiere OSS X11 implementation things are starting to move again and we can expect to see plenty of improvements down the line.
In the end X11 is a protocol, not an application - there are lots of different implementations. X11 can definitely be a stunning graphical environemnt: IRIX used to use X and you can hardly say SGI was all about shitty quality graphics. You seem to be suffering under a poor driver for your Xserver. Wanting to scrap X11 because of this is like wanting to scrap HTML because there's a page that takes a while to load, or wanting to scrap KDE because someone wroite a crappy application for it.
Almost all the hatred of X11 is largely misdirected. Scrapping X11 is not going to magically make everythign better. Using a better X11 implementation (again, check out Keith Packard's work, which is slowly making it's way into Xorg) is the answer for the problems you're raising, and we don't lose the network transparency which, to be frank, is a truly wonderful thing.
I suggest you actually take some time to learn about what X11 is and how it works before you call to scrap it. There are some legitimate complaints that can be made about X11, but I don't think they're sufficient to start from scratch, and they certainly aren't anything like the ill-informed arguments you are touting.
Jedidiah.
The whole X server thing. Its a great idea, and has lasted for a long time, but I think its done. The only saving grace I think it has is the ability to remotely run an application and display it and interface it locally. The downside is that local applications are pretty much like remote applications. The graphics are not smooth and jerky at times. They flicker, and just are not as good as graphics on MS Windows or OS X or even a console game. I think X should die.
You are aware that the ability of X11 todisplay remote applications transparently has no significant effect on local applications right? Local applications effectively uses shared memory, the same way OS X and Windows works. Will people please get through their thick heads that the remote capabilitis of X11 have nothing to do with their percieved performance issues of X11. Getting rid of X11's network transparency will not suddenly stop the "flickering". If you want to do that, try messing with Keith Packards kdrive and similar - yes they are still X11, but a different implementation of the X11 protocol that's smoother and has a lot of the facnier effects you might expect.
Jedidiah.
sed - Powerful and versitile
...})
awk - For what sed doesn't do easily
perl - For what awk doesn't do easily
You can probably add 2 more items to your list by noting that perl -pe make s a great replacement for sed, and perl -F[PATTERN] -ane makes a great replacement for awk -F[PATTERN], and thus removing awk and sed. Perl gives you all the power and flexibility, and is nice enoug to provide commandline switches to take all the hassle out of common operations.
(For reference "-pe" effectively wraps whatever perl code you write in a while(){...; print;}, and "-F[PATTERN] -ane" wraps your code in while(){@F = split(/PATTERN/,$_);
A cute trick: if your only working 1 directory change deep then instead of using pushd and popd you can just use "~-" which is a bash alias for "previous working directory". cd to where you want to be directly, and when you're done just cd ~- to get back to where you were.
Jedidiah,
I find that sed and awk are two tools I use the most. Not so much for sys admin stuff...but, I get all kinds of fscked up files that need to be cleaned up for insertion into an Oracle database instance.
I used to use awk and sed a lot, but these days I just use perl on the command line - perl -pe has better/more flexible regex than sed and is just as fast for any simple commandline munging. You can do anything awk does while you're at it. Never underestimate perl -i~ -F[PATTERN] -ape for getting things done.
Jedidiah.
One thing's for sure: Improvements in software quality will be harder to come by if everybody's attitude continues to be "Bugs are inevitable. Formal proofs are beyond us. Let's keep doing it the old way."
Actually I think the thing that needs to be realised is that verification is not some binary thing where you either do a full exhaustive proof of everything, or do nothing at all. There's a vast sliding scale and you can do as much or as little as you need to do for the given project. We already regularly do a certain amount of verification against a specification! Static types and type signatures for functions and methods are specifications for the method and compiling to see if you get any type errors is verification against that spec. You can be a little more detailed in your specification and maybe have proper pre and postconditions instead of just a type signature. There are tools to do extended static checks (beyond the basic type checks) based on such extra information. You can try and construct formal proofs based on a more detailed specification - you don't have to prove everything, you can just prove certain properties that are important. You can do a top down approach starting with a formal specification and produce the code by progressive refinement, verifying each step along the way. You can do as much or as little suits you.
We need to realise that being rigorous about your code is not some "all or nothing" thing. If I write a word processor I probably won't care about specifying the GUI in much detail (if at all), but I might add some formal annotations to a few of the backend routines to, for instance, allow me to prove and verify that files won't ever be corrupted even if the program crashes, or that the print preview is guaranteed to produce an image of exactly what will be printed.
Yes, bugs are inevitable to some extent, and complete formal verification can be more costly than the project requires. That doesn't absolve you from being able to make explicit formal assurances for certain aspects of the program that are important. Software in general would be far better if more software engineers bothered to learn enough about formal specification to use as much as they need in the areas where it is appropriate, rather than just writing off the whole concept as too hard.
Jedidiah.