I've had great success acting on my own initiative and begging forgiveness afterwards.
That being said, the bottom line is I was able to show marked improvement. If your tools and processes have no tangible benefit - then I'm sorry, but you're going to have to pay the price for your insolence.
Actually, there is one optimization you should always do before deciding to code up a program:
Ask yourself, "do I have something already available that can do this job?"
In my experience the very best programmers are the most lazy for several reasons:
1. They search for existing alternatives to having to code (as above). 2. They automate as much of their job as they possibly can (not only does this save them time - it means their results are consistent). 3. Rather than building one-offs, they build libraries that have reuse value (because they know they will undoubtably have to visit the problem domain again at some point). 4. Most importantly, and related to all the above: they think about what they are going to build before they build it.
In my experience lazy programmers are slower to solve novel solutions, but are very fast when dealing with things that relate to what they've already created libraries to handle. As time passes, the old lazy programmer is very fast indeed in comparison to the neophyte because he generally has code squirreled about to handle just about any situation effectively.
That's not lateral thinking - that is the Unix way... small tools that do very specific things that you can string together via output redirection to create new functionality (the whole is greater than the sum of the parts). From a resource, security, and provably correct standpoint - that shell script solution is superior to any 'reinvention of the wheel' you could come up with as an executable program.
If you come from a windows/dos world, I can understand why you wouldn't understand this concept, as dos is a poor excuse for a shell in comparison to sh/bash/ksh/csh (well maybe not csh) - and windows programming is a blecherous atrocity without any redeeming qualities.
But, that's just my opinion; your views may differ, and you are welcome to them!
I would say there is one sense where interpreted basic is better than python - the fact that interpreted basic is a simple structural language - whereas there are some things in python that have to be done in an OO context.
For end users - any programming language must limit the conceptual domain to structural language constructs, and furthermore should also be interpreted. This allows the end user who is not familiar with programming to immediately grasp the idea of a list of instructions that follow one after the other, and gives them immediate feedback during the critical early period when they are learning the basics(sic).
We as programmers collectively have a tendency to find joy in ever more levels of complexity. We shouldn't forget who we are really working for - and do something to make their life easier. (And frankly - I'm tired of them calling me for things that they should be able to do for themselves...so my motivations aren't totally without self interest).
I think the tool needs to be more than just a toy - it should allow them to get things done, but not require computer science level knowledge to use. This is why I think an interpreter would be a better choice for end users; they would get immediate feedback and not have to learn the compile/debug cycle with different tools.
A good example from my early teen years is a basic interpreter. I could read and write files with it - and create programs to do useful things - but it generally did not allow me to shoot myself in the foot without some serious effort. It came loaded with the system (in fact at that time it WAS the operating system) - but a similar tool with a bit more sophistication could be developed for end users to accomplish the same thing in modern operating systems. It should be noted that complete BBS systems were built using this basic - so it is not only simple - but could have some powerful application if desired.
I am scared about all the damage they will do when trying to. And it has already started, e.g. with businessmen automatizing things using spreadsheets that bypass any organizational requirements for documentation, software quality, maintainability and even backup. These are disasters waiting to happen.
This is no worse than what 'professional' programmers are already doing to those same end users through zero-day exploits and bugs that confound easy use of their computing systems.
Why not build automation tools instead that not only allow end users to handle some of their own automation without shooting themselves in the foot - but also ties those solutions into the enterprise systems as well? Geez guys - this is not rocket science. For that matter, we could also create tools that limit what application programmers can do to avoid the security pitfalls - and make programming faster and more accurate even for the professionals who shouldn't be doing systems level programming anyway.
What I keep hearing is laziness, fear, and some amount of greed talking. Computers weren't designed for your private amusement. They are tools for the greater good - that is currently causing as much lost time and suffering as not having the computers would have in the first place. We need to do something about this.
You're assuming a static tool set (leaning towards systems programming level skill).
Given the right tools - anyone can generate automation for themselves that is useful in some context. This is what the original article is talking about - and I don't understand the lack of understanding of that basic premise by ostensibly smart people who can handle complexity. The programmers here "do'th protest too much!"
Every problem is not a nail, and every tool is not a hammer. This is 30+ years of experience talking here; giving users decent automation tools for their skill level isn't going to make you lose your job...unless you're already a complete moron.
Here's a wild idea - why not make a user-level computer language that abstracts away those details for the user-level programmer.
Basically create a development tool specifically for end users that doesn't allow them to shoot themselves in the foot.
I've been programming for 30+ years - and I know end users would find use for simple scripting/automation tools if they were designed correctly.
A useful program isn't necessarily a complex one; I'm seeing too many people here conflate usefulness with complexity - and no such correlation exists. I can only assume they are worried that if people can roll their own - there will be less need for 'professional' programmers. That is the wrong way to view this - instead think about the overflow of projects that exist today - there will be less trivial ones to deal with in this scenario, and our professionals will be able to focus more time and energy on making the complex projects better.
Everyone doesn't need to be able to manage memory directly, manipulate CPU registers, or do authentication/cryptography. I'm not saying to take away systems programming; but application programming shouldn't require these low level constructs - and where they do need to interact with those systems level things, a standard and secure implementation should be imbedded in the framework/sandbox you're using so that the interaction is consistently bug free and secure. We do need tools that limit the problem domain - even for so-called 'professionals' that continue to churn out zero-day exploits on a daily basis.
The bigger problem is too many unskilled (in terms of the complexities described above) programmers having to implement these things in their application layer programs.
We can build systems that are easy to use and manage - and easy to program for applications layer things. We don't do that because we are lazy and would rather hide behind a limited liability license and collect revenue for each gee-whiz feature that differentiates our product from the thousands of others out there.
My suggestion is for us to do something before the users come at us with pitch forks and torches.
You are absolutely right. As much as I like to tinker with my linux box and write code - computers are really only valuable to the extent they can be useful to the average user. None of us in IT would have jobs if it wasn't for the network and all the computers in hands of the end users that makes that network useful.
The problem today goes beyond just the unnecessary complexity of programming languages (and I agree that is entirely rediculous and also contributes to bugs and security problems even in the hands of professionals) to the issues of end users effectively managing their computers (configurations/security) and extending its capabilities; you have to practically be a computer scientist. That isn't reasonable from my perspective.
We (IT) could solve this - but there is no pressure to make it happen.
I think you have that backwards: the problem is and always has been the creation of computing systems that require the average person to understand computer science to safely use these devices. That was a failure from day one - but having a EULA that says "company X is not responsible for your use of the software" was easier than fixing the problem.
I would say this is our failure - the minority of people who are in the IT/Technology field that are computer scientists and responsible for designing and building the devices and networks; our purpose is to help people (all people) - not just a few who are clued in.
From my own experience programming since I was 16 (30+ years myself!), as I became more experienced over time I became more and more aware of my shortcomings (the more you learn, the less you know). I've tried to make a point to continue learning and improving - and today in my old(er) age I would be more likely to appreciate constructive criticism than when I was younger (and sure I knew it all).
The guy might surprise the kid - so I would advise him to have a friendly/constructive discussion about it.
Your post is related to what I was thinking: if there is no expectation for anyone else to maintain his code, then I don't see the problem from the complainers perspective. Of course, that doesn't help the company if he gets hit by a bus.
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
He might be focussing on delivering working software - and less about documentation or process. The management of this company might see his performance as a good thing relative to customer satisfaction...that is until he gets hit by a bus and a zero day vulnerability emerges from the depths of the gaseous mud bog that passes for his code base...
Our legal council for the subsidiary was located in our office - and I can vouch for her (one person mind you) using way in excess of 10,000 sheets a year easy. She would print tomes on a daily basis - and the printer was often empty of paper or toner the few times I needed it. She kept most of it in several large file cabinets - and when she moved it was a big deal packing up all the mess for shipment (think 30+ legal boxes chock full of paper).
While you may not use that much paper - I have no problem with the idea of others making up for it.
Many times there is simply nothing you can do. In a large corporate setting - very rarely will you see excellence. Instead mediocrity will be the norm for various reasons:
1. Processes and organizational silos get in the way of performance. It doesn't matter how much you warn the design team about the problem their design has with battery life of the gadget in question - they almost always have the 'not designed here' mentality that negates outside suggestions - since they are in a different group and don't report through your chain of command. Sometimes the process itself forces bad implementation and deployment - either in time, costs or both (e.g. time to market window is missed because we had to wait for all the boxes to be checked in the process - thus losing out to a faster competitor).
2. Programmer resources are seen as interchangeable widgets. We all know this is not true - but management thinks so and allocates resources accordingly - which generally results in non-optimal results.
3. IT is run and managed as a cost center - driven by accounting. This means the focus is on cost rather than results. If the results are 'good enough' at a given cost point, then that is okay with management (too bad for the poor people in the operations teams who have to actually run and troubleshoot it in production). This drives downsizing, and outsourcing too - driving good developers either out or up (into the peter principle area - which causes still more problems).
4. Upper management politics. Turf wars, empire building, whatever you want to call it - can put a damper on any project as the upper managers jostle for projects and resources. You can also see similar effects when upper management doesn't know what to do - projects without clear benefit become hot potatoes - or focus is lost altogether. This is when you get really bad 'designed by committee' projects that usually end in disaster.
I've experienced all that and more in my 16 years in the business. That experience has proved invaluable in my own projects - not only knowing what problems to anticipate, but also knowing how best to allocate the people and resources I do have control over - at least until the next reorganization takes them away.
My advise would be to remain flexible and valuable. Be able to roll with the punches and keep upbeat - but be sure to do what is in the best interests of your company - you can never be seen as negatively disruptive if you are doing what's right for the company - and be able to express that to your management chain in a positive light. Learn all you can about your craft and the jobs of those on a typical development team from inception to deployment into production - know the pitfalls and how it all works together (or should if it is dysfunctional). Do what you can to mitigate problems - before they can damage the project or the company's reputation, but pick your battles - you're not going to be able to win every time. There is no use being scared; whatever 'security' exists in a large company is a fallacy that only exists as long as the next reorganization and can be impacted by financial considerations outside of any value you might bring - assume the worst and be happy when they decide to keep you around until the next one.
Finally, if that is too difficult to manage - start looking for work elsewhere, for your own sake - in a small company where these kinds of issues aren't likely to happen.
When I started having to have automation (either in my IDE or externally as a second pass) manage my curly braces and semicolons - coupled with strange debugging errors the result of dangling curly braces and/or semicolons - which sent me on many a 'needle in a haystack wild goose chase' to locate and fix - I knew there had to be a better way. I found it in python.
For me: python saved me time, and allowed me to deliver more and better quality code over doing the same tasks in perl. When projects evolved to teams of people having to share and read each other's code - this really paid off. YMMV.
If you are happy and productive with perl - stick with it by all means! If you are not - there are alternatives that may address the issues you are experiencing.
For me: I was a long time perl developer - until I found python. There isn't anything I can think of that can't be done in python that can be done in perl (or awk or sed for that matter). Furthermore, the base libraries provide most of the functionality needed, and I've found that I was able to avoid having to download modules - as I was building my own toolset most of the time.
Other aspects sold it for me: faster and more accurate debugging, more readable code (regardless who wrote it - primarily because for most things there is only one canonical way to do something), ability to not only do small apps well - but to manage large applications easily, OO integrated into the language (not a sidecar - I never did get the hang of using OO in perl whereas python OO was natural to me), and finally there were some things that were 'pythonic' ways of doing certain equivalent perl tasks that ended up being superior.
In summary: for me developer time and delivered working code is the bottom line - and python allows me to save time while delivering quality working code. You even have the option of building python modules in C if you desire - to address a performance bottleneck presumably. For what I do - I haven't had the need to do that yet - so whatever performance hits 'stock' python may have, it hasn't been a big enough problem to stop using it.
YMMV
Re:this guy is hitting the nail on the head
on
The Web We Lost
·
· Score: 1
There is no free lunch. You paid for your internet access back then (or if you were underage - your adult caretaker, or the entity you were stealing access from).
Re:Uh...it's still there, you know
on
The Web We Lost
·
· Score: 1
Better yet - have one in the corner, and a mirror of that in the cloud. If you push-only (no inbound services enabled for your home machine) - then you have very little if anything to worry about (aside from someone getting unauthorized access to your data in the cloud; but if you put something in the cloud - unless it is encrypted - you should assume anyone can see it anyway).
When you are young, you think you know it all and as a result lack the proper humility and respect. When you get older and the problem domain opens up to you - you realize just how much you really didn't know - and the daunting fact that you will never be able to know it all. You can either let that knowledge crush you, or you can decide not to lose heart and forge a path forward that includes life-long learning.
Ultimately I think long term success comes down to picking the right things to know, having a good model for how that all fits together, and most importantly - being able to quickly put that to good use.
Are there exceptions to this? Certainly - there are. When I look back on the code I produced when I was 20 - I often ask myself, "what was I thinking?" Sure - I worked long hours back than - as I was in larval stage. I had to spend more time in iterations of code - build - test - repeat to get it right. But what I did finally get working was not pretty to look at. When I look at code of 20-somethings today I see that same pattern. 20-somethings more productive? Hogwash...unless all you care about are costs without regard for quality. At the same token - are there numbers of older developers who've lost touch with their craft? Certainly.
A better approach is not to focus on the age of a given person - but look instead at what they are accomplishing. As the saying goes, actions speak louder than words or age for that matter.
Ah - it has been said before, but I'll say it again, "Youth is wasted on the young."
When you are young you think you know it all. Once you get any significantly deep understanding of any technical or scientific subject you'll quickly learn how little you really know. You will learn to couch your words with more caveats and less certainty as reality (and possibly physics) beats you down - if you are being honest with yourself and others.
There is only one certainty: nothing is certain.
My advice - start working on humility now - and quest for wisdom (truth) in all things.
Slashdot Mirror
I've had great success acting on my own initiative and begging forgiveness afterwards.
That being said, the bottom line is I was able to show marked improvement. If your tools and processes have no tangible benefit - then I'm sorry, but you're going to have to pay the price for your insolence.
People who think they know what the job entails start out saying "It's Easy! All You Have To Do Is..." and the whole thing swiftly descends into Hell.
I think that's okay - as long as they don't drag anyone else down into the fire with them, and learn something from their journey.
Actually, there is one optimization you should always do before deciding to code up a program:
Ask yourself, "do I have something already available that can do this job?"
In my experience the very best programmers are the most lazy for several reasons:
1. They search for existing alternatives to having to code (as above).
2. They automate as much of their job as they possibly can (not only does this save them time - it means their results are consistent).
3. Rather than building one-offs, they build libraries that have reuse value (because they know they will undoubtably have to visit the problem domain again at some point).
4. Most importantly, and related to all the above: they think about what they are going to build before they build it.
In my experience lazy programmers are slower to solve novel solutions, but are very fast when dealing with things that relate to what they've already created libraries to handle. As time passes, the old lazy programmer is very fast indeed in comparison to the neophyte because he generally has code squirreled about to handle just about any situation effectively.
That's not lateral thinking - that is the Unix way... small tools that do very specific things that you can string together via output redirection to create new functionality (the whole is greater than the sum of the parts). From a resource, security, and provably correct standpoint - that shell script solution is superior to any 'reinvention of the wheel' you could come up with as an executable program.
If you come from a windows/dos world, I can understand why you wouldn't understand this concept, as dos is a poor excuse for a shell in comparison to sh/bash/ksh/csh (well maybe not csh) - and windows programming is a blecherous atrocity without any redeeming qualities.
But, that's just my opinion; your views may differ, and you are welcome to them!
I would say there is one sense where interpreted basic is better than python - the fact that interpreted basic is a simple structural language - whereas there are some things in python that have to be done in an OO context.
For end users - any programming language must limit the conceptual domain to structural language constructs, and furthermore should also be interpreted. This allows the end user who is not familiar with programming to immediately grasp the idea of a list of instructions that follow one after the other, and gives them immediate feedback during the critical early period when they are learning the basics(sic).
We as programmers collectively have a tendency to find joy in ever more levels of complexity. We shouldn't forget who we are really working for - and do something to make their life easier. (And frankly - I'm tired of them calling me for things that they should be able to do for themselves...so my motivations aren't totally without self interest).
I think the tool needs to be more than just a toy - it should allow them to get things done, but not require computer science level knowledge to use. This is why I think an interpreter would be a better choice for end users; they would get immediate feedback and not have to learn the compile/debug cycle with different tools.
A good example from my early teen years is a basic interpreter. I could read and write files with it - and create programs to do useful things - but it generally did not allow me to shoot myself in the foot without some serious effort. It came loaded with the system (in fact at that time it WAS the operating system) - but a similar tool with a bit more sophistication could be developed for end users to accomplish the same thing in modern operating systems. It should be noted that complete BBS systems were built using this basic - so it is not only simple - but could have some powerful application if desired.
Where are those simple tools for end users today?
I am scared about all the damage they will do when trying to. And it has already started, e.g. with businessmen automatizing things using spreadsheets that bypass any organizational requirements for documentation, software quality, maintainability and even backup. These are disasters waiting to happen.
This is no worse than what 'professional' programmers are already doing to those same end users through zero-day exploits and bugs that confound easy use of their computing systems.
Why not build automation tools instead that not only allow end users to handle some of their own automation without shooting themselves in the foot - but also ties those solutions into the enterprise systems as well? Geez guys - this is not rocket science. For that matter, we could also create tools that limit what application programmers can do to avoid the security pitfalls - and make programming faster and more accurate even for the professionals who shouldn't be doing systems level programming anyway.
What I keep hearing is laziness, fear, and some amount of greed talking. Computers weren't designed for your private amusement. They are tools for the greater good - that is currently causing as much lost time and suffering as not having the computers would have in the first place. We need to do something about this.
You're assuming a static tool set (leaning towards systems programming level skill).
Given the right tools - anyone can generate automation for themselves that is useful in some context. This is what the original article is talking about - and I don't understand the lack of understanding of that basic premise by ostensibly smart people who can handle complexity. The programmers here "do'th protest too much!"
Every problem is not a nail, and every tool is not a hammer. This is 30+ years of experience talking here; giving users decent automation tools for their skill level isn't going to make you lose your job...unless you're already a complete moron.
Here's a wild idea - why not make a user-level computer language that abstracts away those details for the user-level programmer.
Basically create a development tool specifically for end users that doesn't allow them to shoot themselves in the foot.
I've been programming for 30+ years - and I know end users would find use for simple scripting/automation tools if they were designed correctly.
A useful program isn't necessarily a complex one; I'm seeing too many people here conflate usefulness with complexity - and no such correlation exists. I can only assume they are worried that if people can roll their own - there will be less need for 'professional' programmers. That is the wrong way to view this - instead think about the overflow of projects that exist today - there will be less trivial ones to deal with in this scenario, and our professionals will be able to focus more time and energy on making the complex projects better.
Everyone doesn't need to be able to manage memory directly, manipulate CPU registers, or do authentication/cryptography. I'm not saying to take away systems programming; but application programming shouldn't require these low level constructs - and where they do need to interact with those systems level things, a standard and secure implementation should be imbedded in the framework/sandbox you're using so that the interaction is consistently bug free and secure. We do need tools that limit the problem domain - even for so-called 'professionals' that continue to churn out zero-day exploits on a daily basis.
The bigger problem is too many unskilled (in terms of the complexities described above) programmers having to implement these things in their application layer programs.
We can build systems that are easy to use and manage - and easy to program for applications layer things. We don't do that because we are lazy and would rather hide behind a limited liability license and collect revenue for each gee-whiz feature that differentiates our product from the thousands of others out there.
My suggestion is for us to do something before the users come at us with pitch forks and torches.
You are absolutely right. As much as I like to tinker with my linux box and write code - computers are really only valuable to the extent they can be useful to the average user. None of us in IT would have jobs if it wasn't for the network and all the computers in hands of the end users that makes that network useful.
The problem today goes beyond just the unnecessary complexity of programming languages (and I agree that is entirely rediculous and also contributes to bugs and security problems even in the hands of professionals) to the issues of end users effectively managing their computers (configurations/security) and extending its capabilities; you have to practically be a computer scientist. That isn't reasonable from my perspective.
We (IT) could solve this - but there is no pressure to make it happen.
Let's fix this.
I think you have that backwards: the problem is and always has been the creation of computing systems that require the average person to understand computer science to safely use these devices. That was a failure from day one - but having a EULA that says "company X is not responsible for your use of the software" was easier than fixing the problem.
I would say this is our failure - the minority of people who are in the IT/Technology field that are computer scientists and responsible for designing and building the devices and networks; our purpose is to help people (all people) - not just a few who are clued in.
From my own experience programming since I was 16 (30+ years myself!), as I became more experienced over time I became more and more aware of my shortcomings (the more you learn, the less you know). I've tried to make a point to continue learning and improving - and today in my old(er) age I would be more likely to appreciate constructive criticism than when I was younger (and sure I knew it all).
The guy might surprise the kid - so I would advise him to have a friendly/constructive discussion about it.
(and stop posting about me on /. please!)
Your post is related to what I was thinking: if there is no expectation for anyone else to maintain his code, then I don't see the problem from the complainers perspective. Of course, that doesn't help the company if he gets hit by a bus.
The agile manifesto may also be useful to consider:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
He might be focussing on delivering working software - and less about documentation or process. The management of this company might see his performance as a good thing relative to customer satisfaction...that is until he gets hit by a bus and a zero day vulnerability emerges from the depths of the gaseous mud bog that passes for his code base...
Our legal council for the subsidiary was located in our office - and I can vouch for her (one person mind you) using way in excess of 10,000 sheets a year easy. She would print tomes on a daily basis - and the printer was often empty of paper or toner the few times I needed it. She kept most of it in several large file cabinets - and when she moved it was a big deal packing up all the mess for shipment (think 30+ legal boxes chock full of paper).
While you may not use that much paper - I have no problem with the idea of others making up for it.
Many times there is simply nothing you can do. In a large corporate setting - very rarely will you see excellence. Instead mediocrity will be the norm for various reasons:
1. Processes and organizational silos get in the way of performance. It doesn't matter how much you warn the design team about the problem their design has with battery life of the gadget in question - they almost always have the 'not designed here' mentality that negates outside suggestions - since they are in a different group and don't report through your chain of command. Sometimes the process itself forces bad implementation and deployment - either in time, costs or both (e.g. time to market window is missed because we had to wait for all the boxes to be checked in the process - thus losing out to a faster competitor).
2. Programmer resources are seen as interchangeable widgets. We all know this is not true - but management thinks so and allocates resources accordingly - which generally results in non-optimal results.
3. IT is run and managed as a cost center - driven by accounting. This means the focus is on cost rather than results. If the results are 'good enough' at a given cost point, then that is okay with management (too bad for the poor people in the operations teams who have to actually run and troubleshoot it in production). This drives downsizing, and outsourcing too - driving good developers either out or up (into the peter principle area - which causes still more problems).
4. Upper management politics. Turf wars, empire building, whatever you want to call it - can put a damper on any project as the upper managers jostle for projects and resources. You can also see similar effects when upper management doesn't know what to do - projects without clear benefit become hot potatoes - or focus is lost altogether. This is when you get really bad 'designed by committee' projects that usually end in disaster.
I've experienced all that and more in my 16 years in the business. That experience has proved invaluable in my own projects - not only knowing what problems to anticipate, but also knowing how best to allocate the people and resources I do have control over - at least until the next reorganization takes them away.
My advise would be to remain flexible and valuable. Be able to roll with the punches and keep upbeat - but be sure to do what is in the best interests of your company - you can never be seen as negatively disruptive if you are doing what's right for the company - and be able to express that to your management chain in a positive light. Learn all you can about your craft and the jobs of those on a typical development team from inception to deployment into production - know the pitfalls and how it all works together (or should if it is dysfunctional). Do what you can to mitigate problems - before they can damage the project or the company's reputation, but pick your battles - you're not going to be able to win every time. There is no use being scared; whatever 'security' exists in a large company is a fallacy that only exists as long as the next reorganization and can be impacted by financial considerations outside of any value you might bring - assume the worst and be happy when they decide to keep you around until the next one.
Finally, if that is too difficult to manage - start looking for work elsewhere, for your own sake - in a small company where these kinds of issues aren't likely to happen.
You could alternatively do something like comment out the original if statement and insert a passthrough:
if True: # if myflag == 1:
print "hello world!"
myflag=2
This code will have the desired effect (body of if statement runs every time) without having to unindent.
"Can't do it without reindenting." O'RLY!!?
When I started having to have automation (either in my IDE or externally as a second pass) manage my curly braces and semicolons - coupled with strange debugging errors the result of dangling curly braces and/or semicolons - which sent me on many a 'needle in a haystack wild goose chase' to locate and fix - I knew there had to be a better way. I found it in python.
For me: python saved me time, and allowed me to deliver more and better quality code over doing the same tasks in perl. When projects evolved to teams of people having to share and read each other's code - this really paid off. YMMV.
If you are happy and productive with perl - stick with it by all means! If you are not - there are alternatives that may address the issues you are experiencing.
For me:
I was a long time perl developer - until I found python. There isn't anything I can think of that can't be done in python that can be done in perl (or awk or sed for that matter). Furthermore, the base libraries provide most of the functionality needed, and I've found that I was able to avoid having to download modules - as I was building my own toolset most of the time.
Other aspects sold it for me: faster and more accurate debugging, more readable code (regardless who wrote it - primarily because for most things there is only one canonical way to do something), ability to not only do small apps well - but to manage large applications easily, OO integrated into the language (not a sidecar - I never did get the hang of using OO in perl whereas python OO was natural to me), and finally there were some things that were 'pythonic' ways of doing certain equivalent perl tasks that ended up being superior.
In summary: for me developer time and delivered working code is the bottom line - and python allows me to save time while delivering quality working code. You even have the option of building python modules in C if you desire - to address a performance bottleneck presumably. For what I do - I haven't had the need to do that yet - so whatever performance hits 'stock' python may have, it hasn't been a big enough problem to stop using it.
YMMV
There is no free lunch. You paid for your internet access back then (or if you were underage - your adult caretaker, or the entity you were stealing access from).
Better yet - have one in the corner, and a mirror of that in the cloud. If you push-only (no inbound services enabled for your home machine) - then you have very little if anything to worry about (aside from someone getting unauthorized access to your data in the cloud; but if you put something in the cloud - unless it is encrypted - you should assume anyone can see it anyway).
When you are young, you think you know it all and as a result lack the proper humility and respect. When you get older and the problem domain opens up to you - you realize just how much you really didn't know - and the daunting fact that you will never be able to know it all. You can either let that knowledge crush you, or you can decide not to lose heart and forge a path forward that includes life-long learning.
Ultimately I think long term success comes down to picking the right things to know, having a good model for how that all fits together, and most importantly - being able to quickly put that to good use.
Are there exceptions to this? Certainly - there are. When I look back on the code I produced when I was 20 - I often ask myself, "what was I thinking?" Sure - I worked long hours back than - as I was in larval stage. I had to spend more time in iterations of code - build - test - repeat to get it right. But what I did finally get working was not pretty to look at. When I look at code of 20-somethings today I see that same pattern. 20-somethings more productive? Hogwash...unless all you care about are costs without regard for quality. At the same token - are there numbers of older developers who've lost touch with their craft? Certainly.
A better approach is not to focus on the age of a given person - but look instead at what they are accomplishing. As the saying goes, actions speak louder than words or age for that matter.
In what ways is he wrong, and what ways is he crazy?
(If you're going to make such a bold statement, at least provide some evidence to support your hypothesis please.)
Ah - it has been said before, but I'll say it again, "Youth is wasted on the young."
When you are young you think you know it all. Once you get any significantly deep understanding of any technical or scientific subject you'll quickly learn how little you really know. You will learn to couch your words with more caveats and less certainty as reality (and possibly physics) beats you down - if you are being honest with yourself and others.
There is only one certainty: nothing is certain.
My advice - start working on humility now - and quest for wisdom (truth) in all things.
Ed's mentally challenged brother Edlin.