My example may have been a bit excentric, but the SetsLower should not be read a verb "Set" (with +"s" for tense), but as a noun "Set" (with "+s" for plural, hence a set of sets). SetsLower would be a function that gets the lower bound (given some partial ordering) of sets in a set (probably better modelled as Sets.Lower). Get it? SetLower is not what I intendend in my example.
Sorry I couldn't think of a better example. THe point I wanted to make, stands: with case-insensivity, two completely unrelated pieces of semantics may be forced to the same identifier. And since they are so unrelated, you may never notice the clash until you review you complete API through the eyes of the compiler.
Never forget that a compiler should be primarily a tool to help developers, secundarily the other way around.
>It always cracks me up when people invoke these languages that never occur outside of an academic setting.
I guess I should have learned Cobol, right? Leaving C/C++ out, for the sake of the argument, I did two years of coding in Perl + Prolog at a full-text retrieval software company. Currently employed at a supply chain & logistics software company using a blend of C++ & Sicstus + constraint logic programming module.
OK. I've never seen a mature OS written in Modula (some parts in Arthur appear to be, but that could harly be considered a mature OS, right?) and Haskell, Gofer, Miranda are probably just too hard for the average MSCE drone. But please stop whining about not being able to find a job that's more challenging than writing ASP, VB, Java, C#, PHP, Perl, Cobol... interfaces to some SQL database. If you feel your graduate diploma was a waste of time, please look around: There lots of good paying interesting jobs out there.
-- There are two ways of constructing a software design: One way is to make is so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare
I agree that clearer names are always an advantage -- in general. What "clearer" means remains a question. First, mapping two completely unrelated identifiers to the same function doesn't always generate a compiler warning. Just think of overloading, which you would have to consider similarly dangerous.
Second, it may not occur to you that SetSlower & SetsLower are similar because they have completely unrelated meanings. With case-insensitivity you always need to be aware that you identifier might mean something different given a different morphological decomposition of that identifier.
Meaningfull identifier should be able to express as much meaning as possible. Thus, the form of an identifier should not be a goal in itself, but rather an expression of meaning. And ambiguity simply does not help.
-- Is a computer language with goto's totally Wirth-less?
>In something like Unicode where different languages are sharing character codes, case insensitivity is bound to do something unexpected and weird sooner than later.
True. Moreover; I've had some really hard-to-track bugs involving case-insensivity combined with automatic character conversion while interfacing identifiers between different systems, where for example an umlaut (dieresis) was simply ignored by some part of the system ('u'=='Ü'=='UE'==...) while it was relevant to another.
- SetSlower is a procedure that reduces the speed - SetsLower is a function that gets a lower bound in a set of sets
These are completely unrelated identifiers which are rendered equivalent by BASIC and other case-insensitive languages. It may look like a stupid example, but I've been annoyed on several occasions by misinterpreations of VB code that were caused by case-insensitivity. As a C/C++/Prolog/Haskell/Modula/... -coder I'm probably biased toward liking case-sensitivity, but I can't see why liking case-insensitivity should be objectively better; be more than just a bias.
-- What is wanted is not the will to believe, but the will to find out, which is the exact opposite -- Bertrand Russell, "Skeptical Essays", 1928
Therefore, lets leave this issue as it is until someone comes up with good arguments to choose either one or the other.
I concur with your findings. Back in the days I was experiencing a little disconfort with the speed of my Pentium 90 running linux, I decided to buy a Digital Alpha system 266 MHz. Both systems were configured with 64 MB, and both ran Red Hat 5.2.
Although the Alpha system is obviously superior in number crunching, I noticed it ran out of physical memory on a regular basis where my P90 whould still be happy. Part of the matter it that alpha binaries tended to be much larger, as was the kernel. But I'm also quite sure that a major part is primarily due to the increased amount of "lost" bits in pointers and memory alignments of small data structures.
-- The problem with engineers is that they tend to cheat in order to get results. The problem with mathematicians is that they tend to work on toy problems in order to get results. The problem with program verifiers is that they tend to cheat at toy problems in order to get results.
True. The downside: so much for the environmentally clean "new economy" -- even the purely digital contents are preferably shipped physically by many. Admit it or not, but it's the stubborn consumer that will ultimately block "superior" methods of (digital) distribution. Which brings us to the upside: the RIAA is probably conservative enought to eventually understand this part of the consumer's psyche and decide that "illegal" file sharing wasn't a threat to their business after all!
Besides the obvious penalty caused by the DAC, there should also be a minor improvement in applications where the CPU needs to have direct access to (physical) screen memory (older 2D games) or the GPU needs data stored in main memory (3D bitmaps). In the "standard setup" this would require data transfer from main memory to video memory (and vice versa) including the overhead of PCI/AGP synchronization. Wrt. performance the benefits of a separated frame buffer outweigh those of shared memory, in my experience. I'm not sure if this is true as well wrt. the performance/power consuption ratio (use suitable definition), however. Especially when the (Dvi LCD/TFT) screen already has a frame buffer and VSync is only 20-40Hz. (Ditch GPU altogether?)
Anyone with ideas, data?
-- As far as we know, our computer has never had an undetected error -- Weisert
You don't have to commit a crime to go to jail. In those millions of files made for airline passengers, someone is bound to make a mistake in filling in the crosses or someone is bound to interpret a form incorrectly.
If all goes well, you'll be out in a day with appologies, but there is nothing keeping the Bush admin from sending you to Guantanamo bay and keeping you there until you confess.
If you think privacy is an issue only to criminals you've never though about the Gestapo, KGB, Spanish inquisition, McArthy's men, Brittain's "anti-terrorism" laws or JWB's current administration.
--- A conclusion is simply the place where someone got tired of thinking
So true. This is not something you can hide from; it just appears to be. Currently, I work for a Dutch company with offices around the world, approx. half in the US. Until now my employer hasn't forced me to visit US offices, but I am reluctant to go there. I figure I can always quit my job and start working for a locally oriented company, but European and Amercan economies are so closely linked that eventually you'll be affected by US policies directly, or -- as you pointed out by the biometric ID example -- indirectly.
I guess you can't avoid the effects of the US's abuse of power, but you migh be able to change people minds by objecting to it. Or could it?
> How can they get such information, and why do they? This is a concern even before they start making it available to anyone.
Inaccurate data gathered by sloppy / unlawful means could make US customs using the date all the more dangerous.
-- To know that you know what you know, and that you do not know what you do not know, that is true wisdom -- Scooby Doo [...] as we know, there are known knowns, there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. -- Donald Rumsfeld (Whatever)
EU legislation is one thing, but most major European airlines have freely shared ALL passenger info with the US authorities for almost two years, despite questions and objections by various political bodies. The message is clear: If you care about liberty, privacy and those sort of things and you're not an American, than just stay out. Thanks to the 9/11 attacks, the Bush administration now has world-wide carte blance to invade anyone's privacy. </Rant>
-- Those who make peaceful revolution impossible will make violent revolution inevitable -- John F. Kennedy
[From the article:] I was very pleased with the overall performance of the IT100, and would ask that anyone interested in this server not get hung up on the specs.[...]Too often people get caught up in the hype of Dual Xeon or Dual A64 servers, when the truth of the matter is that you do not need that kind of power to run a simple e-mail server and share files.
Couldn't agree more. I understand that less is more, but *WHY* does it have to be more expensive than a similar laptop? Can't you get a discount for a system that's essentially stripped from all user interfaces?
>You have to understand something, the voices of SONY and the RIAA are the only voices that the government is listening to.
I believe the confusion is in the word "governments", which you use to refer to the Bush administration, but which I intended to use to refer to government agencies like Israel's Commerce department, the German government, China, Peru, etc. that are scared away by American lobbyist backed monopolies like Microsoft. I'm not sure about Sony, but the RIAA definitely does not have a very creditable reputation in lobbying these governments.
Just my $.02
-- Those who make peaceful revolution impossible will make violent revolution inevitable -- John F. Kennedy
How about MS adopting to OO.org? None of the new legislations/techniques prevents them from supporting an open standard. And eventually they will, if people keep resisting DRM and governments and large enterprises are forced to support these open standards, mainly by their own anti-trust laws.
Microsoft has shown on several occasions it's able to retreat from a failing assault; even when strong lobby groups tell them to do otherwise.
If Palladium isn't dead yet, I'm sure it will reincarnate in a much lighter form.
Arguibly, ARM is weak in math. The original ARM cores indeed do not feature any floating point facilities, but there have always been facilities for IEEE754 floating point in the architecture. Indeed, there are hardware implementations in the form of co processors and software emulation.
The only reason FPUs were not integrated in StrongARM is that there cost (in terms of Watts) is not justified by the small benefit to performance (in terms of MIPS/FLOPS). Aparently, FPUs, in their current form only make sense for lack of anything better.
If MIPS/Watt is the focus, why not use Intel's StrongARM, XScale or other ARM based cores rather than Transmeta's stuff. Afterall, ARM was designed specifically with the MIPS/Watt ratio as objective, starting a whole new architecture from scratch. Whereas Transmeta has focussed on effectient x86 "emulation".
-- Real computer scientists despise the idea of actual hardware. Hardware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O.
> Eolas vs M$ [...] proves [...](software) patents [...] frustrate rather than further innovation.
'Guess YHO is based on this paragraph:
>The lawsuit could have huge repercussions for other browser makers if Microsoft's expected appeal falls flat: Browsers such as Mozilla, Netscape, Opera, and Safari all use similar means to add plug-in capabilities.
Caldera has also promised to return any changes made to the OSes kernel to the Internet community--its chief partner. Caldera is also aligning with a wide range of companies to address some of Linux's commercial weaknesses.
Sweet! If only some of what people said could be held against them in the court of law...
In my experience - I've worked with a lot of people just coding for the love of it - most coders find specification very hard. The term "Formal Specification" suggests it is a solid way to define program semantics unambiguously. Also, since it is (or should be) a high level language, it should be pretty easy to express complex behaviour.
In reality it is not. Writing a good specification - where good implies not just that it is consistent, but also that it covers the complete problem (and nothing but that problem), it is not too lengthy and is intelligible by people implementing it - is a job unsuited for many, if not most, programmers with average or above average skill. Many of my colleagues with Masters or PhD degrees can't even write proper inline documentation with their code. This is not a matter of learning English but of being able to think abstractly and working very disciplined.
Although I believe specification should always be an integral part of software development, I must say the best and most productive coders are the ones that simply "go out and code". People that know what good code should look like. For a large code base it is far more important to be able to maintain this code than to know that is "correct".
The USA would have ratified Kyoto automatically if only they would have been driving European cars.
Yes, Kyoto is "unfair" in the sense that exceeding levels can be traded with third world countries. Kyoto is "unfair" in that it starts from emission/surface instead of emission/population.
But ratifying Kyoto might at least have shown the USA's intention to do something about its mass consumption. It might have shown they feel responsible for burning over 25% of worldwide resources, while constitutin less than 10% of its population/surface. And, ultimately, it might have led to some form of responsible and respectful behaviour - or it migh have not...
Von Neumann bottle neck
on
Legacy-Free PCs
·
· Score: 2, Interesting
Legacy free PCs......Wow...
Does this really mean we can actually, finally rid ourselves from Von Neumann's bottle neck?
It does, doesn't it?! I could fly my filesystem for hours. No pills needed... And all that in 25Kb -- how's that on a bloated ratio? This Japanese dude needs some good marketing;-)
My example may have been a bit excentric, but the SetsLower should not be read a verb "Set" (with +"s" for tense), but as a noun "Set" (with "+s" for plural, hence a set of sets). SetsLower would be a function that gets the lower bound (given some partial ordering) of sets in a set (probably better modelled as Sets.Lower). Get it? SetLower is not what I intendend in my example.
Sorry I couldn't think of a better example. THe point I wanted to make, stands: with case-insensivity, two completely unrelated pieces of semantics may be forced to the same identifier. And since they are so unrelated, you may never notice the clash until you review you complete API through the eyes of the compiler.
Never forget that a compiler should be primarily a tool to help developers, secundarily the other way around.
>It always cracks me up when people invoke these languages that never occur outside of an academic setting.
I guess I should have learned Cobol, right? Leaving C/C++ out, for the sake of the argument, I did two years of coding in Perl + Prolog at a full-text retrieval software company. Currently employed at a supply chain & logistics software company using a blend of C++ & Sicstus + constraint logic programming module.
OK. I've never seen a mature OS written in Modula (some parts in Arthur appear to be, but that could harly be considered a mature OS, right?) and Haskell, Gofer, Miranda are probably just too hard for the average MSCE drone. But please stop whining about not being able to find a job that's more challenging than writing ASP, VB, Java, C#, PHP, Perl, Cobol... interfaces to some SQL database. If you feel your graduate diploma was a waste of time, please look around: There lots of good paying interesting jobs out there.
--
There are two ways of constructing a software design: One way is to make is so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare
I agree that clearer names are always an advantage -- in general. What "clearer" means remains a question. First, mapping two completely unrelated identifiers to the same function doesn't always generate a compiler warning. Just think of overloading, which you would have to consider similarly dangerous.
Second, it may not occur to you that SetSlower & SetsLower are similar because they have completely unrelated meanings. With case-insensitivity you always need to be aware that you identifier might mean something different given a different morphological decomposition of that identifier.
Meaningfull identifier should be able to express as much meaning as possible. Thus, the form of an identifier should not be a goal in itself, but rather an expression of meaning. And ambiguity simply does not help.
--
Is a computer language with goto's totally Wirth-less?
>In something like Unicode where different languages are sharing character codes, case insensitivity is bound to do something unexpected and weird sooner than later.
True. Moreover; I've had some really hard-to-track bugs involving case-insensivity combined with automatic character conversion while interfacing identifiers between different systems, where for example an umlaut (dieresis) was simply ignored by some part of the system ('u'=='Ü'=='UE'==...) while it was relevant to another.
- SetSlower is a procedure that reduces the speed
- SetsLower is a function that gets a lower bound in a set of sets
These are completely unrelated identifiers which are rendered equivalent by BASIC and other case-insensitive languages. It may look like a stupid example, but I've been annoyed on several occasions by misinterpreations of VB code that were caused by case-insensitivity. As a C/C++/Prolog/Haskell/Modula/... -coder I'm probably biased toward liking case-sensitivity, but I can't see why liking case-insensitivity should be objectively better; be more than just a bias.
--
What is wanted is not the will to believe, but the will to find out, which is the exact opposite -- Bertrand Russell, "Skeptical Essays", 1928
Therefore, lets leave this issue as it is until someone comes up with good arguments to choose either one or the other.
I concur with your findings. Back in the days I was experiencing a little disconfort with the speed of my Pentium 90 running linux, I decided to buy a Digital Alpha system 266 MHz. Both systems were configured with 64 MB, and both ran Red Hat 5.2.
Although the Alpha system is obviously superior in number crunching, I noticed it ran out of physical memory on a regular basis where my P90 whould still be happy. Part of the matter it that alpha binaries tended to be much larger, as was the kernel. But I'm also quite sure that a major part is primarily due to the increased amount of "lost" bits in pointers and memory alignments of small data structures.
--
The problem with engineers is that they tend to cheat in order to get results. The problem with mathematicians is that they tend to work on toy problems in order to get results. The problem with program verifiers is that they tend to cheat at toy problems in order to get results.
True. The downside: so much for the environmentally clean "new economy" -- even the purely digital contents are preferably shipped physically by many. Admit it or not, but it's the stubborn consumer that will ultimately block "superior" methods of (digital) distribution. Which brings us to the upside: the RIAA is probably conservative enought to eventually understand this part of the consumer's psyche and decide that "illegal" file sharing wasn't a threat to their business after all!
--
Recursive, Adjective: See Recursive
>Microsoft don't make secure products because the programmers are directed from the menegment to prefer nice Shiny GUI instead on security.
Apple has some good programmers
Apple management has a GUI focus
Still Apple doesn't make conceptual security flaws like requiring root privilege for any user to perform even the most basic tasks.
--
Every program has two purposes -- one for which it was written and another for which it wasn't.
Besides the obvious penalty caused by the DAC, there should also be a minor improvement in applications where the CPU needs to have direct access to (physical) screen memory (older 2D games) or the GPU needs data stored in main memory (3D bitmaps). In the "standard setup" this would require data transfer from main memory to video memory (and vice versa) including the overhead of PCI/AGP synchronization.
Wrt. performance the benefits of a separated frame buffer outweigh those of shared memory, in my experience. I'm not sure if this is true as well wrt. the performance/power consuption ratio (use suitable definition), however. Especially when the (Dvi LCD/TFT) screen already has a frame buffer and VSync is only 20-40Hz. (Ditch GPU altogether?)
Anyone with ideas, data?
--
As far as we know, our computer has never had an undetected error -- Weisert
You don't have to commit a crime to go to jail. In those millions of files made for airline passengers, someone is bound to make a mistake in filling in the crosses or someone is bound to interpret a form incorrectly.
If all goes well, you'll be out in a day with appologies, but there is nothing keeping the Bush admin from sending you to Guantanamo bay and keeping you there until you confess.
If you think privacy is an issue only to criminals you've never though about the Gestapo, KGB, Spanish inquisition, McArthy's men, Brittain's "anti-terrorism" laws or JWB's current administration.
---
A conclusion is simply the place where someone got tired of thinking
So true.
This is not something you can hide from; it just appears to be. Currently, I work for a Dutch company with offices around the world, approx. half in the US. Until now my employer hasn't forced me to visit US offices, but I am reluctant to go there. I figure I can always quit my job and start working for a locally oriented company, but European and Amercan economies are so closely linked that eventually you'll be affected by US policies directly, or -- as you pointed out by the biometric ID example -- indirectly.
I guess you can't avoid the effects of the US's abuse of power, but you migh be able to change people minds by objecting to it. Or could it?
> How can they get such information, and why do they? This is a concern even before they start making it available to anyone.
Inaccurate data gathered by sloppy / unlawful means could make US customs using
the date all the more dangerous.
--
To know that you know what you know, and that you do not know what you do not know, that is true wisdom -- Scooby Doo
[...] as we know, there are known knowns, there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. -- Donald Rumsfeld
(Whatever)
EU legislation is one thing, but most major European airlines have freely shared ALL passenger info with the US authorities for almost two years, despite questions and objections by various political bodies. The message is clear: If you care about liberty, privacy and those sort of things and you're not an American, than just stay out. Thanks to the 9/11 attacks, the Bush administration now has world-wide carte blance to invade anyone's privacy.
</Rant>
--
Those who make peaceful revolution impossible will make violent revolution inevitable -- John F. Kennedy
[From the article:] I was very pleased with the overall performance of the IT100, and would ask that anyone interested in this server not get hung up on the specs.[...]Too often people get caught up in the hype of Dual Xeon or Dual A64 servers, when the truth of the matter is that you do not need that kind of power to run a simple e-mail server and share files.
Couldn't agree more. I understand that less is more, but *WHY* does it have to be more expensive than a similar laptop? Can't you get a discount for a system that's essentially stripped from all user interfaces?
--
Good marketing beats good engineering
Linux DV HOWTO on Kino plug-ins
>You have to understand something, the voices of SONY and the RIAA are the only voices that the government is listening to.
I believe the confusion is in the word "governments", which you use to refer to the Bush administration, but which I intended to use to refer to government agencies like Israel's Commerce department, the German government, China, Peru, etc. that are scared away by American lobbyist backed monopolies like Microsoft. I'm not sure about Sony, but the RIAA definitely does not have a very creditable reputation in lobbying these governments.
Just my $.02
--
Those who make peaceful revolution impossible will make violent revolution inevitable -- John F. Kennedy
How about MS adopting to OO.org? None of the new legislations/techniques prevents them from supporting an open standard. And eventually they will, if people keep resisting DRM and governments and large enterprises are forced to support these open standards, mainly by their own anti-trust laws.
Microsoft has shown on several occasions it's able to retreat from a failing assault; even when strong lobby groups tell them to do otherwise.
If Palladium isn't dead yet, I'm sure it will reincarnate in a much lighter form.
Arguibly, ARM is weak in math. The original ARM cores indeed do not feature any floating point facilities, but there have always been facilities for IEEE754 floating point in the architecture. Indeed, there are hardware implementations in the form of co processors and software emulation.
The only reason FPUs were not integrated in StrongARM is that there cost (in terms of Watts) is not justified by the small benefit to performance (in terms of MIPS/FLOPS). Aparently, FPUs, in their current form only make sense for lack of anything better.
If MIPS/Watt is the focus, why not use Intel's StrongARM, XScale or other ARM based cores rather than Transmeta's stuff. Afterall, ARM was designed specifically with the MIPS/Watt ratio as objective, starting a whole new architecture from scratch. Whereas Transmeta has focussed on effectient x86 "emulation".
--
Real computer scientists despise the idea of actual hardware.
Hardware has limitations, software doesn't.
It's a real shame that Turing machines are so poor at I/O.
> Eolas vs M$ [...] proves [...](software) patents [...] frustrate rather than further innovation.
'Guess YHO is based on this paragraph:
>The lawsuit could have huge repercussions for other browser makers if Microsoft's expected appeal falls flat: Browsers such as Mozilla, Netscape, Opera, and Safari all use similar means to add plug-in capabilities.
Right? I totally agree.
--
As Zeus said to Narcissus: "watch yourself"
[From the article]
Caldera has also promised to return any changes made to the OSes kernel to the Internet community--its chief partner. Caldera is also aligning with a wide range of companies to address some of Linux's commercial weaknesses.
Sweet! If only some of what people said could be held against them in the court of law...
Good point. I'd like to add one.
In my experience - I've worked with a lot of people just coding for the love of it - most coders find specification very hard. The term "Formal Specification" suggests it is a solid way to define program semantics unambiguously. Also, since it is (or should be) a high level language, it should be pretty easy to express complex behaviour.
In reality it is not. Writing a good specification - where good implies not just that it is consistent, but also that it covers the complete problem (and nothing but that problem), it is not too lengthy and is intelligible by people implementing it - is a job unsuited for many, if not most, programmers with average or above average skill. Many of my colleagues with Masters or PhD degrees can't even write proper inline documentation with their code. This is not a matter of learning English but of being able to think abstractly and working very disciplined.
Although I believe specification should always be an integral part of software development, I must say the best and most productive coders are the ones that simply "go out and code". People that know what good code should look like. For a large code base it is far more important to be able to maintain this code than to know that is "correct".
... And then again...
The USA would have ratified Kyoto automatically if only they would have been driving European cars.
Yes, Kyoto is "unfair" in the sense that exceeding levels can be traded with third world countries. Kyoto is "unfair" in that it starts from emission/surface instead of emission/population.
But ratifying Kyoto might at least have shown the USA's intention to do something about its mass consumption. It might have shown they feel responsible for burning over 25% of worldwide resources, while constitutin less than 10% of its population/surface. And, ultimately, it might have led to some form of responsible and respectful behaviour - or it migh have not...
Legacy free PCs... ...Wow...
Does this really mean we can actually, finally rid ourselves from Von Neumann's bottle neck?
It does, doesn't it?! I could fly my filesystem for hours. No pills needed... ;-)
And all that in 25Kb -- how's that on a bloated ratio? This Japanese dude needs some good marketing