Just because you don't know how to do it, doesn't make it impossible or wrong.
It's wrong in principle. As you can see from your own explanations, you don't know how it can be done either. The reason, of course, is that it's a complete absurdity.
Again, it seems that you've confused 'a solution that meets the requirements' with 'the best possible solution'. I'm not sure if you're actually still confused, or just too ashamed to admit that you misread my original post.
You destroyed your own argument.
By financially and scientifically rewarding, Knuth is referring to the benefits of computer programs to science and industry.
This isn't ambiguous. I'd suspect that you're being intentionally obtuse, but I can't give you that much credit.
By that definition, everything is art.
You think everything is a skilled craft? I'm sorry, I must simply disagree with you outright as I can't comprehend the confusion of ideas that would provoke such a response. All I can do is direct you to the nearest dictionary. You can write an angry letter to the publisher if you're still having trouble.
I was being modest and only brought it up because of your continuing slight against my intelligence and qualifications on the subject.
I thought I was being rather nice, considering what you've offered here. I had you pegged as a trade-school dropout after your impossibly incompetent reading of the Knuth quote. Just look at your own posts. They are clearly not the product of an educated person!
Your bashing of weighted variables just shows your ignorance in both math and science.
That you need to make trade-offs, balancing both quantitative and qualitative variables, should indicate to you that the entire concept of a "best possible solution" is absurd. Revisit my earlier posts for more detail. We've been over this already. I can only repeat myself so many times.
All you've told me is that you can produce a solution that meets some requirements. That's not in dispute. Nor is it terribly interesting. We're after the mythical "best possible solution" you've been on about.
On math, science, and art:
Yes, you use math in development, but that does not make programming mathematics any more so than carpentry! Equally, while you may use some of the methods associated with science in programming, that does not make programming a science any more than auto repair, which also employees those same methods.
Both of those are examples of skilled trades. The largest distinctions between those and programming are the cultural assumptions we apply to their practitioners. I suspect that the social advantages afforded computer programmers is what leads to that delusional thinking.
When I refer to programming as an 'art' I mean that in the sense that programming is a skilled craft. From the preface to Knuth's The Art of Computer Programming:
The process of preparing programs for a digital computer is especially attractive because it not only can be economically and scientifically rewarding, it can also be an aesthetic experience much like composing poetry or music. This book is the first volume of a seven-volume set of books that has been designed to train the reader in the various skills which go into a programmer's craft.
I'm not offering a unique perspective here, but one long-established. It's frustrating to the neopositivists, but they also want to see programming become more like engineering. In that sense, even they acknowledge the nature of computer programming, despite their otherwise delusional thinking.
Not that you need to know my qualifications
It's just a game, for fun. I'm going to guess "2-year trade school" given that you claim a "formal background in programming" because I can't see that meaning anything else.
We clearly need to get back on track. The source of this conflict:
In programming there is a best possible solution to the given problem.
You now know that this assertion is complete nonsense. That was my entire point. It's been made. You admit as much with nonsense like this:
As for memory vs speed vs readability, you can weight requirements making them more or less important and there by altering the target optimal performance.
Read that again: "altering the target optimal performance" The word "optimal" there loses all meaning. It should read as simply "target performance". There is either an optimal solution or there isn't. Why not just say "the best possible solution is whatever I say it is". It's more honest, and just as convincing!
On science, you give this silliness:
Lets take a quick look at the definition of science: systematic knowledge of the physical or material world gained through observation and experimentation.
Science is many things. You define science as a body of knowledge. Science can also be defined as a method of inquiry, as a community, and simply to mean 'the study of'. I expect middle-school kids to understand something that basic.
The "science" part of "computer science" is science in 'the study of' sense. As a discipline, it's essentially a branch of mathematics.
Do you honestly sit in dev meetings and when asked why you did something respond with "because its art man"?
You also don't seem to understand what is meant by 'art'. I'm going to guess you're an autodidact. Am I right? I can't imagine that an educated person would make such an absurd statement.
The best possible solution would have 100% code coverage of unit tests, be 100% documented, 100% rules compliance on top of being the fastest, lowest memory consuming solution possible.
How disappointing. At least you tried. How do you know that your solution is the fastest, lowest memory solution possible? How do you know that your "best practices" are really the "best" and that there aren't better options?
Since you mention it, how do you know that the language or platform selected is capable of producing the optimal solution? You mention using Java a good bit, so you know that you're already adding a lot of overhead and thus very unlikely to produce a mythical "best possible solution" given your performance and memory requirements.
See, there is no such thing as the "best possible solution". What you're describing is an "acceptable solution" given a set of constraints, many of which (like your silly "best practices" which change with incredible frequency) are just folk-wisdom. They're not scientific, mathematical, or objective in any way. Your other constraints (memory and speed) are impossible to meet as you can't tell if there is a faster solution that uses less memory.
Instead of trying to win an argument here, reflect a bit. Particularly on how readability factors in to your above criteria. Are those criteria subjective or objective? Can they be measured? Are you really measuring what you think you're measuring or do your methods merely quantify something you believe to be related? On things like memory and cycles, how do you know that they are as low as possible and that there aren't different approaches that you could use to minimize those?
Further, when you trade memory for speed or speed for readability how do you know that your decision will lead you closer to this alleged "best possible solution"?
In programming there is a best possible solution to the given problem.
Nonsense. Though that silly belief is a big part of the delusion.
There are a lot of factors to consider when writing a computer program. Some (but not all) of those factors can be quantified. How best to balance those is also deeply subjective. For example, is a fast program that uses little memory but is difficult to read and maintain better or worse than a fast program that uses more memory but is easy to read and maintain?
I don't know that I really need to explain this further. It's pretty obvious that there is no such thing as a "best possible solution" to a given programming problem. To believe otherwise is, quite simply, delusional.
Don't be foolish. Dogmatic adherence silly acronyms at the expense of readability is a bad thing. You often end up with more code, not less, trying to avoid any and all redundancy. If it's cleaner and easier to read and maintain, it's worth the exchange.
Let's look at your justification for your dogmatism:
If the other person does not even look for the second check then you now have broken code.
What you've written here, is that if a developer makes a mistake modifying code they don't understand, you'll have broken code. It doesn't look that strong now, does it?
Further, I'd argue that adding more, likely more complicated, code to avoid a tiny bit of redundancy is far more likely to bring about those circumstances where a developer is going to modify code they don't fully understand.
Have you ever played code golf? The idea is to make the shortest possible program that meets some requirement. The most common strategy is to start with a normal implementation and then find ways to reduce the codes size. Essentially, it's about eliminating redundancy. The results look really impressive, short and compact code that does a lot. They're also impossible to read and maintain!
What I'd challenge you to do is find some short bit of code you've written that you think is particularly good, then play code golf to reduce its size. I can guarantee that you'll find plenty of redundancy in function of which you can take advantage to reduce the code size. I'll also guarantee you that your code will be less readable and far more difficult to maintain.
If you really are a born-again acronymist, you'll happily take DRY to its absurd conclusion and golf your way to an unmaintainable nightmare. My guess is that you'll quickly come to your senses and realize that DRY is really just a bit of folk wisdom. It's good to avoid a lot of redundancy (somethings things should be made more generic) but that it's not truy evil, and can sometimes be helpful. Particularly when it makes your code easier to read.
Speaking of making code generic, that's not always a good thing either. You've probably seem this yourself, where a programs size and complexity were dramatically increased by trying to make everything as generic as possible (usually justified as making the code 'reusable'). While a joke, FizzBuzz Enterprise Edition makes my case here nicely.
Keeping code simple and readable is far more important than any fly-by-night acronym you'll run across.
No, it's not science. (It doesn't even remotely resemble science!) Neither is it an application of science, for obvious reasons. I'll maintain that it isn't mathematics or an application of mathematics as well, as while some math is used, it's not where the developers effort is focused. (If you don't like that, ask yourself why there isn't an algebra for computer programs.)
It's more in line with arts and crafts. You'll find far more similarities to painting or sculpting in programming than you will mathematics or science. Interestingly, you'll use quite a bit of math is both painting and sculpting. (You may even find some applied science in those.)
It's just delusional thinking to make some developers feel better about themselves. Consider how many developers don't understand basic logic, despite believing that logic is a fundamental aspect of the work that they do! You might be one yourself. Grab an undergraduate textbook on logic and give it a go. You may find yourself surprised.
Oddly enough, I've seen that cause more problems than it's solved.
It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.
Even when used correctly, I've seen some pretty impressive code-contortions to avoid even a very small amount of duplicate code. Sometimes, it's okay to just do a check twice. As long as the code is easy to read and modify, you're fine. Really.
But that's the problem with programming, isn't it? It's little more than wishful thinking and folk-wisdom. That would be okay (it's an art, after all) but too many developers have deluded themselves in to thinking it's more in-line with mathematics or engineering. They've convinced themselves the cute little acronyms they repeat to one another have some objective, rational, basis and must be obeyed at all cost.
Retired, my home is what amounts to a small castle (ex-church), multiple vehicles, 200" home theater, no mortgage, no loans, investments a-plenty, two wholly owned, profitable businesses that run themselves, and the software that put me here now available for free to anyone...
Okay. Good for you? What does that have to do with the silly point you were making?
Moving on to something relevant: $7k isn't exactly a big return over a period as short as two-months. Even $47k over a year isn't great working for yourself, by yourself, in most places. It could be okay if you live in an area with a low cost-of-living, you were single, worked out of your home, and didn't need health insurance.
If you hire anyone, expect that 7k to vanish in short order. Even at $47k, you'd be lucky to pay a second developer for more than a few months, even at a very low rate.
The point? The "hidden assumption" that development takes a year is nonsense.
You miss the point that people whose brains work in a specific way are more likely to enjoy and want to programming computers.
I didn't miss it, it's just total nonsense. I'd call it wishful thinking from socially inept basement-dwellers. They get to pretend that their poor hygiene and lack-of-success with women indicates that they're really super-programmers.
No, I was making fun of you. See, you believe that programming is just too difficult for women yet believe that the mentally challenged are qualified. I'm pointing out that it's easier than it has ever been -- a point to which you're sure to agree as you hold the absurd belief that mentally handicapped people are attracted to the profession.
It is possible that you're a mentally disabled programmer, and simply believe that your personal experience is common. That I'll believe.
Here's a third possibility: Women are generally less interested in computer science.
No. That's the problem. The question here is "why?"
My guess? The industry is a cesspit. It's hostile to all, but to women in particular. Hobbyist communities, online forums, and (particularly) OSS projects are even worse. It sucks for men, sure, but it sucks even more for women.
Think about the shitheads that make your workplace a living hell. Now imagine that, while you're physically weaker, they're also making unwanted sexual advances and, possibly on occasion, "accidentally" groping you. On top of all that, regardless of your actual performance, you're considered to be half as good as the worst guy on the team.
A fitting prelude to your post. At least you were honest about what followed. In case you were actually serious:
Neither autism nor any of the particular metaphysical assumptions you offer are relevant to the topic.
Further, while it's true that the average computer programming job in the 1960's is different than it is today, it's gotten significantly easier. So simple, in fact, that many mentally handicapped men, as you point out, opt for a career in programming.
Slashdot Mirror
You're deeply confused.
Evidence? Because I don't see any.
Social Justice Warrior. It's a term used by bigots to denigrate anyone who thinks that disadvantaged groups should have equal opportunity.
No doubt. The poor personal hygiene alone could cripple them.
I'm glad to see things are finally getting back to normal around here.
Just because you don't know how to do it, doesn't make it impossible or wrong.
It's wrong in principle. As you can see from your own explanations, you don't know how it can be done either. The reason, of course, is that it's a complete absurdity.
Again, it seems that you've confused 'a solution that meets the requirements' with 'the best possible solution'. I'm not sure if you're actually still confused, or just too ashamed to admit that you misread my original post.
You destroyed your own argument.
By financially and scientifically rewarding, Knuth is referring to the benefits of computer programs to science and industry.
This isn't ambiguous. I'd suspect that you're being intentionally obtuse, but I can't give you that much credit.
By that definition, everything is art.
You think everything is a skilled craft? I'm sorry, I must simply disagree with you outright as I can't comprehend the confusion of ideas that would provoke such a response. All I can do is direct you to the nearest dictionary. You can write an angry letter to the publisher if you're still having trouble.
I was being modest and only brought it up because of your continuing slight against my intelligence and qualifications on the subject.
I thought I was being rather nice, considering what you've offered here. I had you pegged as a trade-school dropout after your impossibly incompetent reading of the Knuth quote. Just look at your own posts. They are clearly not the product of an educated person!
Your bashing of weighted variables just shows your ignorance in both math and science.
That you need to make trade-offs, balancing both quantitative and qualitative variables, should indicate to you that the entire concept of a "best possible solution" is absurd. Revisit my earlier posts for more detail. We've been over this already. I can only repeat myself so many times.
All you've told me is that you can produce a solution that meets some requirements. That's not in dispute. Nor is it terribly interesting. We're after the mythical "best possible solution" you've been on about.
On math, science, and art:
Yes, you use math in development, but that does not make programming mathematics any more so than carpentry! Equally, while you may use some of the methods associated with science in programming, that does not make programming a science any more than auto repair, which also employees those same methods.
Both of those are examples of skilled trades. The largest distinctions between those and programming are the cultural assumptions we apply to their practitioners. I suspect that the social advantages afforded computer programmers is what leads to that delusional thinking.
When I refer to programming as an 'art' I mean that in the sense that programming is a skilled craft. From the preface to Knuth's The Art of Computer Programming:
The process of preparing programs for a digital computer is especially attractive because it not only can be economically and scientifically rewarding, it can also be an aesthetic experience much like composing poetry or music. This book is the first volume of a seven-volume set of books that has been designed to train the reader in the various skills which go into a programmer's craft.
I'm not offering a unique perspective here, but one long-established. It's frustrating to the neopositivists, but they also want to see programming become more like engineering. In that sense, even they acknowledge the nature of computer programming, despite their otherwise delusional thinking.
Not that you need to know my qualifications
It's just a game, for fun. I'm going to guess "2-year trade school" given that you claim a "formal background in programming" because I can't see that meaning anything else.
We clearly need to get back on track. The source of this conflict:
In programming there is a best possible solution to the given problem.
You now know that this assertion is complete nonsense. That was my entire point. It's been made. You admit as much with nonsense like this:
As for memory vs speed vs readability, you can weight requirements making them more or less important and there by altering the target optimal performance.
Read that again: "altering the target optimal performance" The word "optimal" there loses all meaning. It should read as simply "target performance". There is either an optimal solution or there isn't. Why not just say "the best possible solution is whatever I say it is". It's more honest, and just as convincing!
On science, you give this silliness:
Lets take a quick look at the definition of science: systematic knowledge of the physical or material world gained through observation and experimentation.
Science is many things. You define science as a body of knowledge. Science can also be defined as a method of inquiry, as a community, and simply to mean 'the study of'. I expect middle-school kids to understand something that basic.
The "science" part of "computer science" is science in 'the study of' sense. As a discipline, it's essentially a branch of mathematics.
Do you honestly sit in dev meetings and when asked why you did something respond with "because its art man"?
You also don't seem to understand what is meant by 'art'. I'm going to guess you're an autodidact. Am I right? I can't imagine that an educated person would make such an absurd statement.
The best possible solution would have 100% code coverage of unit tests, be 100% documented, 100% rules compliance on top of being the fastest, lowest memory consuming solution possible.
How disappointing. At least you tried. How do you know that your solution is the fastest, lowest memory solution possible? How do you know that your "best practices" are really the "best" and that there aren't better options?
Since you mention it, how do you know that the language or platform selected is capable of producing the optimal solution? You mention using Java a good bit, so you know that you're already adding a lot of overhead and thus very unlikely to produce a mythical "best possible solution" given your performance and memory requirements.
See, there is no such thing as the "best possible solution". What you're describing is an "acceptable solution" given a set of constraints, many of which (like your silly "best practices" which change with incredible frequency) are just folk-wisdom. They're not scientific, mathematical, or objective in any way. Your other constraints (memory and speed) are impossible to meet as you can't tell if there is a faster solution that uses less memory.
Instead of trying to win an argument here, reflect a bit. Particularly on how readability factors in to your above criteria. Are those criteria subjective or objective? Can they be measured? Are you really measuring what you think you're measuring or do your methods merely quantify something you believe to be related? On things like memory and cycles, how do you know that they are as low as possible and that there aren't different approaches that you could use to minimize those?
Further, when you trade memory for speed or speed for readability how do you know that your decision will lead you closer to this alleged "best possible solution"?
Something like sonar can easily quantify your readability and adherence to coding standards.
Okay, I'll play. What coding standards are necessary to achieve the "best possible solution" for a given problem? How were these determined?
If you'd rather: How can we determine that we've arrived at the "best possible solution"?
In programming there is a best possible solution to the given problem.
Nonsense. Though that silly belief is a big part of the delusion.
There are a lot of factors to consider when writing a computer program. Some (but not all) of those factors can be quantified. How best to balance those is also deeply subjective. For example, is a fast program that uses little memory but is difficult to read and maintain better or worse than a fast program that uses more memory but is easy to read and maintain?
I don't know that I really need to explain this further. It's pretty obvious that there is no such thing as a "best possible solution" to a given programming problem. To believe otherwise is, quite simply, delusional.
Don't be foolish. Dogmatic adherence silly acronyms at the expense of readability is a bad thing. You often end up with more code, not less, trying to avoid any and all redundancy. If it's cleaner and easier to read and maintain, it's worth the exchange.
Let's look at your justification for your dogmatism:
If the other person does not even look for the second check then you now have broken code.
What you've written here, is that if a developer makes a mistake modifying code they don't understand, you'll have broken code. It doesn't look that strong now, does it?
Further, I'd argue that adding more, likely more complicated, code to avoid a tiny bit of redundancy is far more likely to bring about those circumstances where a developer is going to modify code they don't fully understand.
Have you ever played code golf? The idea is to make the shortest possible program that meets some requirement. The most common strategy is to start with a normal implementation and then find ways to reduce the codes size. Essentially, it's about eliminating redundancy. The results look really impressive, short and compact code that does a lot. They're also impossible to read and maintain!
What I'd challenge you to do is find some short bit of code you've written that you think is particularly good, then play code golf to reduce its size. I can guarantee that you'll find plenty of redundancy in function of which you can take advantage to reduce the code size. I'll also guarantee you that your code will be less readable and far more difficult to maintain.
If you really are a born-again acronymist, you'll happily take DRY to its absurd conclusion and golf your way to an unmaintainable nightmare. My guess is that you'll quickly come to your senses and realize that DRY is really just a bit of folk wisdom. It's good to avoid a lot of redundancy (somethings things should be made more generic) but that it's not truy evil, and can sometimes be helpful. Particularly when it makes your code easier to read.
Speaking of making code generic, that's not always a good thing either. You've probably seem this yourself, where a programs size and complexity were dramatically increased by trying to make everything as generic as possible (usually justified as making the code 'reusable'). While a joke, FizzBuzz Enterprise Edition makes my case here nicely.
Keeping code simple and readable is far more important than any fly-by-night acronym you'll run across.
No, it's not science. (It doesn't even remotely resemble science!) Neither is it an application of science, for obvious reasons. I'll maintain that it isn't mathematics or an application of mathematics as well, as while some math is used, it's not where the developers effort is focused. (If you don't like that, ask yourself why there isn't an algebra for computer programs.)
It's more in line with arts and crafts. You'll find far more similarities to painting or sculpting in programming than you will mathematics or science. Interestingly, you'll use quite a bit of math is both painting and sculpting. (You may even find some applied science in those.)
It's just delusional thinking to make some developers feel better about themselves. Consider how many developers don't understand basic logic, despite believing that logic is a fundamental aspect of the work that they do! You might be one yourself. Grab an undergraduate textbook on logic and give it a go. You may find yourself surprised.
I'd never trade readability for "elegance" or, worse, "performance".
Code golf may be fun, but it needs to be kept very far away from everything outside those games.
Oddly enough, I've seen that cause more problems than it's solved.
It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.
Even when used correctly, I've seen some pretty impressive code-contortions to avoid even a very small amount of duplicate code. Sometimes, it's okay to just do a check twice. As long as the code is easy to read and modify, you're fine. Really.
But that's the problem with programming, isn't it? It's little more than wishful thinking and folk-wisdom. That would be okay (it's an art, after all) but too many developers have deluded themselves in to thinking it's more in-line with mathematics or engineering. They've convinced themselves the cute little acronyms they repeat to one another have some objective, rational, basis and must be obeyed at all cost.
It's silly, really.
Retired, my home is what amounts to a small castle (ex-church), multiple vehicles, 200" home theater, no mortgage, no loans, investments a-plenty, two wholly owned, profitable businesses that run themselves, and the software that put me here now available for free to anyone...
Okay. Good for you? What does that have to do with the silly point you were making?
Moving on to something relevant:
$7k isn't exactly a big return over a period as short as two-months. Even $47k over a year isn't great working for yourself, by yourself, in most places. It could be okay if you live in an area with a low cost-of-living, you were single, worked out of your home, and didn't need health insurance.
If you hire anyone, expect that 7k to vanish in short order. Even at $47k, you'd be lucky to pay a second developer for more than a few months, even at a very low rate.
The point? The "hidden assumption" that development takes a year is nonsense.
Whatever helps you sleep better at night.
You miss the point that people whose brains work in a specific way are more likely to enjoy and want to programming computers.
I didn't miss it, it's just total nonsense. I'd call it wishful thinking from socially inept basement-dwellers. They get to pretend that their poor hygiene and lack-of-success with women indicates that they're really super-programmers.
You're confused because all you see are monopolies and near-monopolies. Don't panic. That's what an under-regulated free market naturally produces.
The assumption it takes a year to put out an app.
Let's look at that again:
between $7,000 to $47,000
"$7,000" ... "The assumption it takes a year"
I highly recommend that you talk to HR about your compensation.
icrosoft panicked and claimed that iPads weren't "real computers"
Well, they were right. They're still right. Just head-to-head the iPad against something like the Surface Pro and you'll see why they mean.
So it is relevant then. Hmm.
No, I was making fun of you. See, you believe that programming is just too difficult for women yet believe that the mentally challenged are qualified. I'm pointing out that it's easier than it has ever been -- a point to which you're sure to agree as you hold the absurd belief that mentally handicapped people are attracted to the profession.
It is possible that you're a mentally disabled programmer, and simply believe that your personal experience is common. That I'll believe.
Here's a third possibility: Women are generally less interested in computer science.
No. That's the problem. The question here is "why?"
My guess? The industry is a cesspit. It's hostile to all, but to women in particular. Hobbyist communities, online forums, and (particularly) OSS projects are even worse. It sucks for men, sure, but it sucks even more for women.
Think about the shitheads that make your workplace a living hell. Now imagine that, while you're physically weaker, they're also making unwanted sexual advances and, possibly on occasion, "accidentally" groping you. On top of all that, regardless of your actual performance, you're considered to be half as good as the worst guy on the team.
Does that sound like your dream job?
Not exactly. Well, not even close!
While it's true that most women have similar opportunities, they also face dramatically different obstacles.
People like you, for example.
This is nonsense.
A fitting prelude to your post. At least you were honest about what followed. In case you were actually serious:
Neither autism nor any of the particular metaphysical assumptions you offer are relevant to the topic.
Further, while it's true that the average computer programming job in the 1960's is different than it is today, it's gotten significantly easier. So simple, in fact, that many mentally handicapped men, as you point out, opt for a career in programming.