Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Automate Science (Score 1) 613

The simple answer is, who cares? Why should we be trusting science to a bunch of arrogant people that cost too much, live to short, and have such an inefficient method of programming anyway? Science itself is something that should be automated, to create a world where everyone gets to know exactly how to do whatever they want to do, without all the whiny political bs about it? Wah, women can whine about being unemployed just as much as automated men increasingly are.

Comment Re: 23 down, 77 to go (Score 1) 866

Do murderers get their religion before or after committing murder?

For rape and other sexual offenses, research did specifically find religion as a strong "before" factor.
I think there was a specific "before" finding for murder as well, but my recollection on that isn't 100%.

-

Comment Re:Good thing climate change isn't real! (Score 1) 293

My first hit for "Global warming"+"times faster" yields this link: As the Earth moved out of ice ages over the past million years, the global temperature rose a total of 4 to 7 degrees Celsius over about 5,000 years. In the past century alone, the temperature has climbed 0.7 degrees Celsius, roughly ten times faster than the average rate of ice-age-recovery warming.

All the opinions you mentioned are, at best, poorly informed.

-

Comment Re:Pretty sure the heat death of the universe will (Score 2) 386

Are you sure? FooBar() and foobar() are different functions in C but the same function in Fortran, so calling foobar() from C in a fortran-compiled libfb.so is probably not going to have the effect you intended if both FooBar() and foobar() are present in libfb.so, if it is even possible at all (name-mangling might be happening).

I was writing Fortran/C multi-language applications twenty years ago, so yeah, despite a few issues this is easily possible. There was some weirdness, as I recall, because Fortran implicitly pushed the size of arrays onto the stack, so you had to do some fiddling to accommodate them. There were a few other minor issues, but what the GP said is essentially correct: Fortran is link-compatible with C. C++ mangles names, so unless functions are declared with C linkage (extern "C") all bets are off.

Pretty much any language can be interfaced with any other using tools like swig (dunno if anyone still uses that--it's been almost 10 years since I wrote any multi-language code, thankfully).

Comment Re:Why non-conclusive? (Score 1) 65

Personally, when I gamble and end up about 3/4 of a million dollars in the hole, I assume that I lost.

That sounds more like a conclusion than an assumption.

But the question isn't "Who won?" It is: "On the basis of this result what can we say about who will win next time?"

I don't know what kind of measures they used, and there are a couple of links in this discussion to papers pointing out how problematic p-values are, but it is perfectly possible for the weaker competitor to win any given competition. All it requires is that the width of the performance distributions be large enough to give significant overlap between the players.

People who don't understand statistics are baffled by this. They see individual instances, but statistics is about distributions. We can, by measuring instances, make judgements about the distributions they are drawn from, and knowing about the distributions we can make predictions about future instances.

In the present case, it appears that the observed distribution of performance was such that it wasn't possible to distinguish clearly between the case where the computer is slightly better than the humans but the humans got lucky, and the case where the humans are definitely better than the computer.

Comment Re:Around the block (Score 5, Insightful) 429

I may not know "what works", but I sure do know what won't.

Age is not a great arbiter of such things, but it's still true that without age there are some experiences that are hard to get.

I remember when "structured programming" was the silver bullet du jour. Then it was OO. Then it was Java (this is hard to believe, but really, Java was touted as the solution to all our ills, and people believed it for a while, rushing out to re-write perfectly good code in Java and frequently ruining it in the process) Today it's FP.

All of these, except maybe Java, brought some real good to the table. There were a variety of side-trends that never really got off the ground, at least as silver bullets, like 5GLS, whatever they are.

An older developer has had the opportunity to watch these decade-long trends and make better judgements about the curve of adoption. Will Haskell ever become a mainstream language? Nope, although it'll be used in some niche areas, the way SmallTalk still is. Will FP techniques and ideas filter in to all kinds of other languages? Well, duh. Already happening. Is it worth learning a little Haskell and maybe come category theory? Sure. You can do that even while thinking the claim "apart from the runtime, Haskell is functionally pure" is precisely as impressive as the claim "apart from all the sex I've had, I'm a virgin."

Not all older developers will get any utility out of their experience. Some become cynical and dismissive. A very, very few retain their naive enthusiasm for the Next Great Thing. But many of them have a nuanced and informed attitude toward new technology that makes them extremely valuable as the technical navigator for teams they're on.

Comment Re:Depends how you evaluate the curve (Score 4, Insightful) 425

If you're looking for people who generate a profit from their time, the curve is almost certainly U-shaped based on my now not-so-light 30+ years in the trenches.

The skill distribution doesn't have to be U-shaped to produce a U-shaped distribution. All there has to be is a threshold of skill that must be reached to perform effectively: http://www.tjradcliffe.com/?p=...

I liken this to a wall-climbing task in an obstacle course: some combination of height/weight/strength is necessary to get over the wall. If you measure them individually you'll see broad distributions with soft correlations with ability to get over the wall (because short/strong/light people will be able to do it and tall/strong/heavy people will be able to do it, but short/strong/heavy people won't and tall/weak/light people won't, etc). The wall-climbing task requires the right combination of a small number of such skills to be over some threshold. This trivially (as the simple model in the link shows) generates the observed U-shaped distribution in programming outcomes.

People who claim that anyone can be taught to code well enough to pass a first year computer science course have the opportunity to make a very simple, compelling argument in favour of their thesis: tell us how to teach people to program! If you can do that--if you can get rid of the U-shaped mark distribution that has been documented in first year computing for decades despite all kinds of efforts to understand and deal with it, your argument will be made. Everything else is just hot air: ideological and unconvincing.

There are certain things we know do not cause the bimodal mark distribution in first year computing:

1) Bad teaching (because the issue has been researched and any number of caring, intelligent teachers have thrown themselves at it, and anyone's sucky first year computing prof does not disprove this)

2) Language (because the bimodal mark distribution persists in all languages)

3) Years of coding experience of incoming students (because if that were the case it would have been identified as the differentiator in the decades of research that have gone into this: someone with no coding experience can do as well as someone with years... if they are over some threshold of skill.)

So while it's fun to watch equalitarian ideologues tub-thump this issue, they unfortunately bring nothing to the discussion but ideological blather. The U-shaped, bimodal, mark distribution in first-year computing is robust evidence of a threshold of some kind that people have to be over to code well. There may be other thresholds higher up the scale (I've seen estimates that 25% of coders will never get OO... god knows what the figure is for FP, which I'm still struggling with myself.) But the claim "It would be dreadful if everyone can't code!" is not an argument, it's an emotional outburst, and we need to focus on the data, not the way we wish the world is.

Personally, I would love it if we could figure out how to teach coding better. I see journalists, economists, politicians, business-people, all sorts who are dependent on coders to help them out on the most rudimentary questions. If we could teach everyone to code the level of data-driven discourse would go through the roof. But I'm not counting on that happening any time soon.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Working...