And apps. I hate flashing ads, I always pay the extra to be left alone. But I wonder, how many have fake, extra annoying ads? It's almost like extortion.
But as technology progresses, I can see a future where AI and facial recognition and this targeted sound will torment every person, everywhere they go. The more recent Time Machine movie showed a bit of this.
Age discrimination is rampant and yet illegal. Corporations ought to be fined for having a workforce younger than the average age of the country's citizens. That would help people like the man in this article.
But I wonder, at 64, hasn't he applied for Social Security? It wasn't mentioned. It's not much, but it's better than nothing.
These replies were not what I expected. Practice, practice, practice is not necessarily good advice if you don't know what you're doing. Before I took college programming classes I was self taught and wrote what I later learned was called "spaghetti code." I had no idea (before the classes) who was giving me good advice and who was giving me bad advice. My code was unorganized and a total mess.
In my class, our textbook was "The Elements Of Programming Style" by Kernighan and Plaugher. As far as I'm concerned, it is THE book for beginning programmers. It's rare and expensive now, but worth it.
In a nutshell, it taught:
- program in a direct way, do NOT try to be clever and code in weird, complex ways. Your code (not just the comments) needs to be readable to others, what it does should be evident. (The book gave examples of both, and after looking at a number of these examples, you get the idea of what K&P mean by ELEGANT programming.)
- Subroutines must have one entry point and one exit point, and accomplish one task.
- Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.
These are just a few examples of good programming practice. I later became a professional programmer, using assembly language and C++. But that first college book was the one that outshone all the later ones that I read. Get it if you can find it!
I would also highly recommend Dennis Ritchie's books.
One more thing - object oriented programming is good, but I'm not sure it's paradigm will win out in the end. As an assembly language programmer, I began to realize the power of data driven programming, and I began to write my programs in that way. Which is why I think this new language, Julia, holds a lot of promise. I say this as one who has only read ABOUT Julia, not as one who has studied the language itself.
> Practice, practice, practice is not necessarily good advice if you don't know what you're doing.
Your example is good about learning good program structure; that can save you a lot of time. You can only learn so much that way though. Sometimes you just have to make mistakes.
I've written a lot of code that is bad. But if I hadn't written that code and I was tasked to do again I'd do it the same way because there is no other experience to tell me not to do that. My sum knowledge of programming is everything I learned from school and from reading -- but the majority comes from actually writing a whole lot of crap.
It's interesting but in my experience:
> Subroutines must have one entry point and one exit point, and accomplish one task.
My subroutines almost always exit early at the top if any pre-conditions fail to be met. This is much better than a ton of nested if statement for each pre-condition. But in general it's best not to exit somewhere in the middle.
> Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.
In practice, comments are pretty hard to maintain. I usually ask new applicants how they ensure a project can easily be passed off to others and if they just answer comments then that's generally a bad sign. Good hires will often laugh when mentioning comments and then describe other things like good naming, etc.
> - Subroutines must have one entry point and one exit point, and accomplish one task.
Sometimes code is much cleaner if you exit a method or a function early. Especially in languages with automatic memory management where you don't need to concern yourself about leaks so much.
> - Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.
Lots of comments is a red flag to me. It often indicates the code itself is of poor readability. But it's usually easier to just slap some comment on it than to properly rewrite it... "A comment is a failure to express yourself in code" (Uncle Bob).
> These are just a few examples of good programming practice
I'd argue they are debatable, and at the very least not necessarily universal.
I put a lot of comments in my code, but not to explain what the code does, moreso to explain why it is doing what it is doing, what it used to do and why it changed, and what else I think it could do instead of what it is.
About the comments, by no means do I mean that comments can be a crutch and should allow for sloppier coding, but sometimes the problem that you're trying to solve requires a lot of brainstorming, and when you hit your "aha" moment, you'd better write down what your thinking is, in English. The code itself might be pretty hairy to go over and decipher if that's all you've left yourself.
But I get what you mean, and you make a valid point.
Sometimes code simply cannot speak for itself, and then a comment is very welcome, sure.
What I learned though is that a lot of programmers suffer from a form of a "comment blindness". I was once asked to explain a piece of code for which I already provided that exact explanation in the form of a neat, verbose comment, on this every screen : )
In my experience, programmers develop this "comment blindness" kind of like an everyday person numbs themselves to omnipresent ads via so-called "banner blindness".
Basically, most of the comments one encounters are redundant, stale etc. and therefore useless. So the less comments overall, the better the chance for the ones that matter to stand out.
At the end, there's no silver bullet, and while as experienced programmers we find it obvious and needless to say, I guess it probably is a valid takeaway for juniors to take most guidelines as rules of thumb only, and avoid falling into dogmatism (the mother of cargo cult)...
I remember looking at used books in my college bookstore, and found one which had nearly every sentence highlighted in yellow. The book might as well have been dipped in yellow ink! Overuse of the highlighter amounted to not using it at all.
- Subroutines must have one entry point and one exit point, and accomplish one task.
Good thing every programming language nowadays enforce that lesson. I can only imagine how horrible it must've been to reason about a program when a method could just GOTO away and never come back.
> Practice, practice, practice is not necessarily good advice if you don't know what you're doing.
The lacking part is not knowing what you are doing (if you know what you are doing, why do you need to practice?), but having enough introspection to be critical of the code you just wrote.
I think back to the old Cat Stevens song "I Want To Live In A Wigwam", except now I think maybe one day I'd like to live in a Faraday cage.
Computers, like guns, drugs, and any other invention of man are not inherently evil. All these things can be used for good or evil. Unfortunately, the fly in the ointment is human nature. With the convergence of cheaper but increased computing power and the monetization of personal information, I fear what the future holds. I hope I'm wrong, but it looks to me that humanity is doomed to forever live in a state total surveillance and control. We're seeing it happening already. Just the other day I saw an article that said that Sweden is going to tax people on the miles they drive. The very next day I saw another article saying Los Angeles is planning to do the same thing.
A fuel tax isn't effectively a tax on mileage, nor is it an effective tax for offsetting infrastructure costs. An increase in axle weight causes an exponential increase in damage to infrastructure (the American Association of State Highway and Transportation Officials uses a "fourth-power" rule). Increased fuel economy also has unintended consequences leading to fuel taxes under-funding the infrastructure repairs.
You essentially have heavy-duty or commercial trucks that don't "pay their weigh" and hyper efficient hybrids and EVs that don't "pay their way" when it comes to infrastructure costs.
So fuel tax isn't equivalent to a tax on "miles driven," it might be better suited to off-setting air pollution (pure conjecture on my part), but if you wanted everyone to be responsible for the damage they cause to public infrastructure, you would need some weird calculus of axle-weight/mile driven tax.
Or we could decide major roads/infrastructure are an economic public good worthy of paying taxes on.
The difference is pay at the pump or pay via what your car's embedded GPS is reporting. GPS also allows them to know when and where you were speeding, and since Sweden went cashless, they can simply deduct the fines from your bank account. Compliance is irrelevant.
If having a GPS device on your person becomes law, then avoiding the tax by riding a bicycle, walking, riding a horse etc is defeated.
This fear mongering goes on since the days of Henry Ford. Technology has been a boon for many many people. I can't imagine a world with many more people dying or without access to information.
