jdoege's comments

You must decide if you want your career path to be a manager or a technologist. In most cases, there is valid career growth in either path but they are different paths because there are fundamentally different skill sets and inclinations involved. It is important to take a brutally honest introspective look at yourself to determine what you enjoy about your career and what motivates you.

Then, if you still really want to change to the managerial path, you must again be brutally honest with yourself as you try to figure out why that has not yet been an option. Usually a technologist starts to get opportunities to make this choice at between 5 and 10 YOE. It might be that you unintentionally are signaling to your management that your preference is to be a technologist either because of personality characteristics (your objection to being managed by those younger than you is a potential problem area) or obviously deep focus on technology. Figure out what is blocking you and fix it.

I understand where you are coming from with regard to being managed by those younger than you but take it from a technologist with over 30 years of experience, being a manager is not a function of seniority but of talent. As I mentioned before, management involves a different set of skills. You must evaluate managers for their talent at the activity and remove your bias based on their age. You may find that working for a young manager sometimes gives you the opportunity to lead and mentor them and help them become a better manager.

As others have mentioned, if you really want to move to the management path, you must communicate to others that is what you want. You do this explicitly by telling them and you do this implicitly by demonstrating interest and focusing on your behaviors.

Finally, I’ve noticed that it is very common for people to think that a natural and expected career progression goes from low-level worker to worker to leader to manager to director, VP and CEO. In technology, this is not the only case. Senior technologists are valuable stores of information and capability and there is a valid career progression for them which goes: low-level worker to worker to leader to senior and principal technologist to fellow to CTO. You still get leadership responsibilities but you don’t have the administrative responsibilities. It is important to note that your authority, in this circumstance, comes from a reputation for being knowledgeable and smart (influence), not from position.

Many industries use Perl 5 to keep things running. The semiconductor industry, in particular uses a lot of existing, and develops a lot of new, Perl code to do things commercial software cannot.

The language formerly known as Perl 6 is now called Raku so there are no more backwards compatibility issues.

Perl 7 is the new opportunity for backwards incompatibility (and probably doesn't even have an entry on Tiobe which would make your argument even stronger!)

Also, Tiobe is about as interesting as a gossip column. There are many reasons to pick one language over another, but ranking on Tiobe will never be one of them.

I view the Raku vs. Perl split as schizophrenic conflict resolution.

Packrat parsing is not an intrinsic aspect of PEG, nor does it increase memory usage. Further, the memory issue is more academic than real. If you are having memory issues, you will add intentional pruning to your parser to purge anything that comes before a point behind which you can not backtrack. Such points tend to exist in most computer languages. Yes, this is not a strict part of PEG but being academically pure when constructing a parser of any complexity leads to a short trip to madness. Perl 6's grammar construct is not pure to the PEG definition but it is a recursive descent grammar engine with all the bells and whistle you could want including functional components such as argument pattern matching which makes generic and reusable grammar expression a cinch.

Also, PEG makes having a context sensitive lexer not simply trivial but no effort at all because lexing and parsing are all the same process. It you want to have two different token-types for an INT-looking-thing at two different places in your grammar for, "reasons", you are free to do so. Try that in a discrete lex/parse style grammar.

I went paperless, this year, and after trying 3 or 4 different note apps, I settled on Notability on an iPad Pro with Apple Pencil. That I can run the app on my laptop (and phone), synchronized through iCloud makes this incredibly more useful than pen and paper. Importing pdfs and images from other places, keyboard based text entry from the laptop, proper handwriting recognition and search thereon based is amazing. I can tell when technology will work for me when I can quickly adopt it and feel no desire to go back to what I did before. That happened with ereaders for me when they came to the phone (I can read anywhere, anytime and for however long I have, I love it) and it has happened with this, as well.

I don't know about vendor stance, but Elixir feels fairly elegant (better descriptive word than beautiful, I think.)

What I have negative to say has more to do with those producing implementations than the architecture or RTL. In order to have the security afforded by being open, every part of the process must be open from the spec to the silicon. The entities producing RISC-V devices are simply passing forward the RTL along with their additions and changes. They are not releasing the work product of any of the steps between there and silicon. There are many differences between RTL and the gate-level representation, many of which represent potential security issues (testability features, for instance.) Between gates and physical design more changes can be made and between physical design and mask, even more. Some of those could result in sloppy security holes or some could even be maliciously introduced security holes. With any of the current providers there is no way to know or test for these potential issues.

Moreover, no one is releasing the gate-level netlists nor the LEF and DEF nor mask data. Without those you can't have security unless you build your own.

It really depends. The question really should be, "Is Perl 6 fast enough?" For my purposes, the answer is almost always yes. I can imagine some applications where the answer would be no, but then I would probably be looking at C/C++ for a solution, anyway. Language bench-racing has really begun to look counter-productive to me.

If you are doing it for personal growth and learning, then Perl 6. It is an interesting language that cleanly supports many major programming paradigms including functional, imperative and object oriented and, most probably, others. Additionally, it has many nifty features built in such as concurrency, grammars and rationals. Aside from that, it is also fun to use and has a great community.

If you are doing it for immediate application in a job or wish to acquire a skill you think might be required in a job then the answer is probably Perl 5. Despite the noise about Perl, it is still used a lot in many industries for flow control and inter-tool format conversion as well as many other applications. Many, many people understand perl and use it for rapid development of automation tools. I can tell you for a fact that it is pervasive in the semiconductor industry and is practically a job requirement, there.

Perl 6 actually exists and has a REPL which Perl 5 lacked.

I use Perl 6