At the old place where I worked, I had a couple friends that just did porting work. I thought it was ridiculous porting basic things like string manipulations and stacks from one language to another. We simply did it, because languages evolve and needs evolve...and to use something, we often find it easier to rewrite the damn thing in another language.
However, you can't be sure that you did it right during the rewrite. This is where I figured unit tests, if it could be preserved somehow, between ports, would be useful. Then you can run the unit tests against the set of new code, then you can be pretty sure that your new code did what your old code did (at least the stuff you tested for). If there was somewhere, where this type of unit testing existed for basic stuff like stacks, linked lists, time converters, etc. was in a public repository of some sort...then you can run these unit tests every time you had a new piece of code.
Then taking it one step further, I thought then it'd be an interesting reason for humans to NOT write this type of code, since conceivably, you can use genetic algorithms for it. Because when you think about it, unit tests are basically evaluation functions (the environment) for a population of programs. Theoretically, people would ease themselves the burden of rewriting basic well-understood algorithms and data structures, like quicksort and red-black trees, etc.
But the thing I dislike about unit tests is really just how many of them there are. It's mostly because unit tests take one case at a time and test it...case by case. This is where I feel like rigors of mathematics is enviable. Math functions are basically generalizations of a lot of different, but related specific cases. A lot of math statements are succinct ways to declare all cases you'd care about across the board--the times it fails, is when you have piece-wise functions, then you get that funny big "{". If there was a more functional way to express unit tests, that would be an interesting avenue to explore--and save the rest of us on typing.
> First, let’s get the obvious difference out of the way. Mathematics is largely a theoretical field. Sure, we can often apply it to the real world, but where’s the fun in that? The goal is not to produce products for ordinary people, but rather to further mathematics as a subject.
I take serious issue with that statement. Many of the most serious mathematicians refuse to think about problems that don't eventually have an application to the real world. It's just that they do it by mapping the real-world problems onto mathematical abstractions, and then studying the properties of these abstractions. (Example: the three-body problem.)
I take an even more serious issue when a title as 'Save software development' has the following in the second paragraph 'The requirements suck, so the design sucks, so the interaction between modules suck'
What deep thinking
For a lot of younger mathematicians, I understand that an even more important problem is finding two sufficiently close locations that the pragmatic constraints of the two body problem are satisfiable.
(the three body problem is a interesting problem, as problems go)
The other problem with a group karma system is that coders will obsess about it and spend their karma distribution time not writing code and not really getting better as a result of doling out positive karma. And then Sr. Architect X announces hiring of a replacement in the next 6 months and everyone spends 2 hours a day up-modding his/her old code, etc.
Oh and what if I think that nested if statements are easy to follow so I go around dinging you for extracting to methods or using ? : form or something.
Perhaps if you had a really bad-ass coder whose job was to apply karma to code from either lower-tier or less experienced for part of the day, that might work. It provides incentive, it comes from a source of understood quality and authority and it can be accompanied by constructive criticism or substitute code to study. A system like this would have to have a clearly defined goal of rewarding good programming according to some metric or standard.
It's a good germ of an idea, but not a good idea as stated I think.
Nit-pick: "Theorems that have withstood the test of time are falling, one by one; just ask Fermat and Poincaré."
The author means "conjectures", or "open problems" rather than "theorems". Theorems are the end-product of mathematics and do not fall one by one (unless someone finds a mistake in a proof, and a counterexample, which is pretty rare).
In a way this is what the CPAN kwalitee ( http://cpants.perl.org/kwalitee.html) aims at. It is currently rather primitive - but there is quite a bit of brainstorming in the Perl community on how to improve it.
Just to be clear, Reddit (the .com) won't save software development, especially since the author points to a lack of "rigor" as one of the main problems. That site is a bath of noise and juvenile disputes.
Reddit (the template) might, but it's a lot harder to know.
However, you can't be sure that you did it right during the rewrite. This is where I figured unit tests, if it could be preserved somehow, between ports, would be useful. Then you can run the unit tests against the set of new code, then you can be pretty sure that your new code did what your old code did (at least the stuff you tested for). If there was somewhere, where this type of unit testing existed for basic stuff like stacks, linked lists, time converters, etc. was in a public repository of some sort...then you can run these unit tests every time you had a new piece of code.
Then taking it one step further, I thought then it'd be an interesting reason for humans to NOT write this type of code, since conceivably, you can use genetic algorithms for it. Because when you think about it, unit tests are basically evaluation functions (the environment) for a population of programs. Theoretically, people would ease themselves the burden of rewriting basic well-understood algorithms and data structures, like quicksort and red-black trees, etc.
But the thing I dislike about unit tests is really just how many of them there are. It's mostly because unit tests take one case at a time and test it...case by case. This is where I feel like rigors of mathematics is enviable. Math functions are basically generalizations of a lot of different, but related specific cases. A lot of math statements are succinct ways to declare all cases you'd care about across the board--the times it fails, is when you have piece-wise functions, then you get that funny big "{". If there was a more functional way to express unit tests, that would be an interesting avenue to explore--and save the rest of us on typing.