Please tell me about a good randomized sorting algorithm. I haven't heard of any (well, except for those that assume the existence of a sorting network, or other special hardware...)
To clarify even more, insertion sort is O(n^2), but really fast for smaller datasets, and for data already sorted (in that case it is O(n)).
Shell sort is like an advanced insertion sort, that makes it faster for larger datasets, but also adds a larger overhead. It is also O(n^2) in the worst case, but if I remember correctly, Sedgewick proves a much better average-time for (different variants of) it in his algorithm book (which I unfortunately not have handy).
In general, people should avoid quicksort. The obvious implementation (recursion) is not particularly efficient, either speed-wise or in terms of space. Selecting a good value to divide the dataset on is hard (if you want to avoid O(n^2) performance). And it's overkill for anything but quite large datasets. In general, insertion-sort or shellsort is much better.
In general, you should also avoid the C-library routine qsort(). It requires a function pointer for comparison, making it extremely slow. It's also hard to remember how to use it.
Well, he doesn't have to. Because he didn't claim an asymptotically better algorithm. He claimed to have an algorithm better than quicksort (by a factor of 4). This can still mean an O(nlogn) algorithm.
My guess, is that it really isn't. There are many algorithms that are faster than quicksort for smaller inputs. For less than 100 elements, insertion sort wins (hands down). For less than "really more than you usually need to sort, but not really extreme values", shell-sort usually wins.
Also, there are lots of algorithms that are faster than O(nlogn) when you have more information than that given to you by <:. One example would be bucket-sort.
Personally, I couldn't care less. The chances of a second-year student inventing a better sorting algorithm that isn't already published somewhere is nada. That doesn't mean that he is not smart, and that his algorithm is stupid. It *is* probably better than quicksort for the test-cases he has tested it on (and maybe for many more). What it means is that the field of sorting is so well-studied that it is very unlikely to get real contributions from somebody without at least two PhD's in mathematics these days.
There is this thing called CD distributions you know. Back before I had my cable-modem, I used to have a subscription to the InfoMagic linux developer set. It contained (back then), at least RedHat and Slackware, as well as a dump of some popular ftp-sites with active development).
I don't think making a smaller kernel tree just for those people who unecessarily wants to be bleeding edge, don't like CD distributions, don't like downloading patches, won't or can't have broadband at home, and doesn't have access to broadband at a friends place, library, workplace, school or anywhere else is worth the trouble. But if you feel otherwise, just go ahead and make it.
Re:What (cool thing) could you do w/multiple devic
on
Tackling AGP 8X
·
· Score: 3, Insightful
Yeah. Being a hobbyist keyboardist, I've looked into some of these virtual instruments myself, to connect to my sequencer setup. What I can't for the life of me understand is why they all (1) have a GUI, that (2) mimics the real instruments, and is therefore impossible to use, and (3) all take up a lot of screenspace showing useless logos, VU-meters, buttons that don't work, etc...
What I want is something that I can easily control from my midi-instrument(s), not some useless knob on the screen to fiddle with. Alternately, keyboard/mouse control would be useful, but turning round knobs on the screen is completely useless... And they should not use up screen-space
Now, if all geeks moved to North Dakota, I'd be pretty sure of finding a good job in Silicon Valley. I wouldn't be surprised if more geeks thought like that.
And if all geeks moved to North Dakota, then certainly I wouldn't be moving there. I would like some normal people around as well, not to mention people of the opposite sex.
And if you really believe you can get a significant portion of freedom-loving people to move to some state, you are severly misguided about what freedom means. Because freedom-lovers love their freedom, they will not be moved around like cattle.
And while getting all free thinkers to have the same fun idea at the same time (if even for 5 minutes) is close to impossible, making all of them have the same fun idea for long enough to actually sell their house and move to North Dakota (or wherever) is far worse than impossible.
First, make a HIPAA working group with 3 or 4 non-IT members. Help them put out the guidelines, while you take care of the technical stuff, and checks the guidelines for technical sanity. Make HIPAA courses mandatory for everyone. Make the different departments audit each other for HIPAA compliance. Do everything you can to avoid actual HIPAA work yourself.
By involving employees, you will at not only free yourself from a lot of grunt-work, but you will also avoid becoming the nasty HIPAA police everyone ignores and hates. And you will probably also get a bit of enthusiasm from at least some of the co-workers. This is the right approach, because what you are after is mostly a culture-change, not a technical change. Besides, management will love you...
It would help the "average user", if the "average user" would run X11. Of course, if all the "average user" does is run programs locally, there won't be many reasons to change. But here are some I like: work home with stuff at the workplace, work at work with stuff on some server in some other country, work with expensive programs on other peoples computers,... etc...
Personally, I use X11's remote features all the time, and would generally wish it was even more network aware, rather than faster...
Re:Error,Cannot Close Application, Click OK to clo
on
Gnarly Error Messages
·
· Score: 2
No, you don't. That would mean you would quickly spend a lot of time on writing boilerplate code for error-situations instead of being productive. The error can easily be found later with a debugger.
Of course, the assert() macro in C is a good alternative. Simply writing assert(0) will give you the filename and line-number, unless you deliver applications without runtime checking. Of course, writing a NEVER_EXCUTED macro isn't that hard, so that would be an even better alternative. But both assert() and NEVER_EXECUTED leads to excessive bloat, and the debugger solution might be better after all...
Another quite popular alternative, is to put a unique insult to the user in each error-message. This is quite popular. E.g. die("you son of a bitch"), die("you moron"), die("you filthy fever-ridden faggot"), and so on... Since the error messages are not supposed to be seen by the user, this is in theory ok. Just don't tell the boss it was you when they one day complain...
Well, it's surprising, but it's also what we were taught in my chemistry classes. As it turns out DDT is mostly safe for humans (yeah, it is somewhat toxic, but it would take a lot to kill you, or even make you feel ill). People practically lived in DDT (spraying their houses, clothes, everything) without obvious health-effects.
On the other hand, people was going somewhat overboard in their enthusiasm of spraying with DDT, and the long time for natural decomposition meant it would accumulate through the food chain. One of the effects spotted was weaker eggs in birds of prey, especially those eating fish, such as in the antarctic region. As usual, it was the continued increased exposure that worried scientists, not the short-term effects (and yes, we live on top of the food-chain too).
So, it seems reasonable that we could continue to use some DDT, but because of the worrying long-term effects, it shouldn't be used as freely as in the 40's and 50's. The fact that we are still debating it's effects after 60 years shows us that Malaria/DDT is not an easy issue. As an added complication comes the economic divide between north and south, if it was us living in malaria-infected areas, we would probably have kept spraying...
Yes, but do you find much on the web that renders adequately in netscape 3? Or is even rendering at all?
Can you even use e.g. hotmail in netscape 3? Can I access my bank with it? Can I deliver my tax reports with it? Can I use it for popular shopping sites like ebay or amazon? Can I read the online phonebook provided by my phone-company, or the zipcode-catalog by the postal office? If all I can do is to surf the useless majority (unfortunately) of the web (like slashdot), then it wouldn't do me much good.
And that is why I claim that the web is nowadays one of the major reasons to upgrade. Sure, I can still type letters in WP5.1 (actually, I kind of like it), and lotus 123 is still an excellent spreadsheet. And I remember fondly running linux, XFree86, emacs and gcc (yes I did have some trouble) on an old 486sx25 with 8MB of ram and 20MB HD. But the moment I want to access something useful on the web with that machine, I'm lost. And so I am with my old Pentium-clone.
that question the validity of relativity (and I don't mean it's entirely wrong, just that it may be, for lack
of a better word, a good approximation of the truth)
Yes. It's not the ultimate truth. But it's certainly not "only a theory".
There have been many theories in the past that have
predicted a number of things and yet in the end, those theories didn't pan out.
I fail to see what this has to do with the validity of relativity. It really shouldn't be too hard to understand that just because two things are called "theories", doesn't mean that they are equally thrustworthy. Just because two things are called "cars", doesn't mean they have to take the same amount of passengers, and have the same top speed. In fact, just around the corner I saw a "car" that didn't even have wheels. That would mean it's not even usable to drive with, but it still is a car, and I can still drive mine.
Relativity is here to stay. It will be around as long as Newtons laws. It is a useful theory that describes the universe well. It's not the ultimate truth, but it's probably much easier to use than whatever physicists will come up with next (whether it will be string-theory or something even more horrible).
My point is simply, in speaking of these things, it's best not to speak in terms of absolutes, as there are no absolutes in this
area.
Which is a good point. But before you nitpick, you should learn to speak the same language, to avoid being seen as stupid. I no longer believe you are, but your previous post basically made you seem like an idiot. If you want to get your point through, that is hardly the best way.
Nah. Is free software any better? I sure wouldn't want to run Gnome, KDE, OpenOffice or Mozilla on an old PC (My old Cyrix 586 with 48MB ram is completely unusable for webbrowsing. But I can still use old wordprocessors, older versions of gcc, older games, etc without problems. Of course, the web is the only thing I can't get an old version of.
Well, you've got the most expensive networking equipment I've seen then.
For IP over avian carriers to work, you need: a printer, preferably to microfilm, a scanner, preferably from microfilm, OCR software, and lots of avian carriers. Seems to me it would be far beyond the capabilities of the difference engine. What computer do you use to feed your difference engine the IP-protocol messages?
But of course, to understand it, it would be beneficial to have a background in programming. Two excellent books that are useful for non-programmers however are: "David Harel: Algorithmics - The Spirit of Computing", and "Douglas Hofstadter: Goedel, Escher, Bach - An Eternal Golden Braid".
The first book try to condense modern computer science into a few hundred pages written for a layman (much like "A brief history of time" does it for physics). The second combines everything interesting (Art, music, mathematics, philosophy, literature, genetics, etc), with programming, and is among the most interesting books I've ever read.
The foundations of programming in Scheme is covered quite well in "Abelson & Sussman: Structured Interpretation of Computer Programs". But this is only one view. You may also want to read "Bertrand Meyer: Object-oriented software construction" for a relatively different view (more mainstream). Of course, when it comes to programming, there are no hard facts, and people tend to have a lot of differing opinions.
Functional programming and logic programming arose out of a need to make programming more like that of writing specifications, to make it easier to construct mathematical proofs. It would be a good idea to look into that as well. I can recommend "L. C. Paulson: ML for the working programmer" as a good introduction to functional programming. There are also a number of good books on Haskell, please pick one. When it comes to logic programming, things are unfortunately a bit more messy. The main logic programming language, "Prolog", is all but logical. Also, most research these days seems to focus on constraint programming, which is a generalization of logic programming. For a good online introduction, check out Oz Mozart.
The foundations of mathematics (logic, set-theory, category-theory, etc) are all important in computer science. And of course also more mundane subjects such as combinatorics, calculus, etc...
Logic relates to programming, as mathematics do to engineering. While formal methods have not had much practical value so far, it's an important part of computer science, and undoubtedly something that should become important sometime in the future, once we find a practical way to do it. The best place to get the basic ideas are still "Edsger Dijkstra: A discipline of programming". It's more than likely that you local CS department offers some courses.
Since your view is from philosophy, I guess you are more interested in the important insights of computer science, rather than the boring details. In that case, I can also recommend: "Papadimitrou: Computational Complexity" which covers more or less the same stuff as Harel's book, but in a bit more in depth. It would be good to have read a basic book on algorithms first (basically any will do, but I can recommend the books by Sedgewick, or Cormen, Leiserson & Rivest). By this time, you should be able to find your own references in computational complexity and algorithm analysis.
The only model I've seen in actual programs, seem to be the "hairy ball of mud". Basically, everything is integrated into the GUI-code, and changing one line somewhere breaks 10 things elsewhere.
I had high hopes when Tcl/Tk became somewhat popular, because a scripted GUI seems to be the way to go. There was however three reasons it didn't work out in practice. 1: People didn't like Tcl. 2: Interfacing Tcl and C was still too much work. 3: Tk wasn't enough to build a good GUI, and didn't grow fast enough.
On the other hand, I still believe in separation of concerns. Heavily. I've just spent almost a week(!) hunting for one buffer-overrun in a all-to-large program. The lesson learned: "Don't write large programs" (well, not that I didn't know that in the first place).
The only place we have somewhat maintainable code for large GUI's at my workplace is where we have written something in small pieces. If you have complex data to manage, make that a separate application. If you need some (or many) ways to interact with it, make it separate applications. If you need to save and restore it, make it separate applications. If you need a GUI to coordinate it all, make it a separate application. This way, you can easily separate responsability of different parts to different people, and you can use simple unit-testing to ensure correctness of each part. And you can replace stuff that doesn't work, and add new stuff without breaking old things easily.
Secondly, don't build complex interfaces. Keep interfaces down to a minimum. There is a danger in giving each developer their part to play with. And that is, that their overblown egos will quickly assume their part is the most critical, and needs to be the most complex. I've seen interfaces with as much as 60 interface-functions to just get a simple stream of data. It should be four (connect, unconnect, send, receive).
What should then be your "glue"? Well, I would prefer a scripting language, but as of today, there are still no easy alternatives (they all suck in one way or another). So we use CORBA. It's too complex. It's too easy to be locked into a vendor. But it's here, and it works. If you know of something better, please tell me... (I guess XML-RPC, SOAP, etc... might be an alternative in some cases)
These are all theories, not facts. I wish people would just be a little more careful in their phrasing, as indeed, black holes themselves are still theories.
I wish people had a little bit of training in theory of science, before they started worrying about phrasing in discussions about science.
In day-to-day communication, we use the word "theory" to denote something we are not sure of. Thus in day-to-day communication "just a theory" makes sense.
However, in science, a "theory" is basically what the majority of scientists believe to be the truth. There is no difference between a "natural law" and a theory (In fact, "natural law" is most often viewed as a misnomer, and is simply something we use for historical reasons). And there is no "higher level" something can escape to, when people think it's worthy of a higher status than "just a theory".
If you want a word for what scientists use for the day-to-day usage of "theory", their word is "hypothesis". A hypothesis is nothing but an idea. Most theories start as a hypothesis, and then, after a sufficient number of supporting facts have been found, and experiments have been done, people will then speak of it as a "theory". Sometimes, scientists will also use the word "model" as something in-between, but most often it is used by engineers using well-known theories to model complex phenomena.
As for black holes being "only a theory" (in the meaning of "just a hypothesis". Yes and no! It would be very hard to come up with a cosmological model that fitted our universe, that would not predict the existence of black holes. And it would be very hard to explain some observed phenomena as something else than a black hole. On the other hand, the theories of what goes on inside the hole, how it was created, and how it dies (if ever) is very much up to discussion. As for doubting their existence, well it's possible, but not easy...
As for relativity being "only a theory", again assuming you mean "just a hypothesis". In a word, no! The basic ideas of relativity has predicted a lot of observable things in the universe better than any other model. And it has been verified again, and again through experiments. Is it entirely correct? No, it doesn't fit in with quantum mechanics, and therefore can't explain everything (just like Newtons laws can't explain everything). So it's reasonable to believe that there exists an even more complex theory of everything, that will incorporate both quantum mechanics and relativity. Unfortunately, there haven't been too much success in this area yet.
Of course minix is dying for real-world use. Minix was never designed to do anything practical. Minix was designed to be a minimal multi-tasking unix-like micro-kernel OS that was small and simple enough for students to understand in half a year. It still is.
If people were running XF86 on top of Minix, that would in my mind make them crazy. The way to work with minix nowadays is to run it inside e.g. VMware, not to run it as your primary OS. Minix was never intended to be anything but a toy.
But it is a good toy. I have just recently started to look at it, and it is very easy to learn from. And personally, I would rather see it stay that way. It's much better to have a simple educational toy, than a half-assed attempt at making it more complex, and more suitable for actual work. Because for actual work, there are already so many alternatives that are so much better: Windows, Linux, *BSD, Solaris,...
I doubt many minix users really care about the dropped support. They are there for the kernel, and could care less about support for third-party programs.
And Tannenbaums strict control of the source have proven to be right. I can today download minix, and it still has some resemblance to what is described in the book. If Linus and the other good minix hackers had had their own way, minix would today look entirely different, and thus be useless for teaching.
Not being exactly a math whizard myself, I found this book extremely entertaining. It's pretty easy to see that the author is a heavy follower of the KISS philosophy. He tries to keep it simple not just in his code, but also in his explanations. It is possible to understand most of his explanations, even if you don't know much about differential equations, fft's or anything else.
As for the title, I agree it's a bit misleading. The book has pretty little to do about real-time (in fact nothing, as far as I could see). What it really should be called is "Computer arithmetic and a little of numerical methods for dummies". This book will help you understand how to write your own libm, and give you some ideas for more advanced tasks, but that's about it.
For me, who didn't know much of this stuff, it was very interesting. It will probably not save you that course in numerical algorithms (which I for one haven't taken), but even then, it will probably contain some interesting tidbits you didn't know.
On the other hand, if you have years of experience in writing computer math routines, it will probably quickly become dull, but that's true about anything you already know.
I usually carry a pen, and some scrap piece of paper. It can come in very handy when you need to discuss, plan, or understand something that is too difficult to get off the computer screen.
Since I work with some embedded stuff as well, it has happened that my pocket knife have come in handy (some people actually fasten those screws at the end of the com-ports I need access to in order to speak to the equipment).. But it depends on what you do (well, I have also used a multimeter once, but only because I had no lightbulb and two pieces of wire handy).
If you need more tools than that, you can't possibly call yourself a software developer.
Besides, the ultimate toolchest has been discussed at slashdot before. But anyway, here is my suggestion (but for software developers):
A hammer (good for solving problems with faulty compilers)
A bat (see above, but when something else fails as well)
A punchbag (for those situations when you finally found out, the problem was your own code)
A pillow (when you need to take a nap to "think of your problem")
A teddy (which you can try to explain your problem too before you pester your coworkers, most often it's the explaining that is important, not your coworkers suggestion. Besides, it's cuddly and sweet and can give you emotional support when you need it...)
A dirty coffe-mug (that you never wash or use (there are paper cups, right?), but at least keeps your desk less tidy)
A couple of boxes of old outdated and useless manuals for things you don't even remember what was (but sure, the next day after you throw something away, you certainly remember)
Yes, I know, a VERY daunting and time consuming task. But I have a very good understanding of 3D mathematics, physics, and computer graphics in general, plus a solid foundation in computer programming.
Sure, if you are a genius, you can do some amazing things alone (e.g. Linus Thorvalds, Donald Knuth, Larry Wall,....), but since you have to ask this question, you are obviously not demigod material.
The question is, what is the best programming paradigm to use for such a project?
I have no idea what you mean about programming paradigm here. In my normal everyday use of those two words following each other in sequence, it means things such as the logic programming paradigm, functional programming, object-oriented programming, etc... If you don't know which paradigm you would want to choose, you can't as you claim to, have a solid foundation in computer programming, because that would mean you'd picked a favourite already. It doesn't really matter, as long as you pick the right one:-)
I have all of the major concepts, and relationships in mind, but refuse to write one line of code until I have a good design plan.
Well, then you can just sit and wait, because by them time you will have a good design plan you will not only be dead, but also western civilisation will be dead, the earth gone into a new ice-age, then vaporized when the sun went nova, and eventually the universe will have undergone heat-death.
The only way to come up with a good design plan, is to write it after you discover the errors in your last design plan. And the only way to discover the errors in your last design plan, is to try to use it to write some code. This sequence of analyse-design-write-test cycles is known as iterative project management. What you seem to want to do is the waterfall model, and any software engineer will be able to tell you that while it might sound like a good idea, in reality it has never actually worked for anyone...
Plus, if you have all the major concepts and relationships in mind, why are you even asking this question? Seems to me it should just be a matter of coding left then?
Ultimately I would like to be able to tie it into any number of different operating systems, graphics API's (OpenGL, DirectX, etc..), and so on. What are some good ways to do this?
Ehh, just write the darn thing? It's not like it is especially hard to use an API, or what is your problem?
My second question would be, why on earth do you want to tie it into everything? Just to have a list of buzzwords to spread around? Try to focus on functionality, not how much you can "tie it into"...
[...feature...buzzword...feature...feature...featu re...feature...buzzword...feature...feature...buzz word...feature...feature] Any design suggestions?
Slashdot Mirror
Please tell me about a good randomized sorting algorithm. I haven't heard of any (well, except for those that assume the existence of a sorting network, or other special hardware...)
To clarify even more, insertion sort is O(n^2), but really fast for smaller datasets, and for data already sorted (in that case it is O(n)).
Shell sort is like an advanced insertion sort, that makes it faster for larger datasets, but also adds a larger overhead. It is also O(n^2) in the worst case, but if I remember correctly, Sedgewick proves a much better average-time for (different variants of) it in his algorithm book (which I unfortunately not have handy).
In general, people should avoid quicksort. The obvious implementation (recursion) is not particularly efficient, either speed-wise or in terms of space. Selecting a good value to divide the dataset on is hard (if you want to avoid O(n^2) performance). And it's overkill for anything but quite large datasets. In general, insertion-sort or shellsort is much better.
In general, you should also avoid the C-library routine qsort(). It requires a function pointer for comparison, making it extremely slow. It's also hard to remember how to use it.
My guess, is that it really isn't. There are many algorithms that are faster than quicksort for smaller inputs. For less than 100 elements, insertion sort wins (hands down). For less than "really more than you usually need to sort, but not really extreme values", shell-sort usually wins.
Also, there are lots of algorithms that are faster than O(nlogn) when you have more information than that given to you by <:. One example would be bucket-sort.
Personally, I couldn't care less. The chances of a second-year student inventing a better sorting algorithm that isn't already published somewhere is nada. That doesn't mean that he is not smart, and that his algorithm is stupid. It *is* probably better than quicksort for the test-cases he has tested it on (and maybe for many more). What it means is that the field of sorting is so well-studied that it is very unlikely to get real contributions from somebody without at least two PhD's in mathematics these days.
I don't think making a smaller kernel tree just for those people who unecessarily wants to be bleeding edge, don't like CD distributions, don't like downloading patches, won't or can't have broadband at home, and doesn't have access to broadband at a friends place, library, workplace, school or anywhere else is worth the trouble. But if you feel otherwise, just go ahead and make it.
What I want is something that I can easily control from my midi-instrument(s), not some useless knob on the screen to fiddle with. Alternately, keyboard/mouse control would be useful, but turning round knobs on the screen is completely useless... And they should not use up screen-space
...is to put everything into boxes, and get done with it. Hopefully, you will find a lot of stuff you can throw away or sell in the process.
And if all geeks moved to North Dakota, then certainly I wouldn't be moving there. I would like some normal people around as well, not to mention people of the opposite sex.
And if you really believe you can get a significant portion of freedom-loving people to move to some state, you are severly misguided about what freedom means. Because freedom-lovers love their freedom, they will not be moved around like cattle.
And while getting all free thinkers to have the same fun idea at the same time (if even for 5 minutes) is close to impossible, making all of them have the same fun idea for long enough to actually sell their house and move to North Dakota (or wherever) is far worse than impossible.
By involving employees, you will at not only free yourself from a lot of grunt-work, but you will also avoid becoming the nasty HIPAA police everyone ignores and hates. And you will probably also get a bit of enthusiasm from at least some of the co-workers. This is the right approach, because what you are after is mostly a culture-change, not a technical change. Besides, management will love you...
It would help the "average user", if the "average user" would run X11. Of course, if all the "average user" does is run programs locally, there won't be many reasons to change. But here are some I like: work home with stuff at the workplace, work at work with stuff on some server in some other country, work with expensive programs on other peoples computers, ... etc...
Personally, I use X11's remote features all the time, and would generally wish it was even more network aware, rather than faster...
Of course, the assert() macro in C is a good alternative. Simply writing assert(0) will give you the filename and line-number, unless you deliver applications without runtime checking. Of course, writing a NEVER_EXCUTED macro isn't that hard, so that would be an even better alternative. But both assert() and NEVER_EXECUTED leads to excessive bloat, and the debugger solution might be better after all...
Another quite popular alternative, is to put a unique insult to the user in each error-message. This is quite popular. E.g. die("you son of a bitch"), die("you moron"), die("you filthy fever-ridden faggot"), and so on... Since the error messages are not supposed to be seen by the user, this is in theory ok. Just don't tell the boss it was you when they one day complain...
On the other hand, people was going somewhat overboard in their enthusiasm of spraying with DDT, and the long time for natural decomposition meant it would accumulate through the food chain. One of the effects spotted was weaker eggs in birds of prey, especially those eating fish, such as in the antarctic region. As usual, it was the continued increased exposure that worried scientists, not the short-term effects (and yes, we live on top of the food-chain too).
Oblinks:
So, it seems reasonable that we could continue to use some DDT, but because of the worrying long-term effects, it shouldn't be used as freely as in the 40's and 50's. The fact that we are still debating it's effects after 60 years shows us that Malaria/DDT is not an easy issue. As an added complication comes the economic divide between north and south, if it was us living in malaria-infected areas, we would probably have kept spraying...
Can you even use e.g. hotmail in netscape 3? Can I access my bank with it? Can I deliver my tax reports with it? Can I use it for popular shopping sites like ebay or amazon? Can I read the online phonebook provided by my phone-company, or the zipcode-catalog by the postal office? If all I can do is to surf the useless majority (unfortunately) of the web (like slashdot), then it wouldn't do me much good.
And that is why I claim that the web is nowadays one of the major reasons to upgrade. Sure, I can still type letters in WP5.1 (actually, I kind of like it), and lotus 123 is still an excellent spreadsheet. And I remember fondly running linux, XFree86, emacs and gcc (yes I did have some trouble) on an old 486sx25 with 8MB of ram and 20MB HD. But the moment I want to access something useful on the web with that machine, I'm lost. And so I am with my old Pentium-clone.
Yes. It's not the ultimate truth. But it's certainly not "only a theory".
There have been many theories in the past that have predicted a number of things and yet in the end, those theories didn't pan out.
I fail to see what this has to do with the validity of relativity. It really shouldn't be too hard to understand that just because two things are called "theories", doesn't mean that they are equally thrustworthy. Just because two things are called "cars", doesn't mean they have to take the same amount of passengers, and have the same top speed. In fact, just around the corner I saw a "car" that didn't even have wheels. That would mean it's not even usable to drive with, but it still is a car, and I can still drive mine.
Relativity is here to stay. It will be around as long as Newtons laws. It is a useful theory that describes the universe well. It's not the ultimate truth, but it's probably much easier to use than whatever physicists will come up with next (whether it will be string-theory or something even more horrible).
My point is simply, in speaking of these things, it's best not to speak in terms of absolutes, as there are no absolutes in this area.
Which is a good point. But before you nitpick, you should learn to speak the same language, to avoid being seen as stupid. I no longer believe you are, but your previous post basically made you seem like an idiot. If you want to get your point through, that is hardly the best way.
Nah. Is free software any better? I sure wouldn't want to run Gnome, KDE, OpenOffice or Mozilla on an old PC (My old Cyrix 586 with 48MB ram is completely unusable for webbrowsing. But I can still use old wordprocessors, older versions of gcc, older games, etc without problems. Of course, the web is the only thing I can't get an old version of.
For IP over avian carriers to work, you need: a printer, preferably to microfilm, a scanner, preferably from microfilm, OCR software, and lots of avian carriers. Seems to me it would be far beyond the capabilities of the difference engine. What computer do you use to feed your difference engine the IP-protocol messages?
The first book try to condense modern computer science into a few hundred pages written for a layman (much like "A brief history of time" does it for physics). The second combines everything interesting (Art, music, mathematics, philosophy, literature, genetics, etc), with programming, and is among the most interesting books I've ever read.
The foundations of programming in Scheme is covered quite well in "Abelson & Sussman: Structured Interpretation of Computer Programs". But this is only one view. You may also want to read "Bertrand Meyer: Object-oriented software construction" for a relatively different view (more mainstream). Of course, when it comes to programming, there are no hard facts, and people tend to have a lot of differing opinions.
Functional programming and logic programming arose out of a need to make programming more like that of writing specifications, to make it easier to construct mathematical proofs. It would be a good idea to look into that as well. I can recommend "L. C. Paulson: ML for the working programmer" as a good introduction to functional programming. There are also a number of good books on Haskell, please pick one. When it comes to logic programming, things are unfortunately a bit more messy. The main logic programming language, "Prolog", is all but logical. Also, most research these days seems to focus on constraint programming, which is a generalization of logic programming. For a good online introduction, check out Oz Mozart.
The foundations of mathematics (logic, set-theory, category-theory, etc) are all important in computer science. And of course also more mundane subjects such as combinatorics, calculus, etc...
Logic relates to programming, as mathematics do to engineering. While formal methods have not had much practical value so far, it's an important part of computer science, and undoubtedly something that should become important sometime in the future, once we find a practical way to do it. The best place to get the basic ideas are still "Edsger Dijkstra: A discipline of programming". It's more than likely that you local CS department offers some courses.
Since your view is from philosophy, I guess you are more interested in the important insights of computer science, rather than the boring details. In that case, I can also recommend: "Papadimitrou: Computational Complexity" which covers more or less the same stuff as Harel's book, but in a bit more in depth. It would be good to have read a basic book on algorithms first (basically any will do, but I can recommend the books by Sedgewick, or Cormen, Leiserson & Rivest). By this time, you should be able to find your own references in computational complexity and algorithm analysis.
Agreed. I stand corrected.
The only model I've seen in actual programs, seem to be the "hairy ball of mud". Basically, everything is integrated into the GUI-code, and changing one line somewhere breaks 10 things elsewhere.
I had high hopes when Tcl/Tk became somewhat popular, because a scripted GUI seems to be the way to go. There was however three reasons it didn't work out in practice. 1: People didn't like Tcl. 2: Interfacing Tcl and C was still too much work. 3: Tk wasn't enough to build a good GUI, and didn't grow fast enough.
On the other hand, I still believe in separation of concerns. Heavily. I've just spent almost a week(!) hunting for one buffer-overrun in a all-to-large program. The lesson learned: "Don't write large programs" (well, not that I didn't know that in the first place).
The only place we have somewhat maintainable code for large GUI's at my workplace is where we have written something in small pieces. If you have complex data to manage, make that a separate application. If you need some (or many) ways to interact with it, make it separate applications. If you need to save and restore it, make it separate applications. If you need a GUI to coordinate it all, make it a separate application. This way, you can easily separate responsability of different parts to different people, and you can use simple unit-testing to ensure correctness of each part. And you can replace stuff that doesn't work, and add new stuff without breaking old things easily.
Secondly, don't build complex interfaces. Keep interfaces down to a minimum. There is a danger in giving each developer their part to play with. And that is, that their overblown egos will quickly assume their part is the most critical, and needs to be the most complex. I've seen interfaces with as much as 60 interface-functions to just get a simple stream of data. It should be four (connect, unconnect, send, receive).
What should then be your "glue"? Well, I would prefer a scripting language, but as of today, there are still no easy alternatives (they all suck in one way or another). So we use CORBA. It's too complex. It's too easy to be locked into a vendor. But it's here, and it works. If you know of something better, please tell me... (I guess XML-RPC, SOAP, etc... might be an alternative in some cases)
I wish people had a little bit of training in theory of science, before they started worrying about phrasing in discussions about science.
In day-to-day communication, we use the word "theory" to denote something we are not sure of. Thus in day-to-day communication "just a theory" makes sense.
However, in science, a "theory" is basically what the majority of scientists believe to be the truth. There is no difference between a "natural law" and a theory (In fact, "natural law" is most often viewed as a misnomer, and is simply something we use for historical reasons). And there is no "higher level" something can escape to, when people think it's worthy of a higher status than "just a theory".
If you want a word for what scientists use for the day-to-day usage of "theory", their word is "hypothesis". A hypothesis is nothing but an idea. Most theories start as a hypothesis, and then, after a sufficient number of supporting facts have been found, and experiments have been done, people will then speak of it as a "theory". Sometimes, scientists will also use the word "model" as something in-between, but most often it is used by engineers using well-known theories to model complex phenomena.
As for black holes being "only a theory" (in the meaning of "just a hypothesis". Yes and no! It would be very hard to come up with a cosmological model that fitted our universe, that would not predict the existence of black holes. And it would be very hard to explain some observed phenomena as something else than a black hole. On the other hand, the theories of what goes on inside the hole, how it was created, and how it dies (if ever) is very much up to discussion. As for doubting their existence, well it's possible, but not easy...
As for relativity being "only a theory", again assuming you mean "just a hypothesis". In a word, no! The basic ideas of relativity has predicted a lot of observable things in the universe better than any other model. And it has been verified again, and again through experiments. Is it entirely correct? No, it doesn't fit in with quantum mechanics, and therefore can't explain everything (just like Newtons laws can't explain everything). So it's reasonable to believe that there exists an even more complex theory of everything, that will incorporate both quantum mechanics and relativity. Unfortunately, there haven't been too much success in this area yet.
If people were running XF86 on top of Minix, that would in my mind make them crazy. The way to work with minix nowadays is to run it inside e.g. VMware, not to run it as your primary OS. Minix was never intended to be anything but a toy.
But it is a good toy. I have just recently started to look at it, and it is very easy to learn from. And personally, I would rather see it stay that way. It's much better to have a simple educational toy, than a half-assed attempt at making it more complex, and more suitable for actual work. Because for actual work, there are already so many alternatives that are so much better: Windows, Linux, *BSD, Solaris, ...
I doubt many minix users really care about the dropped support. They are there for the kernel, and could care less about support for third-party programs.
And Tannenbaums strict control of the source have proven to be right. I can today download minix, and it still has some resemblance to what is described in the book. If Linus and the other good minix hackers had had their own way, minix would today look entirely different, and thus be useless for teaching.
As for the title, I agree it's a bit misleading. The book has pretty little to do about real-time (in fact nothing, as far as I could see). What it really should be called is "Computer arithmetic and a little of numerical methods for dummies". This book will help you understand how to write your own libm, and give you some ideas for more advanced tasks, but that's about it.
For me, who didn't know much of this stuff, it was very interesting. It will probably not save you that course in numerical algorithms (which I for one haven't taken), but even then, it will probably contain some interesting tidbits you didn't know.
On the other hand, if you have years of experience in writing computer math routines, it will probably quickly become dull, but that's true about anything you already know.
Yes, in deed!
Since I work with some embedded stuff as well, it has happened that my pocket knife have come in handy (some people actually fasten those screws at the end of the com-ports I need access to in order to speak to the equipment).. But it depends on what you do (well, I have also used a multimeter once, but only because I had no lightbulb and two pieces of wire handy).
If you need more tools than that, you can't possibly call yourself a software developer.
Besides, the ultimate toolchest has been discussed at slashdot before. But anyway, here is my suggestion (but for software developers):
Lisp is multiparadigm. It can easily be used as an imperative language. So can ML and Ocaml. It's not usually the best idea, though...
Sure, if you are a genius, you can do some amazing things alone (e.g. Linus Thorvalds, Donald Knuth, Larry Wall, ....), but since you have to ask this question, you are obviously not demigod material.
The question is, what is the best programming paradigm to use for such a project?
I have no idea what you mean about programming paradigm here. In my normal everyday use of those two words following each other in sequence, it means things such as the logic programming paradigm, functional programming, object-oriented programming, etc... If you don't know which paradigm you would want to choose, you can't as you claim to, have a solid foundation in computer programming, because that would mean you'd picked a favourite already. It doesn't really matter, as long as you pick the right one :-)
I have all of the major concepts, and relationships in mind, but refuse to write one line of code until I have a good design plan.
Well, then you can just sit and wait, because by them time you will have a good design plan you will not only be dead, but also western civilisation will be dead, the earth gone into a new ice-age, then vaporized when the sun went nova, and eventually the universe will have undergone heat-death.
The only way to come up with a good design plan, is to write it after you discover the errors in your last design plan. And the only way to discover the errors in your last design plan, is to try to use it to write some code. This sequence of analyse-design-write-test cycles is known as iterative project management. What you seem to want to do is the waterfall model, and any software engineer will be able to tell you that while it might sound like a good idea, in reality it has never actually worked for anyone...
Plus, if you have all the major concepts and relationships in mind, why are you even asking this question? Seems to me it should just be a matter of coding left then?
Ultimately I would like to be able to tie it into any number of different operating systems, graphics API's (OpenGL, DirectX, etc..), and so on. What are some good ways to do this?
Ehh, just write the darn thing? It's not like it is especially hard to use an API, or what is your problem?
My second question would be, why on earth do you want to tie it into everything? Just to have a list of buzzwords to spread around? Try to focus on functionality, not how much you can "tie it into"...
[...feature...buzzword...feature...feature...featu re...feature...buzzword...feature...feature...buzz word...feature...feature] Any design suggestions?
Yes. KISS.