In case you missed it, the stigma has already been attached. Review, even by the public, will be influenced by that stigma. It cannot get a fair and honest review now regardless of who reviews it. Bias will be applied again by the people who care enough to review it. Either to "right the wrong" or to "prove that the first review was right". And even if someone manages to review it with an open and honest mind free from bias, there will be others who call into question the review because it didn't come to the "right" conclusion.
Unbiased review is a fundamental foundation of this thing we call "science". Maybe you've heard of it.
For all intents and purposes, this research has been ruined.
It's clear that the man who reviewed the paper is blatantly biased. His characterization that the quality of papers from men must, by definition, by higher quality clearly establishes the fact that he is a textbook example of the problem.
Nevertheless, it may also be true that the people submitting the paper were also biased. But we will probably never know. The trouble is, now that it's been exposed that they were rejected by someone who is clearly biased, there is no good way to honestly evaluate the paper and come to any conclusion other than acceptance. If you don't reverse the action of the biased person than you too will be accused of bias. But when the paper is accepted, far too many people will assume it was accepted because of the first review and it will never get a fair shake.
And before anyone gets their knickers in a twist, I'm not suggesting that the paper itself is biased or not. There's no way to know given the limited information. I'm simply commenting on the fact that it will not be able to get a fair and honest appraisal now that it's been engulfed in this controversy. And no matter what the outcome, it will forever have one kind of stigma or another attached to it.
I did all my undergraduate work in Pascal, as did pretty much everyone else in my generation. But that was decades ago and while there was some significant work in Pascal and its derivatives at the time, it's pretty much disappeared from the landscape at this point and is not much more than a footnote in history. It's only real significance is how it influenced what is being used today.
It's not that niche. For those of us who are programmers I'm sure the majority haven't used it. But I'm sure most HAVE at least heard of it!
I think you're significantly overestimating the average slashdotter. Sure, if you went through school and spent much time getting a comp sci degree or the like, you should have been exposed. But outside of that group (which may be your entire world but it's hardly representative of the rest of the world), the chances of people hearing about it are far more slim.
I figured there has been a lot of change. I started school in the 80's and finished in the early 90's so maybe a few years before you. I would have been surprised if the landscape hadn't changed dramatically since then.
Like I say, if it's a tool that you find useful to do real work where that tool is the best one to use and you're not just trying to justify using the tool on anything and everything, it's a good thing to have.
I took a couple of undergraduate symbolic logic classes, including a senior level seminar, offered by the philosophy department in my school. That was probably one of the best things I could have done considering how much boolean algebra I have to sift through in my jobs. I've mostly forgotten my Lisp because it was 25 years ago but I work in a niche industry and I don't find much use for it here. But if I did, I certainly would go back and refresh my knowledge so I could use the right tool for the job.
I'd say it's more troll like to judge people for not knowing about a language that is, at best, obscure and not well known outside of academia and research. After all, this website is full of people who have no reason to have known about an obscure niche language, regardless of it's significance and importance.
I worked with a few functional programming languages when I was in school. And back when I took an intro to AI course, they were using Lisp. Not sure if they're still doing that as I took my career in an entirely different direction and that was a long time ago.
My question to you is, where is functional programming used in the real world? Sure, it's a course you can take in school. But what niches use functional programming and how extensive are they? I mean, I don't see it being useful in anything out of a few very specific areas. I mean, Pascal was a good teaching language for the basics of iterative programming but in the real world, outside of a few people trying to mash that square peg in a round hole, it really didn't see any use outside of academia and is now not much more than an afterthought.
I'm much closer to greybeard than hipster. So don't take this as a smug "we don't need that old crap now" post. Because I've been there and I've done that and my foundation of "that old crap" is what gives me an edge over all of these kids out there who can't program without pretty pictures.
That being sad, I've spent my share of time poking around inside functional languages. Lisp primarily, but I've touched several others. And I have to question your assertion that work in functional programming helps your work in iterative and OO languages. And I'm sure that knowing about functional programming helps in some cases with certain tasks. However, I really do think that the subset of tasks where a functional approach will help is significantly smaller than you think. Quite frankly, I find that the functional programming enthusiast crowd is a group of people who only know how to use hammers and they're trying to convince the world that every problem is a nail.
Of course, because you'll take that the wrong way, I will state clearly that I believe there are a great many problems that could benefit from functional programming. And functional languages are a good tool to have with you all the time. It's just that there's not always a need to take that tool out and use it.
Considering the language was originally developed in the 80's and went basically nowhere, I wouldn't be at all surprised if half or more of the audience here has never heard of it. I'm nearing greybeard status myself and I had completely forgotten about it. And even though I remember the language by name, I couldn't tell you the first thing about how it works. I had to go and wiki it to remind myself where I had seen it before. Sure, it may have had some really keen features and maybe had influence on modern programming, it's a language that has been filed away in the "(almost) nobody uses this" cabinet for a long time now. So I agree with you, there is no reason for your opening post to be thought of as a troll.
I remember some years back that the Ford Excursion Diesel was rated one of the top most fuel efficient vehicles. The caveat was that you had to fill all 9 seats with people. If you did that, your economy per passenger was better than just about every car out there, even a Prius with a full passenger load. Of course, I would usually only see one or two people in them on the road so the real world figures weren't as good as that. But the point being made was that bulk transportation of people was more efficient than individuals driving cars.
But that also underlines another point..
We really didn't need another very expensive study to tell us the very obvious. Of course flying is more efficient than driving, so long as everyone is going from the same origin to the same destination on a direct flight.
One of the things I'm pretty sure they didn't factor in was how far people had to travel to get to the airport before the flight and how far they had to travel to get to their destination afterwords, not to mention what type of transportation they used. Certainly, if you're driving from one airport to another the model holds true. But the farther away from the airport you are before and/or after your flight, the more the numbers can skew. And I'm pretty sure they don't factor in when you have to fly through a hub airport that takes you hundreds of miles out of your way. So if you got a deal on a United ticket and you have to fly from Iowa through Denver's hub on your way to Orlando, I'm pretty sure any fuel efficiency you would have gained on the airplane is negated by the fact that you're going something like 1,500 miles farther than you would have on the drive.
Sure. Just because you apply a design methodology "correctly" doesn't mean you're automatically going to have success. There's a billion other factors that contribute to success or failure. And it's not a binary choice. You can't have only full success or complete failure. It's usually somewhere in between. It may be mostly a success but a failure in a few areas. Or it may be a failure but you can salvage a few gems from what happened. My only point is that one needs to look beyond their own anecdotal experience when evaluating things. It's important to look at other people's experiences to see if they have success or failure.
Except that he's not a creationist. Read it for yourself here. The reason people are getting modded down is because they're saying things that are factually untrue with regards to his stance on evolution and creationism. Hell, a significant portion of the work on advancing the science of evolution has been done by some very prominent Catholics over the years.
Your non sequitur about other issues is irrelevant to the topic at hand so you'd be better off leaving that one out of the discussion.
I'd rather not go on personal anecdotal evidence as a measuring stick to determine whether something is fact or not. I don't have to personally see something to acknowledge that it has, in fact, happened.
There's a difference between "good lord, you're screwing up this implementation" and "good lord, I'm not going to take the time to learn a new way of doing things".
You're underestimating how much crap has come out over the decades. Not following Agile correctly is responsible for only a very small portion of that crap because it hasn't been around long enough to measure up to the tried and true ways of producing crap. It's making a go of it but it started out way behind and hasn't even begun to catch up.
It's been my experience that, like so many other methodologies, there is a disconnect between the methodology and what companies actually do from day-to-day. And while I don't have 30+ years under my belt, I have 20+ years and I've seen quite a bit over the years. Companies can change and improve for the better but a lot of old farts who refuse to keep up with modern advances in the way to accomplish things is one of the biggest impediments in my (not so) humble opinion.
Done correctly for the right kinds of projects, Agile is a good way to do things. Unfortunately, a lot of companies get Agile wrong or they try to apply it to a type of project that is really not suited to it. Too many companies follow the "throw whatever s#!t compiles over the wall every Friday" process and try to pass it off as "Agile". Clearly, they are not really following the Agile methodology and you end up with a big steaming pile since they're often breaking things faster than they're fixing them. And then there are the managers who only focus on half the methodology and you get a disjointed mess that goes off the rails. If you want to succeed, you can't just pick and choose the parts you like and discard the rest. It's a complete system and you need to do it completely.
Then there's the groups that try to apply Agile to the wrong kinds of projects. The larger the project, the less suited it is to being Agile. Of course, that's a good argument for breaking large projects into smaller ones that interact with each other, allowing them to be more suited to Agile. But beyond project size, the more safety-critical the project, the less suited it is to the Agile methodology. I'm pretty sure I don't want Boeing writing their flight control software using the Agile methodology. I'd want the heavy certification process they go through to be much more thorough when validating their systems to ensure that no little bugs slipped through. I mean, it's one thing to have a glitch in your word processor. You might lose a couple hours of work. But a "little glitch" in flight controls can lead to that plane "making premature contact with the ground" which is "bad".
Can IBM improve things with a move to Agile? Maybe. If they do it right. Will they do it right? Hard to say. Changing culture at a big corporation like that is kind of like steering an aircraft carrier. It's going to take some time and it's going to require a lot of effort. My best guess is that the move will be a partial success and the success will vary from department to department.
Sadly, there are some who argue (incorrectly) that the genome is something too complicated to evolve on its own and is therefore proof of instant creation.
Except that high throughput does not necessarily give you lower latency. It usually does but it's not a guarantee. Take satellite connections for example. The bandwidth of the connection you have can vary significantly but getting the radio signals up to the satellite and back again result in high latency, regardless of the bandwidth you have access to.
In general you are correct though. Modern land line networks (regardless of whether the last mile is wireless/phone) typically do not suffer from latency problems unless there's a bottleneck in the network somewhere. And the higher your bandwidth between you and the central office, the lower your latency tends to be (to a point). Unfortunately, service providers like Verizon have shown that they're perfectly happy to put in artificial bottlenecks in furtherance of extortion, both of their customers and of the content sources the customers access. So you can have extremely high bandwidth with very low latency between yourself and your service provider but have terrible performance beyond that.
"Oh, you want better performance when you access a server that's not our competing paid subscription service? We have this much more expensive plan that you can sign up for in order to get the performance you want. Just sign on the dotted line. And oh, by the way, this signs you up for our subscription service as a 'bonus' which is covered by this additional bundling fee. Don't forget that there is a stiff penalty for canceling this multi-year contract... What's that? No. Sorry. You don't get a free reach-around. But we have this great bundle you can sign up for..."
Sadly, the evolution of media distribution away from cable TV to direct streaming is going to cause growing pains like this. While I'm sure it's lucrative for them to be in everyone's "basic" package, the fact that you have to pay for channels you don't watch is exactly why cable TV is on the decline. What ESPN needs to do is to get on the ball and get with the 21st century. There's plenty of revenue stream out there for them selling a streaming service and bypassing broadcast TV altogether.
Slashdot Mirror
In case you missed it, the stigma has already been attached. Review, even by the public, will be influenced by that stigma. It cannot get a fair and honest review now regardless of who reviews it. Bias will be applied again by the people who care enough to review it. Either to "right the wrong" or to "prove that the first review was right". And even if someone manages to review it with an open and honest mind free from bias, there will be others who call into question the review because it didn't come to the "right" conclusion.
Unbiased review is a fundamental foundation of this thing we call "science". Maybe you've heard of it.
For all intents and purposes, this research has been ruined.
It's clear that the man who reviewed the paper is blatantly biased. His characterization that the quality of papers from men must, by definition, by higher quality clearly establishes the fact that he is a textbook example of the problem.
Nevertheless, it may also be true that the people submitting the paper were also biased. But we will probably never know. The trouble is, now that it's been exposed that they were rejected by someone who is clearly biased, there is no good way to honestly evaluate the paper and come to any conclusion other than acceptance. If you don't reverse the action of the biased person than you too will be accused of bias. But when the paper is accepted, far too many people will assume it was accepted because of the first review and it will never get a fair shake.
And before anyone gets their knickers in a twist, I'm not suggesting that the paper itself is biased or not. There's no way to know given the limited information. I'm simply commenting on the fact that it will not be able to get a fair and honest appraisal now that it's been engulfed in this controversy. And no matter what the outcome, it will forever have one kind of stigma or another attached to it.
Probably not now. Even if you could hire both of the people who still code in Ada, they would take a while to write that much code.
What's the current state of those projects?
I did all my undergraduate work in Pascal, as did pretty much everyone else in my generation. But that was decades ago and while there was some significant work in Pascal and its derivatives at the time, it's pretty much disappeared from the landscape at this point and is not much more than a footnote in history. It's only real significance is how it influenced what is being used today.
I probably had my real CS education before you were born, son.
I would suggest that "minimally aware of current trends in CS" is a much higher threshold than you may think. Even on /.
It's not that niche. For those of us who are programmers I'm sure the majority haven't used it. But I'm sure most HAVE at least heard of it!
I think you're significantly overestimating the average slashdotter. Sure, if you went through school and spent much time getting a comp sci degree or the like, you should have been exposed. But outside of that group (which may be your entire world but it's hardly representative of the rest of the world), the chances of people hearing about it are far more slim.
I figured there has been a lot of change. I started school in the 80's and finished in the early 90's so maybe a few years before you. I would have been surprised if the landscape hadn't changed dramatically since then.
Like I say, if it's a tool that you find useful to do real work where that tool is the best one to use and you're not just trying to justify using the tool on anything and everything, it's a good thing to have.
I took a couple of undergraduate symbolic logic classes, including a senior level seminar, offered by the philosophy department in my school. That was probably one of the best things I could have done considering how much boolean algebra I have to sift through in my jobs. I've mostly forgotten my Lisp because it was 25 years ago but I work in a niche industry and I don't find much use for it here. But if I did, I certainly would go back and refresh my knowledge so I could use the right tool for the job.
I'd say it's more troll like to judge people for not knowing about a language that is, at best, obscure and not well known outside of academia and research. After all, this website is full of people who have no reason to have known about an obscure niche language, regardless of it's significance and importance.
I worked with a few functional programming languages when I was in school. And back when I took an intro to AI course, they were using Lisp. Not sure if they're still doing that as I took my career in an entirely different direction and that was a long time ago.
My question to you is, where is functional programming used in the real world? Sure, it's a course you can take in school. But what niches use functional programming and how extensive are they? I mean, I don't see it being useful in anything out of a few very specific areas. I mean, Pascal was a good teaching language for the basics of iterative programming but in the real world, outside of a few people trying to mash that square peg in a round hole, it really didn't see any use outside of academia and is now not much more than an afterthought.
I'm much closer to greybeard than hipster. So don't take this as a smug "we don't need that old crap now" post. Because I've been there and I've done that and my foundation of "that old crap" is what gives me an edge over all of these kids out there who can't program without pretty pictures.
That being sad, I've spent my share of time poking around inside functional languages. Lisp primarily, but I've touched several others. And I have to question your assertion that work in functional programming helps your work in iterative and OO languages. And I'm sure that knowing about functional programming helps in some cases with certain tasks. However, I really do think that the subset of tasks where a functional approach will help is significantly smaller than you think. Quite frankly, I find that the functional programming enthusiast crowd is a group of people who only know how to use hammers and they're trying to convince the world that every problem is a nail.
Of course, because you'll take that the wrong way, I will state clearly that I believe there are a great many problems that could benefit from functional programming. And functional languages are a good tool to have with you all the time. It's just that there's not always a need to take that tool out and use it.
Considering the language was originally developed in the 80's and went basically nowhere, I wouldn't be at all surprised if half or more of the audience here has never heard of it. I'm nearing greybeard status myself and I had completely forgotten about it. And even though I remember the language by name, I couldn't tell you the first thing about how it works. I had to go and wiki it to remind myself where I had seen it before. Sure, it may have had some really keen features and maybe had influence on modern programming, it's a language that has been filed away in the "(almost) nobody uses this" cabinet for a long time now. So I agree with you, there is no reason for your opening post to be thought of as a troll.
I remember some years back that the Ford Excursion Diesel was rated one of the top most fuel efficient vehicles. The caveat was that you had to fill all 9 seats with people. If you did that, your economy per passenger was better than just about every car out there, even a Prius with a full passenger load. Of course, I would usually only see one or two people in them on the road so the real world figures weren't as good as that. But the point being made was that bulk transportation of people was more efficient than individuals driving cars.
But that also underlines another point..
We really didn't need another very expensive study to tell us the very obvious. Of course flying is more efficient than driving, so long as everyone is going from the same origin to the same destination on a direct flight.
One of the things I'm pretty sure they didn't factor in was how far people had to travel to get to the airport before the flight and how far they had to travel to get to their destination afterwords, not to mention what type of transportation they used. Certainly, if you're driving from one airport to another the model holds true. But the farther away from the airport you are before and/or after your flight, the more the numbers can skew. And I'm pretty sure they don't factor in when you have to fly through a hub airport that takes you hundreds of miles out of your way. So if you got a deal on a United ticket and you have to fly from Iowa through Denver's hub on your way to Orlando, I'm pretty sure any fuel efficiency you would have gained on the airplane is negated by the fact that you're going something like 1,500 miles farther than you would have on the drive.
Sure. Just because you apply a design methodology "correctly" doesn't mean you're automatically going to have success. There's a billion other factors that contribute to success or failure. And it's not a binary choice. You can't have only full success or complete failure. It's usually somewhere in between. It may be mostly a success but a failure in a few areas. Or it may be a failure but you can salvage a few gems from what happened. My only point is that one needs to look beyond their own anecdotal experience when evaluating things. It's important to look at other people's experiences to see if they have success or failure.
I am in full agreement with you there. It's not unlike defining your base classes. They can make or break your project before you even get started.
Except that he's not a creationist. Read it for yourself here. The reason people are getting modded down is because they're saying things that are factually untrue with regards to his stance on evolution and creationism. Hell, a significant portion of the work on advancing the science of evolution has been done by some very prominent Catholics over the years.
Your non sequitur about other issues is irrelevant to the topic at hand so you'd be better off leaving that one out of the discussion.
I'd rather not go on personal anecdotal evidence as a measuring stick to determine whether something is fact or not. I don't have to personally see something to acknowledge that it has, in fact, happened.
There's a difference between "good lord, you're screwing up this implementation" and "good lord, I'm not going to take the time to learn a new way of doing things".
It's not a fact.
You're underestimating how much crap has come out over the decades. Not following Agile correctly is responsible for only a very small portion of that crap because it hasn't been around long enough to measure up to the tried and true ways of producing crap. It's making a go of it but it started out way behind and hasn't even begun to catch up.
It's been my experience that, like so many other methodologies, there is a disconnect between the methodology and what companies actually do from day-to-day. And while I don't have 30+ years under my belt, I have 20+ years and I've seen quite a bit over the years. Companies can change and improve for the better but a lot of old farts who refuse to keep up with modern advances in the way to accomplish things is one of the biggest impediments in my (not so) humble opinion.
Done correctly for the right kinds of projects, Agile is a good way to do things. Unfortunately, a lot of companies get Agile wrong or they try to apply it to a type of project that is really not suited to it. Too many companies follow the "throw whatever s#!t compiles over the wall every Friday" process and try to pass it off as "Agile". Clearly, they are not really following the Agile methodology and you end up with a big steaming pile since they're often breaking things faster than they're fixing them. And then there are the managers who only focus on half the methodology and you get a disjointed mess that goes off the rails. If you want to succeed, you can't just pick and choose the parts you like and discard the rest. It's a complete system and you need to do it completely.
Then there's the groups that try to apply Agile to the wrong kinds of projects. The larger the project, the less suited it is to being Agile. Of course, that's a good argument for breaking large projects into smaller ones that interact with each other, allowing them to be more suited to Agile. But beyond project size, the more safety-critical the project, the less suited it is to the Agile methodology. I'm pretty sure I don't want Boeing writing their flight control software using the Agile methodology. I'd want the heavy certification process they go through to be much more thorough when validating their systems to ensure that no little bugs slipped through. I mean, it's one thing to have a glitch in your word processor. You might lose a couple hours of work. But a "little glitch" in flight controls can lead to that plane "making premature contact with the ground" which is "bad".
Can IBM improve things with a move to Agile? Maybe. If they do it right. Will they do it right? Hard to say. Changing culture at a big corporation like that is kind of like steering an aircraft carrier. It's going to take some time and it's going to require a lot of effort. My best guess is that the move will be a partial success and the success will vary from department to department.
Sadly, there are some who argue (incorrectly) that the genome is something too complicated to evolve on its own and is therefore proof of instant creation.
You might want to go look at the Catholic Church's stance on evolution and creation.
Except that high throughput does not necessarily give you lower latency. It usually does but it's not a guarantee. Take satellite connections for example. The bandwidth of the connection you have can vary significantly but getting the radio signals up to the satellite and back again result in high latency, regardless of the bandwidth you have access to.
In general you are correct though. Modern land line networks (regardless of whether the last mile is wireless/phone) typically do not suffer from latency problems unless there's a bottleneck in the network somewhere. And the higher your bandwidth between you and the central office, the lower your latency tends to be (to a point). Unfortunately, service providers like Verizon have shown that they're perfectly happy to put in artificial bottlenecks in furtherance of extortion, both of their customers and of the content sources the customers access. So you can have extremely high bandwidth with very low latency between yourself and your service provider but have terrible performance beyond that.
"Oh, you want better performance when you access a server that's not our competing paid subscription service? We have this much more expensive plan that you can sign up for in order to get the performance you want. Just sign on the dotted line. And oh, by the way, this signs you up for our subscription service as a 'bonus' which is covered by this additional bundling fee. Don't forget that there is a stiff penalty for canceling this multi-year contract... What's that? No. Sorry. You don't get a free reach-around. But we have this great bundle you can sign up for..."
Sadly, the evolution of media distribution away from cable TV to direct streaming is going to cause growing pains like this. While I'm sure it's lucrative for them to be in everyone's "basic" package, the fact that you have to pay for channels you don't watch is exactly why cable TV is on the decline. What ESPN needs to do is to get on the ball and get with the 21st century. There's plenty of revenue stream out there for them selling a streaming service and bypassing broadcast TV altogether.