was probably going from Perl 4 to Perl 5. Going across a major release where many features have changed is going to cause problems with any language.
Yeah, I remember that. I looked over the impressively long list of incompatibilities of perl 4 and 5, and wasn't sure I wanted to deal with the hassle. But I rounded up all my zillion lines of perl in hundreds of scripts, took a deep breath, and started putting them through their tests with the new perl5 release. I was unable to find anything at all that didn't work the same as before. Even when I looked for my programs that used the things that were on the incompatibility list, they all still worked unchanged.
So I installed perl5 on all the machines that I had available, and tested all my perl code on all of them. No problems anywhere. I was tempted to try to construct a few test programs that worked differently on 4 and 5, but I was busy and never got around to it. In any case, I was duly impressed by the difficulty I had getting burned by the supposed incompatibilities.
I've mentioned this to a number of other friends who like and use perl, and they all had the same story. So I'm not the only one like that.
I wonder what that guy was doing that had so much trouble and ended up hating perl as a result. Is he an expert at writing code that's dependent on the most obscure machine or OS compatibilities that he can find? I suppose that could be a useful talent in some parts of the software industry.
My conjecture is that this apparent strong backward compatibility is a consequence of the fact that perl's "upgrades" have historically been designed to make the language more general, along the lines of the perl mantra "There's more than one way to do it". The approach has been to make all those ways work correctly, i.e., the way that programmers would usually want them to work. This approach would tend to lead to continued support of the older ways of doing things, since that's what the experienced perl programmers would expect.
I've also collected a lot of C code, going back to the late 1970s, and I've hardly ever had to rewrite anything for new compiler versions. But I've understood from the start that C was intended as a "high-level assembly language", not a true high-level language, and I've always used assembly-like defensive programming techniques in C and that might explain why I never seem to get burned by C incompatibility problems. (I can't say the same for the silly warnings that so many C compilers produce nowadays. They seem be be mistaking C for a high-level language aimed at novices. But they generally include options to suppress most of the warnings, so it's not that big a problem, just a minor hassle.;-)
Just listen sometime to how people brag about being technically illiterate as if it's some badge of honor. "I just don't know these computer thingees," says someone with no shame whatsoever. Do you think they would so proudly admit to being unable to read and write?
This isn't really bragging, you know. It's a way of making oneself feel better about being ignorant.
And it is widespread in the American population. There's a general contempt for "book learnin'" in general, and a special contempt for people who are knowledgeable in scientific topics, especially biology.
An example from when I was in high school: My father installed some rain-spout barrels to collect free water for watering the yard and garden. One day, I noticed a lot of little "wigglers" in them, aka mosquito larvae. I mentioned them to my parents and suggested we do something to eradicate them. The response was to demand that I tell them where I got such a stupid idea as thinking they were baby mosquitos. When I finally admitted I'd got the information from some books, I was soundly criticized for believing all that "book learnin". I was ordered to leave the little critters alone.
I was tempted to report them to the local health authorities, but I understood what would happen to me if I did that. So I kept quiet, and our yard was a local breeding ground for mosquitos.
There are a lot of people living around you like this. If you live in the US, those people have a lot of political power. We're not quite as bad (yet) as the countries that are consciously blocking attempts to eradicate diseases like measles and polio, but a lot of the population would like to push us in that direction.
Biological ignorance isn't just a matter of my opinion versus yours; such ignorance entails the spread of serious diseases among the general population. Ignorance of the evolutionary process is what has led to the overuse of pesticides and antibiotics, resulting in the evolution of resistance in many disease-causing organisms. This isn't an obscure intellectual discussion; it's about future epidemics, plagues, and famines.
I've never seen any study that DIDN'T claim more research was needed.
I've seen this comment suggested as the most important part of any scientific article.;-)
Actually, I like to mention this to the folks on the religious side of the religion-vs-science "war". If you think about it, saying "further research is needed" is a clear, unambiguous statement that the writer doesn't know and understand everything about the topic at hand. This is a sign that the writer probably is actually a scientist.
Religious people, OTOH, already know everything there is to know about whatever topic they're talking about. If you question their evidence, they classify you as a heretic, because a revelation from their Ultimate Authority needs no evidence.
We see a lot of this in a more suble form in this forum. Most of the posts here are in one way or another discussing the claim that this research wasn't needed, because it was known decades ago. People who say that are basically religious, in the sense that they've accepted a theory on the basis of a claim by a supposed authority. But scientists aren't supposed to do this. Yeah, it's handy to accept claims tentatively, if the authority has a good track record so far. But claims of even the most trusted authorities are supposed to be open to challenge.
As others have pointed out, we have had very little actual testing of the various theories about how birds and other critters with flexible, flapping wings actually manage to fly. Almost all our testing has been with rigid, fixed-wing gadgets. That's interesting scientifically, and useful to engineers. But it shouldn't be accepted as an explanation of how birds or bats or insects get their lift.
Relying on untested authorities has a very poor track record, historically. We just had a new case pop up that has gotten a bit of publicity: Someone recently tested the medical benefits of the popular vitamin supplements. It turns out that, unless you have a specific vitamin deficiency disease and take exactly the needed vitamin, they're just placebos, with no measurable affect on health or lifespan. It was just another religious-style scam based on "reasonable" theories, but all it did was extract money from the population for no health payback. It's yet another good example of why we need actual scientific tests of things that "everyone knew years ago". The medical field in particular has a history of this sort of untested "everyone knows" belief system.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles....
But that isn't reactive; it's still polling.... you have to type "make [...]" or set up a cron job, you aren't doing reactive.
So who said anything about typing "make"? It's quite common for, e.g. a web CGI program to start a "make" process after the client input has been written to the appropriate files. The CGI program can then proceed or exit, and make's updates will happen in the background. It's also not uncommon to see Makefile commands of the form "cd some/dir; make foo" as part of the update process.
This isn't materially different from a write/assign triggering a cascade of updates via some routine deep down in the system library or OS. Its main advantage is that it gives the programmer better control of exactly when the updates are triggered. In the languages I use for CGI (bash, perl, tcl, python) it's also easy to check for the completion of the "make" process, and you can also get the error messages if you need them. My investigation of "reactive" libraries didn't spot any way to do this, though I could easily have missed it.
Aside from syntax, a set of Makefile entries are conceptually similar to the rules used in a "reactive" language. Which is better probably depends mostly on your application.
I don't remember ever setting up a cron job that does makes, but I'd imagine it could be a practical approach in some cases, when it's not important that the updates be done quickly. I do have one web site that I'm responsible for where the CGI processes finish by checking their process id, and if it's a multiple of 100, run "make clean" to clear out old log files, etc. But this isn't really the same thing. In perl, it's a one-liner: system 'make clean &'.
OTOH, I have seen an annoying problem with a low-level "reactive" tool: Suppose that A depends on B, C and D. If all three change, this tends to trigger three updates of A that overlap. This is at best a waste of CPU time, and it can lead to race conditions in complex dependency trees. Using the "make" approach, if the changes to B, C and D are done by a single process or a set of communicating processes, it's easy to delay the update until all the leaf data has been written, when a single update process can do all the updates. This is much easier to program correctly. Of course, a well-designed reactive library might provide ways to control this, but the result would probably be isomorphic to the "make" approach.
(And firing up a "make" process isn't cheap. It could be useful to have an equivalent process running permanently, with updates triggered by an inter-process message. But this is merely an efficiency gain; it's still logically equivalent to a "make" command.)
We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
This is yet another illustration that the perps who introduced this supposedly-new concept have mostly just found a new buzzword for an approach that has been reinvented repeatedly in the past.
One of the ongoing problems in many fields of science and technology is the constant rediscovery (or reinvention if you prefer) of concepts long known by others that just use different words for the concepts.
Actually, mathematicians long ago realized this, and have a standard term for things that are described differently but are actually identical: They're generally called "isomorphic". A classical example that's important in computers was George Boole's "Boolean algebra", invented primarily as an exercise in pure logic. Eventually people noticed that it was isomorphic to the "propositional calculus", and then as electricity became widely available, engineers found that their new "circuit switching calculus" was another isomorphism. That's why so many programming languages have those AND, OR, XOR, NOT, etc operators.
This crowd is merely giving us another entry in the rather long list of isomorphic systems that differ only in their terminology. This means time wasted re-developing your system from scratch, when you could have saved a lot of time if you'd only realized that others had already solved your problem for you. But we don't have a good way to discover that two systems described with different words really are the same thing.
(Or do we? Maybe some mathematical linguists are working on the problem right now, and we don't realize this because we don't recognize their terminology.)
You don't need every driver to understand how a transmission works in order to get their drivers' license, and you don't need every delivery driver to understand routing algorithms to be able to drive their route.
You're right, of course. Except that the topic here isn't about the general population of computer users; it's about teaching maybe 1% of people to develop the software for those computers.
With autos, it's true that 99% of us will never need to understand how a transmission or other internal subsystems work. But if you're considering a career either designing or maintaining vehicles, you'd damned well better be learning about the mechanics (and chemistry and electronics) of their internal mechanisms, or you'll never get a job in the field.
Similarly, drivers might not need to understand routing, but the people who manage the routing system (or the computers that run the routing software) need to understand the topic, or they'll just screw it up. If you want a job developing their routing software, you'd better understand routing algorithms, or the people hiring developers will just laugh at you and toss your resume in the trash.
Most users of computers can do what they want using just a GUI. But we're talking about the future programmers, and if they don't understand the CLI approach as well as the GUI, they'll be crippled as developers. Without understanding both levels of your gadgets' command system, any time it gets flakey, you'll be dependent on the people who do understand the internals to get it working. Either that, or you'll be sold a new gadget because your old one is "broken", although it might have been fixed in a few minutes by someone with full knowledge of how to query its internals.
(This latter point has been important to the spread of unix/linux behind the scenes. You might be impressed to find out how many of the machines behind the Internet started life as DOS/Windows systems, and were discarded by their owners because they no longer "worked". I have two such servers myself. Free cast-off windows boxes are often quite serviceable as gateways/routers/servers when their disk is reformatted with a unix system. I run several web sites on "small, slow" machines no longer usable with Windows, but quite able to handle a million or so web requests per day and still be 90% idle. Most of these don't have a windowing system installed. Right now I have 5 Terminal windows open on this Macbook Pro that are ssh'd into 3 such servers, running OpenBSD, FreeBSD and linux on 10-year-old previously-Windows boxes. Plus one ssh'd into a server machine that was born running Ubuntu. The Macbook has a faster cpu and more memory than any of them, but at 4 years, it's nearing the end of its useful life running OS X and Darwin, and I'll have to replace it soon. Maybe I'll reincarnate it as a linux server. It's overpowered for that job.;-)
My issue is that I shouldn't need an app to access the same info I can get via a browser on the desktop. Why, if that app does a better job, does it ask for permissions to data it has no need to access?
Duh; one of its important jobs is sending that data back to its mother ship (or to the NSA.;-)
Doesn't everyone understand that? Are there "smartphone" users dumb enough to think that the app isn't doing such things?
Get a device with a big enough screen, and the internet isn't painful anymore. It's that simple.
Heh. That doesn't always help. A lot of the Internet is painful by design. They make it that way with malice aforethought.
A trivial example in the window I'm typing in right now: There's a horizontal scroll bar at the bottom of this/. window. OK, it has a width= attribute that shouldn't be there that's forcing it to a fixed width, right? Nope. I grabbed one of the resize handles on the window's border, and resized it a few times. No matter what size I made it on my (rather large) screen, the/. window is sized to be slightly wider than that. It dynamically detects the size, and forces the content to be wider.
This is fairly common, and the solution is trivial: Remove all the width= and other size attributes. There's nothing in this/. page that requires such things, and without them, the browser will "flow" the text so that everything fits. But/., like so many sites, tries doing something "clever" (i.e., dumb) with the sizes, and as a result, there's nothing I can do to make it fit.
This is known in legal circles as "with malice aforethought". The developers understand the problem quite well. If they didn't, they wouldn't be smart enough to use HTML in the first place. So they must be doing it intentionally.
And I've seen why this can happen. I've worked on a number of projects that needed a web interface. On many of them, I've gotten explicit orders that the pages must be sized to specific width, so they'll fit in the window the boss wants to use on his desktop. If the boss's desired size isn't the default, it won't be accepted. This sort of idiocy is quite common, and it's not easy to fight.
Actually, I have "fixed" it on a number of projects. These were cases where we had a good reason to have all pages delivered by a CGI program that parses the client's request, runs appropriate data-fetching and -munging subprocesses, and formats the results in HTML. I sneak in a little check of the HTTP_USER_AGENT, and if it's IE (which is the only browser that such bosses know exists), my code generates the required width= attributes; else it produces no sizing instructions at all.
The results usually work fine on anything from a dumb "smartphone" to a humongous window on a humongous display. Or a small browser window on your screen, whatever it is. And it meets the boss's requirement for a fixed width on his screen.
So far, I haven't been caught performing such treachery by any of my bosses, but it's probably only a matter of time. They often believe that their web sites need only work on screens exactly like the one on their desk, and they explicitly order their developers to do it that way, or else.
This is just one of the many reasons for the problem we're discussing. It's yet another example of the old one about not attributing something to malice which may be explained by stupidity. (Quick, without googling it, which famous writer is that usually attributed to?;-)
... you fucking moron, following orders IS ALL A FUCKING COMPUTER CAN DO
Reminds me of that old poem about computers, which ends with the punch line "It never does what I want, only what I tell it".
This was a cliche back in the 1970s at least, perhaps earlier. Ranting about it won't have much effect, because those who understand you will have understood the above all along. The rest simply don't understand what computers are at all.
Unfortunately, a lot of those people are in positions of authority in our governments.
We were human 100000 years ago? Weren't we human-LIKE way back then? I mean, denisovians and Neanderthals weren't human, were they?
Well, if you're talking about the conventional usage of "human" in scientific circles, the answer is: Yes, they were; they just weren't modern humans.
But "human" really isn't a technical term; For that you want something like "Homo" or "hominin", depending on how far back in the tree you want to describe. The term "human" is used informally to mean just about any critters later than the split from the Pan (chimpanzee) branch. It's used when you don't want to be too precise about such things.
OTOH, "human" is widely used in common speech to refer to anyone "not like us". Sometimes it means "white people", especially in writings from before the 20th century. But you don't much hear such usages in scientific settings. You do see it a lot in media coverage of science, but then it means whatever the journalist thinks it means.
... the voting public are fucking morons too damn lazy to know that CONGRESS MAKES THE FUCKING DECISIONS.
You're not nearly the first to make this observation. For another recent example, there's the video of the "reporter" asking people whether the US government shutdown was caused by Obama or Bush. This was a bit of a prank, of course, but they did comment that nobody gave the correct answer: "Neither; it was caused by Congress." Yes, the president has some significant influence in the annual debates over the next year's budget. But, as specified in the US Constitution, only the Congress actually votes on budget bills. It sometimes seems that nobody in the country (not even our Congress critters;-) knows anything about this.
Considering all of the KGB documents that have recently been made available which reveal how successful they were at infiltrating US institutions, I'm surprised people still hold the opinion they do of McCarthyism.
It's probably because most "US institutions" are organizations that want members who support their goals, and very few such organizations ever do any investigation at all of new members' backgrounds. If you ask a member of most organizations about their investigations, they'll just look at you like you're some sort of weirdo, and perhaps show a bit of nervousness about someone like you who would even mention such things. If you show an interest in the organization's goals, cooperate in their activities, and pay the membership fee, you're accepted as one of them. That's the way normal human organizations work, after all. Only a few extreme political and religious organizations would ever do such investigations. There's a reason we often call them "witch hunts". We understand that they're generally aimed at condemning people without bothering with unnecessary stuff like evidence.
If you determine you don't have the necessary ingredients to begin the process, do you say you quit on the first step, or never started?
Yeah, that's the critical difference in the thinking. My calling the ingredient list "step 0" is based on the thinking that a recipe is something that tells you how make a food item. With this understanding, it makes sense that you'd consider "recipe" to mean only the actions you take that create the food item. If you already had all the ingredients in your kitchen a week ago, you wouldn't say that you started making the recipe last week. Checking the ingredient list makes nothing, so it's not a "step", it's merely a description of required initial conditions. Making the food means what you do in the kitchen when you decide what you want to eat. Buying ingredients earlier (perhaps by months because you know you'll want those ingredients some day) isn't part of making the food item. Deciding not to make a recipe because you lack a critical ingredient doesn't mean you've done the recipe's first step.
OTOH, it's reasonable that you'd interpret the ingredient list as a sort of command (though such lists never contain imperative verbs). It means "First, make sure you have the following ingredients...." Someone who thinks that way could reasonably label the list as "step 1".
I tend to take the first approach, which is probably related to the fact that I like to keep a lot of non-perishable ingredients on hand for the food items I make often. Thus, I have a couple of bags of flour on a top kitchen shelf, several pounds of butter in a freezer in the basement, etc. I don't think of buying those ingredients as part of making a recipe. Several of the above posters apparently do, perhaps because their approach is to decide on a recipe, and then go buy the ingredients. Nothing wrong with that, if you have some good stores nearby. But it does lead to a different interpretation of that ingredient list at the top of a recipe.
There are plenty of software documentation sets, tutorials, etc, like this one (selected at random), that have Step 0, Step 1, etc.
And that example illustrates the usual reason for starting with step 0: The "zero" step is determining your initial state before you start doing anything. In this case, it's determining whether you should bother going on to step 1, which is pretty common. It's also common to use step 0 to list the material needed by the task.
Probably the most common real-world example is cooking recipes, which typically start with a list of ingredients. That "step" is typically not numbered, but sometimes the actual "steps" to create the food are numbered starting with 1. Or they're just in separate paragraphs, since numbering them isn't actually very useful to carry out the task. In any case, the ingredient list is usually typographically different than the rest of the recipe, and is a description of the required initial state, so it's natural to call it "step 0".
So if the submitter won't doi it, or the slashdot editors won't do it, the next time you read about malware infecting a bunch of users computers don't forget to add "in windows" to the end.
It similar to the advice I ran across years ago: If any news story talks about problems with "computers", you should always add "running MS Windows". If it were any other kind of computer, they would have told you its brand name. Since then, I've been looking for exceptions, where a computer problem bad enough to make the news was on machines using non-MS software. So far the only cases I've run across have always mentioned the brand or the OS name. I keep expecting exceptions, and maybe some day I'll spot one.
And of course execs have admin privs on their PC. They don't know what to do with it, they don't know why they got it, but don't you dare even suggesting taking it from him!
Reminds me of the old observation that you can easily determine someone's software expertise from the log data showing how often they run with elevated (root, admin, whatever) privileges: The two quantities are inversely related.
I recall once impressing some people at a company that I was contracting for, when at a meeting I was asked if I needed root privileges on the machines I was using for testing. I shrugged, and said I didn't think so. When they looked puzzled, I just said that in the few cases I'd needed root privileges, I'd got them for the few minutes that I needed by using the "jcroot" account that I'd created. The IT guys got nervous looks on their faces, implying that they didn't know that was possible; the other developers were just grinning. Some time later, several IT guys showed up and wanted to know how I did it. I showed them how to use one of the exploits that hadn't been fixed on their machines. A few weeks later, they did an "upgrade" that blocked that exploit (but they didn't disable my root account). They didn't ask how many others I knew of. Maybe some of their other developers told them about a few more eventually.
I also spent a bit of time explaining that I've learned it isn't a good idea to work with more privilege than I need. The builtin security stuff is pretty good at preventing you from making dumb "typo" type mistakes that take time to fix. Yeah, this is a bit simplistic, but it's something that they could understand, and might have persuaded a few of them that they didn't need to run routinely as at admin level. Maybe, but probably not.
The difference is, the fighters are hugely complex and bleeding edge. A website is pretty old hat in 2013.
From what I've read, it's actually sorta the opposite. The healthcare.gov site is generally described as a bureaucratic database horror story. Multiple databases, actually, each with its own API (that's poorly documented), each one elsewhere on the Net, with unrealistic response-time "requirements" written by managers with little distributed-DB experience. And no understanding that messages between sites can't move faster than the speed of light.
Funny thing is that I've also read a number of comments recently about the zillions of cases where new decrees from Congress are handled by thousands of government web sites within a day or two. Thus, the recent "shutdown" was handled gracefully by most departments' web sites, and they were back up within a day or so when the people were called back to work.
So it's not that "the government" can't handle building and revising web sites. Thousands of departments are doing it the job routinely, and nobody notices because it usually goes smoothly.
But healthcare.gov by its very nature has attracted the attention of every politician within reach, most of which qualify as PHBs who want their name attached to the results but are otherwise clueless about this InterWeb stuff. The result is a flood of conflicting orders coming down to the grunts doing the actual web-site development, with radical changes appearing in their inboxes daily.
I'm sure that lots of readers here can identify with this situation. How often have the rest of you seen exactly this sort of mess in a corporate setting? I'm sure we can collect a lot of good horror stories. Or we can just go over to The Daily WTF and read about (or submit them) them there.
Yup, and a general response I've seen that I sorta like is: If you can say beforehand what the results of your research will be, then it isn't research, it's engineering. Of course, we need good engineering, too. But first, we have to have the scientific knowledge that good engineering is based on, and that requires scientific research (plus learning from our mistakes;-).
In general, you can only predict the outcome of something that you know and understand. If you want to extend your knowledge and understanding, you need real research, whose results you can't know until after you've done the research.
Requiring researchers to state beforehand how the results will benefit us has only one effect: It bans actual scientific research. Of course, this might be what is intended.
"Look what the Bible says" only counts as an argument if (a) you can read the original Hebrew/Greek/Latin
Aramaic, you fucktard.
Actually, you'd have to be able to read all four of them, and probably several dialects of each.
Also, you'd have the problem of even finding the original texts. What texts we have, that people mistakenly call "original", date to centuries after the events described. The usual legal term for such long-after-the-facts texts is "hearsay", not "original".
But it's all good as a source of humor, at least until the true believers come looking for you.
Daddy lets you look at a slideshow, spot the magically appearing star. Boy genius!
Or, to convert it from an unsubtle put-down to a more accurate description, it's a straightforward example of something that astronomers have long pointed out: Despite being one of the hardest of "hard sciences", astronomy is a field that has always made good use of interested amateurs. This is yet another of thousands of examples.
The typical explanation is that astronomers do much of their work on high-powered equipment that can give them detailed, close-up views of things out there. This is valuable research, but has the problem that such equipment typically has a tiny field of view, so astronomers often miss interesting things that are outside their tiny fields of view. Astronomy needs people doing wider-angle work, comparing images from different times (and maybe different equipment), to spot interesting things. This is often best done by amateurs with lower-powered equipment. They can report their findings to the astronomers, who can aim their high-powered tools at the coordinates to get the details. Amateurs rarely get paid, but astronomers traditionally reward them by naming discoveries after them.
An interesting extension of this in the "Zooniverse" project, ake the "Galaxy Zoo". Look it up. What they do is take images from the petabytes of data supplied by the newer telescopes, show them to volunteers, and ask them to mark various kinds of "interesting" things in the photos. Each of their projects starts with a short training session showing you one or two examples of what they're looking for. Then you dive into a string of random images, marking them up, and sending them back to the project's computers. Currently, they have a set of details in the Andromeda Galaxy (M31) for people to see and mark up.
This development is interesting partly because it's aimed at amateurs with no special equipment other than a personal computer. They've got very good response, from people who want to while away a few hours looking at pretty pictures of the sky and marking them up. Astronomers have said that their volunteers have led to a lot of interesting discoveries. One of the widely-recognized examples was "Hanny's Voorwerp" (look it up;-), which was discovered by and named for a young woman who is a Dutch school teacher. It has led to several years of work by many astronomers trying to figure out what that thing is.
So, while mocking this kid might be satisfying, it's missing an important point about how some scientific fields actually work. He's probably good enough already to contribute to this effort. As are most of the readers of slashdot.
Slashdot Mirror
was probably going from Perl 4 to Perl 5. Going across a major release where many features have changed is going to cause problems with any language.
Yeah, I remember that. I looked over the impressively long list of incompatibilities of perl 4 and 5, and wasn't sure I wanted to deal with the hassle. But I rounded up all my zillion lines of perl in hundreds of scripts, took a deep breath, and started putting them through their tests with the new perl5 release. I was unable to find anything at all that didn't work the same as before. Even when I looked for my programs that used the things that were on the incompatibility list, they all still worked unchanged.
So I installed perl5 on all the machines that I had available, and tested all my perl code on all of them. No problems anywhere. I was tempted to try to construct a few test programs that worked differently on 4 and 5, but I was busy and never got around to it. In any case, I was duly impressed by the difficulty I had getting burned by the supposed incompatibilities.
I've mentioned this to a number of other friends who like and use perl, and they all had the same story. So I'm not the only one like that.
I wonder what that guy was doing that had so much trouble and ended up hating perl as a result. Is he an expert at writing code that's dependent on the most obscure machine or OS compatibilities that he can find? I suppose that could be a useful talent in some parts of the software industry.
My conjecture is that this apparent strong backward compatibility is a consequence of the fact that perl's "upgrades" have historically been designed to make the language more general, along the lines of the perl mantra "There's more than one way to do it". The approach has been to make all those ways work correctly, i.e., the way that programmers would usually want them to work. This approach would tend to lead to continued support of the older ways of doing things, since that's what the experienced perl programmers would expect.
I've also collected a lot of C code, going back to the late 1970s, and I've hardly ever had to rewrite anything for new compiler versions. But I've understood from the start that C was intended as a "high-level assembly language", not a true high-level language, and I've always used assembly-like defensive programming techniques in C and that might explain why I never seem to get burned by C incompatibility problems. (I can't say the same for the silly warnings that so many C compilers produce nowadays. They seem be be mistaking C for a high-level language aimed at novices. But they generally include options to suppress most of the warnings, so it's not that big a problem, just a minor hassle. ;-)
Just listen sometime to how people brag about being technically illiterate as if it's some badge of honor. "I just don't know these computer thingees," says someone with no shame whatsoever. Do you think they would so proudly admit to being unable to read and write?
This isn't really bragging, you know. It's a way of making oneself feel better about being ignorant.
And it is widespread in the American population. There's a general contempt for "book learnin'" in general, and a special contempt for people who are knowledgeable in scientific topics, especially biology.
An example from when I was in high school: My father installed some rain-spout barrels to collect free water for watering the yard and garden. One day, I noticed a lot of little "wigglers" in them, aka mosquito larvae. I mentioned them to my parents and suggested we do something to eradicate them. The response was to demand that I tell them where I got such a stupid idea as thinking they were baby mosquitos. When I finally admitted I'd got the information from some books, I was soundly criticized for believing all that "book learnin". I was ordered to leave the little critters alone.
I was tempted to report them to the local health authorities, but I understood what would happen to me if I did that. So I kept quiet, and our yard was a local breeding ground for mosquitos.
There are a lot of people living around you like this. If you live in the US, those people have a lot of political power. We're not quite as bad (yet) as the countries that are consciously blocking attempts to eradicate diseases like measles and polio, but a lot of the population would like to push us in that direction.
Biological ignorance isn't just a matter of my opinion versus yours; such ignorance entails the spread of serious diseases among the general population. Ignorance of the evolutionary process is what has led to the overuse of pesticides and antibiotics, resulting in the evolution of resistance in many disease-causing organisms. This isn't an obscure intellectual discussion; it's about future epidemics, plagues, and famines.
So is there any data on the quantity of methane, etc. produced by this? How does it compare with cow farts, for instance?
I've never seen any study that DIDN'T claim more research was needed.
I've seen this comment suggested as the most important part of any scientific article. ;-)
Actually, I like to mention this to the folks on the religious side of the religion-vs-science "war". If you think about it, saying "further research is needed" is a clear, unambiguous statement that the writer doesn't know and understand everything about the topic at hand. This is a sign that the writer probably is actually a scientist.
Religious people, OTOH, already know everything there is to know about whatever topic they're talking about. If you question their evidence, they classify you as a heretic, because a revelation from their Ultimate Authority needs no evidence.
We see a lot of this in a more suble form in this forum. Most of the posts here are in one way or another discussing the claim that this research wasn't needed, because it was known decades ago. People who say that are basically religious, in the sense that they've accepted a theory on the basis of a claim by a supposed authority. But scientists aren't supposed to do this. Yeah, it's handy to accept claims tentatively, if the authority has a good track record so far. But claims of even the most trusted authorities are supposed to be open to challenge.
As others have pointed out, we have had very little actual testing of the various theories about how birds and other critters with flexible, flapping wings actually manage to fly. Almost all our testing has been with rigid, fixed-wing gadgets. That's interesting scientifically, and useful to engineers. But it shouldn't be accepted as an explanation of how birds or bats or insects get their lift.
Relying on untested authorities has a very poor track record, historically. We just had a new case pop up that has gotten a bit of publicity: Someone recently tested the medical benefits of the popular vitamin supplements. It turns out that, unless you have a specific vitamin deficiency disease and take exactly the needed vitamin, they're just placebos, with no measurable affect on health or lifespan. It was just another religious-style scam based on "reasonable" theories, but all it did was extract money from the population for no health payback. It's yet another good example of why we need actual scientific tests of things that "everyone knew years ago". The medical field in particular has a history of this sort of untested "everyone knows" belief system.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. ...
But that isn't reactive; it's still polling. ... you have to type "make [...]" or set up a cron job, you aren't doing reactive.
So who said anything about typing "make"? It's quite common for, e.g. a web CGI program to start a "make" process after the client input has been written to the appropriate files. The CGI program can then proceed or exit, and make's updates will happen in the background. It's also not uncommon to see Makefile commands of the form "cd some/dir; make foo" as part of the update process.
This isn't materially different from a write/assign triggering a cascade of updates via some routine deep down in the system library or OS. Its main advantage is that it gives the programmer better control of exactly when the updates are triggered. In the languages I use for CGI (bash, perl, tcl, python) it's also easy to check for the completion of the "make" process, and you can also get the error messages if you need them. My investigation of "reactive" libraries didn't spot any way to do this, though I could easily have missed it.
Aside from syntax, a set of Makefile entries are conceptually similar to the rules used in a "reactive" language. Which is better probably depends mostly on your application.
I don't remember ever setting up a cron job that does makes, but I'd imagine it could be a practical approach in some cases, when it's not important that the updates be done quickly. I do have one web site that I'm responsible for where the CGI processes finish by checking their process id, and if it's a multiple of 100, run "make clean" to clear out old log files, etc. But this isn't really the same thing. In perl, it's a one-liner: system 'make clean &'.
OTOH, I have seen an annoying problem with a low-level "reactive" tool: Suppose that A depends on B, C and D. If all three change, this tends to trigger three updates of A that overlap. This is at best a waste of CPU time, and it can lead to race conditions in complex dependency trees. Using the "make" approach, if the changes to B, C and D are done by a single process or a set of communicating processes, it's easy to delay the update until all the leaf data has been written, when a single update process can do all the updates. This is much easier to program correctly. Of course, a well-designed reactive library might provide ways to control this, but the result would probably be isomorphic to the "make" approach.
(And firing up a "make" process isn't cheap. It could be useful to have an equivalent process running permanently, with updates triggered by an inter-process message. But this is merely an efficiency gain; it's still logically equivalent to a "make" command.)
We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
This is yet another illustration that the perps who introduced this supposedly-new concept have mostly just found a new buzzword for an approach that has been reinvented repeatedly in the past.
One of the ongoing problems in many fields of science and technology is the constant rediscovery (or reinvention if you prefer) of concepts long known by others that just use different words for the concepts.
Actually, mathematicians long ago realized this, and have a standard term for things that are described differently but are actually identical: They're generally called "isomorphic". A classical example that's important in computers was George Boole's "Boolean algebra", invented primarily as an exercise in pure logic. Eventually people noticed that it was isomorphic to the "propositional calculus", and then as electricity became widely available, engineers found that their new "circuit switching calculus" was another isomorphism. That's why so many programming languages have those AND, OR, XOR, NOT, etc operators.
This crowd is merely giving us another entry in the rather long list of isomorphic systems that differ only in their terminology. This means time wasted re-developing your system from scratch, when you could have saved a lot of time if you'd only realized that others had already solved your problem for you. But we don't have a good way to discover that two systems described with different words really are the same thing.
(Or do we? Maybe some mathematical linguists are working on the problem right now, and we don't realize this because we don't recognize their terminology.)
Next they are gonna to tell me my Fisher Price bath boats are not sufficient for planning naval invasions.
Of course not, don't be silly. Now Lego, that's another matter entirely. Lego is the stuff of military dominance!
So we should be watching Denmark very closely ...
You don't need every driver to understand how a transmission works in order to get their drivers' license, and you don't need every delivery driver to understand routing algorithms to be able to drive their route.
You're right, of course. Except that the topic here isn't about the general population of computer users; it's about teaching maybe 1% of people to develop the software for those computers.
With autos, it's true that 99% of us will never need to understand how a transmission or other internal subsystems work. But if you're considering a career either designing or maintaining vehicles, you'd damned well better be learning about the mechanics (and chemistry and electronics) of their internal mechanisms, or you'll never get a job in the field.
Similarly, drivers might not need to understand routing, but the people who manage the routing system (or the computers that run the routing software) need to understand the topic, or they'll just screw it up. If you want a job developing their routing software, you'd better understand routing algorithms, or the people hiring developers will just laugh at you and toss your resume in the trash.
Most users of computers can do what they want using just a GUI. But we're talking about the future programmers, and if they don't understand the CLI approach as well as the GUI, they'll be crippled as developers. Without understanding both levels of your gadgets' command system, any time it gets flakey, you'll be dependent on the people who do understand the internals to get it working. Either that, or you'll be sold a new gadget because your old one is "broken", although it might have been fixed in a few minutes by someone with full knowledge of how to query its internals.
(This latter point has been important to the spread of unix/linux behind the scenes. You might be impressed to find out how many of the machines behind the Internet started life as DOS/Windows systems, and were discarded by their owners because they no longer "worked". I have two such servers myself. Free cast-off windows boxes are often quite serviceable as gateways/routers/servers when their disk is reformatted with a unix system. I run several web sites on "small, slow" machines no longer usable with Windows, but quite able to handle a million or so web requests per day and still be 90% idle. Most of these don't have a windowing system installed. Right now I have 5 Terminal windows open on this Macbook Pro that are ssh'd into 3 such servers, running OpenBSD, FreeBSD and linux on 10-year-old previously-Windows boxes. Plus one ssh'd into a server machine that was born running Ubuntu. The Macbook has a faster cpu and more memory than any of them, but at 4 years, it's nearing the end of its useful life running OS X and Darwin, and I'll have to replace it soon. Maybe I'll reincarnate it as a linux server. It's overpowered for that job. ;-)
My issue is that I shouldn't need an app to access the same info I can get via a browser on the desktop. Why, if that app does a better job, does it ask for permissions to data it has no need to access?
Duh; one of its important jobs is sending that data back to its mother ship (or to the NSA. ;-)
Doesn't everyone understand that? Are there "smartphone" users dumb enough to think that the app isn't doing such things?
Get a device with a big enough screen, and the internet isn't painful anymore. It's that simple.
Heh. That doesn't always help. A lot of the Internet is painful by design. They make it that way with malice aforethought.
A trivial example in the window I'm typing in right now: There's a horizontal scroll bar at the bottom of this /. window. OK, it has a width= attribute that shouldn't be there that's forcing it to a fixed width, right? Nope. I grabbed one of the resize handles on the window's border, and resized it a few times. No matter what size I made it on my (rather large) screen, the /. window is sized to be slightly wider than that. It dynamically detects the size, and forces the content to be wider.
This is fairly common, and the solution is trivial: Remove all the width= and other size attributes. There's nothing in this /. page that requires such things, and without them, the browser will "flow" the text so that everything fits. But /., like so many sites, tries doing something "clever" (i.e., dumb) with the sizes, and as a result, there's nothing I can do to make it fit.
This is known in legal circles as "with malice aforethought". The developers understand the problem quite well. If they didn't, they wouldn't be smart enough to use HTML in the first place. So they must be doing it intentionally.
And I've seen why this can happen. I've worked on a number of projects that needed a web interface. On many of them, I've gotten explicit orders that the pages must be sized to specific width, so they'll fit in the window the boss wants to use on his desktop. If the boss's desired size isn't the default, it won't be accepted. This sort of idiocy is quite common, and it's not easy to fight.
Actually, I have "fixed" it on a number of projects. These were cases where we had a good reason to have all pages delivered by a CGI program that parses the client's request, runs appropriate data-fetching and -munging subprocesses, and formats the results in HTML. I sneak in a little check of the HTTP_USER_AGENT, and if it's IE (which is the only browser that such bosses know exists), my code generates the required width= attributes; else it produces no sizing instructions at all. The results usually work fine on anything from a dumb "smartphone" to a humongous window on a humongous display. Or a small browser window on your screen, whatever it is. And it meets the boss's requirement for a fixed width on his screen.
So far, I haven't been caught performing such treachery by any of my bosses, but it's probably only a matter of time. They often believe that their web sites need only work on screens exactly like the one on their desk, and they explicitly order their developers to do it that way, or else.
This is just one of the many reasons for the problem we're discussing. It's yet another example of the old one about not attributing something to malice which may be explained by stupidity. (Quick, without googling it, which famous writer is that usually attributed to? ;-)
... you fucking moron, following orders IS ALL A FUCKING COMPUTER CAN DO
Reminds me of that old poem about computers, which ends with the punch line "It never does what I want, only what I tell it".
This was a cliche back in the 1970s at least, perhaps earlier. Ranting about it won't have much effect, because those who understand you will have understood the above all along. The rest simply don't understand what computers are at all.
Unfortunately, a lot of those people are in positions of authority in our governments.
We were human 100000 years ago? Weren't we human-LIKE way back then? I mean, denisovians and Neanderthals weren't human, were they?
Well, if you're talking about the conventional usage of "human" in scientific circles, the answer is: Yes, they were; they just weren't modern humans.
But "human" really isn't a technical term; For that you want something like "Homo" or "hominin", depending on how far back in the tree you want to describe. The term "human" is used informally to mean just about any critters later than the split from the Pan (chimpanzee) branch. It's used when you don't want to be too precise about such things.
OTOH, "human" is widely used in common speech to refer to anyone "not like us". Sometimes it means "white people", especially in writings from before the 20th century. But you don't much hear such usages in scientific settings. You do see it a lot in media coverage of science, but then it means whatever the journalist thinks it means.
... the voting public are fucking morons too damn lazy to know that CONGRESS MAKES THE FUCKING DECISIONS.
You're not nearly the first to make this observation. For another recent example, there's the video of the "reporter" asking people whether the US government shutdown was caused by Obama or Bush. This was a bit of a prank, of course, but they did comment that nobody gave the correct answer: "Neither; it was caused by Congress." Yes, the president has some significant influence in the annual debates over the next year's budget. But, as specified in the US Constitution, only the Congress actually votes on budget bills. It sometimes seems that nobody in the country (not even our Congress critters ;-) knows anything about this.
Considering all of the KGB documents that have recently been made available which reveal how successful they were at infiltrating US institutions, I'm surprised people still hold the opinion they do of McCarthyism.
It's probably because most "US institutions" are organizations that want members who support their goals, and very few such organizations ever do any investigation at all of new members' backgrounds. If you ask a member of most organizations about their investigations, they'll just look at you like you're some sort of weirdo, and perhaps show a bit of nervousness about someone like you who would even mention such things. If you show an interest in the organization's goals, cooperate in their activities, and pay the membership fee, you're accepted as one of them. That's the way normal human organizations work, after all. Only a few extreme political and religious organizations would ever do such investigations. There's a reason we often call them "witch hunts". We understand that they're generally aimed at condemning people without bothering with unnecessary stuff like evidence.
FZ? Frank Zappa? It doesn't sound like a Zappa quote
But if you follow the link, you'll find that's exactly who the quote came from. ;-)
If you determine you don't have the necessary ingredients to begin the process, do you say you quit on the first step, or never started?
Yeah, that's the critical difference in the thinking. My calling the ingredient list "step 0" is based on the thinking that a recipe is something that tells you how make a food item. With this understanding, it makes sense that you'd consider "recipe" to mean only the actions you take that create the food item. If you already had all the ingredients in your kitchen a week ago, you wouldn't say that you started making the recipe last week. Checking the ingredient list makes nothing, so it's not a "step", it's merely a description of required initial conditions. Making the food means what you do in the kitchen when you decide what you want to eat. Buying ingredients earlier (perhaps by months because you know you'll want those ingredients some day) isn't part of making the food item. Deciding not to make a recipe because you lack a critical ingredient doesn't mean you've done the recipe's first step.
OTOH, it's reasonable that you'd interpret the ingredient list as a sort of command (though such lists never contain imperative verbs). It means "First, make sure you have the following ingredients ...." Someone who thinks that way could reasonably label the list as "step 1".
I tend to take the first approach, which is probably related to the fact that I like to keep a lot of non-perishable ingredients on hand for the food items I make often. Thus, I have a couple of bags of flour on a top kitchen shelf, several pounds of butter in a freezer in the basement, etc. I don't think of buying those ingredients as part of making a recipe. Several of the above posters apparently do, perhaps because their approach is to decide on a recipe, and then go buy the ingredients. Nothing wrong with that, if you have some good stores nearby. But it does lead to a different interpretation of that ingredient list at the top of a recipe.
There are plenty of software documentation sets, tutorials, etc, like this one (selected at random), that have Step 0, Step 1, etc.
And that example illustrates the usual reason for starting with step 0: The "zero" step is determining your initial state before you start doing anything. In this case, it's determining whether you should bother going on to step 1, which is pretty common. It's also common to use step 0 to list the material needed by the task.
Probably the most common real-world example is cooking recipes, which typically start with a list of ingredients. That "step" is typically not numbered, but sometimes the actual "steps" to create the food are numbered starting with 1. Or they're just in separate paragraphs, since numbering them isn't actually very useful to carry out the task. In any case, the ingredient list is usually typographically different than the rest of the recipe, and is a description of the required initial state, so it's natural to call it "step 0".
So if the submitter won't doi it, or the slashdot editors won't do it, the next time you read about malware infecting a bunch of users computers don't forget to add "in windows" to the end.
It similar to the advice I ran across years ago: If any news story talks about problems with "computers", you should always add "running MS Windows". If it were any other kind of computer, they would have told you its brand name. Since then, I've been looking for exceptions, where a computer problem bad enough to make the news was on machines using non-MS software. So far the only cases I've run across have always mentioned the brand or the OS name. I keep expecting exceptions, and maybe some day I'll spot one.
Of course buy more of it - hey, 58% + 58% = 116%, doesn't it?????
Yeah, I think you've got it. And it makes perfect sense to the "team leaders" who expect their employees to "give 110%".
And of course execs have admin privs on their PC. They don't know what to do with it, they don't know why they got it, but don't you dare even suggesting taking it from him!
Reminds me of the old observation that you can easily determine someone's software expertise from the log data showing how often they run with elevated (root, admin, whatever) privileges: The two quantities are inversely related.
I recall once impressing some people at a company that I was contracting for, when at a meeting I was asked if I needed root privileges on the machines I was using for testing. I shrugged, and said I didn't think so. When they looked puzzled, I just said that in the few cases I'd needed root privileges, I'd got them for the few minutes that I needed by using the "jcroot" account that I'd created. The IT guys got nervous looks on their faces, implying that they didn't know that was possible; the other developers were just grinning. Some time later, several IT guys showed up and wanted to know how I did it. I showed them how to use one of the exploits that hadn't been fixed on their machines. A few weeks later, they did an "upgrade" that blocked that exploit (but they didn't disable my root account). They didn't ask how many others I knew of. Maybe some of their other developers told them about a few more eventually.
I also spent a bit of time explaining that I've learned it isn't a good idea to work with more privilege than I need. The builtin security stuff is pretty good at preventing you from making dumb "typo" type mistakes that take time to fix. Yeah, this is a bit simplistic, but it's something that they could understand, and might have persuaded a few of them that they didn't need to run routinely as at admin level. Maybe, but probably not.
The difference is, the fighters are hugely complex and bleeding edge. A website is pretty old hat in 2013.
From what I've read, it's actually sorta the opposite. The healthcare.gov site is generally described as a bureaucratic database horror story. Multiple databases, actually, each with its own API (that's poorly documented), each one elsewhere on the Net, with unrealistic response-time "requirements" written by managers with little distributed-DB experience. And no understanding that messages between sites can't move faster than the speed of light.
Funny thing is that I've also read a number of comments recently about the zillions of cases where new decrees from Congress are handled by thousands of government web sites within a day or two. Thus, the recent "shutdown" was handled gracefully by most departments' web sites, and they were back up within a day or so when the people were called back to work.
So it's not that "the government" can't handle building and revising web sites. Thousands of departments are doing it the job routinely, and nobody notices because it usually goes smoothly.
But healthcare.gov by its very nature has attracted the attention of every politician within reach, most of which qualify as PHBs who want their name attached to the results but are otherwise clueless about this InterWeb stuff. The result is a flood of conflicting orders coming down to the grunts doing the actual web-site development, with radical changes appearing in their inboxes daily.
I'm sure that lots of readers here can identify with this situation. How often have the rest of you seen exactly this sort of mess in a corporate setting? I'm sure we can collect a lot of good horror stories. Or we can just go over to The Daily WTF and read about (or submit them) them there.
Yup, and a general response I've seen that I sorta like is: If you can say beforehand what the results of your research will be, then it isn't research, it's engineering. Of course, we need good engineering, too. But first, we have to have the scientific knowledge that good engineering is based on, and that requires scientific research (plus learning from our mistakes ;-).
In general, you can only predict the outcome of something that you know and understand. If you want to extend your knowledge and understanding, you need real research, whose results you can't know until after you've done the research.
Requiring researchers to state beforehand how the results will benefit us has only one effect: It bans actual scientific research. Of course, this might be what is intended.
"Look what the Bible says" only counts as an argument if (a) you can read the original Hebrew/Greek/Latin
Aramaic, you fucktard.
Actually, you'd have to be able to read all four of them, and probably several dialects of each.
Also, you'd have the problem of even finding the original texts. What texts we have, that people mistakenly call "original", date to centuries after the events described. The usual legal term for such long-after-the-facts texts is "hearsay", not "original".
But it's all good as a source of humor, at least until the true believers come looking for you.
... from the real-estate con-men. They must be really excited by the thought of billions of Earth-like planets to sell to the marks.
Daddy lets you look at a slideshow, spot the magically appearing star. Boy genius!
Or, to convert it from an unsubtle put-down to a more accurate description, it's a straightforward example of something that astronomers have long pointed out: Despite being one of the hardest of "hard sciences", astronomy is a field that has always made good use of interested amateurs. This is yet another of thousands of examples.
The typical explanation is that astronomers do much of their work on high-powered equipment that can give them detailed, close-up views of things out there. This is valuable research, but has the problem that such equipment typically has a tiny field of view, so astronomers often miss interesting things that are outside their tiny fields of view. Astronomy needs people doing wider-angle work, comparing images from different times (and maybe different equipment), to spot interesting things. This is often best done by amateurs with lower-powered equipment. They can report their findings to the astronomers, who can aim their high-powered tools at the coordinates to get the details. Amateurs rarely get paid, but astronomers traditionally reward them by naming discoveries after them.
An interesting extension of this in the "Zooniverse" project, ake the "Galaxy Zoo". Look it up. What they do is take images from the petabytes of data supplied by the newer telescopes, show them to volunteers, and ask them to mark various kinds of "interesting" things in the photos. Each of their projects starts with a short training session showing you one or two examples of what they're looking for. Then you dive into a string of random images, marking them up, and sending them back to the project's computers. Currently, they have a set of details in the Andromeda Galaxy (M31) for people to see and mark up.
This development is interesting partly because it's aimed at amateurs with no special equipment other than a personal computer. They've got very good response, from people who want to while away a few hours looking at pretty pictures of the sky and marking them up. Astronomers have said that their volunteers have led to a lot of interesting discoveries. One of the widely-recognized examples was "Hanny's Voorwerp" (look it up ;-), which was discovered by and named for a young woman who is a Dutch school teacher. It has led to several years of work by many astronomers trying to figure out what that thing is.
So, while mocking this kid might be satisfying, it's missing an important point about how some scientific fields actually work. He's probably good enough already to contribute to this effort. As are most of the readers of slashdot.