We still have one web-app written in perl, it's based on the mojolicious web framework to keep it somewhat maintainable, the app used to be heavily tied to mod_perl1 which has thankfully been 'modernised' to not use mod_perl1 or 2 and instead run with mojo+nginx. I expect this to continue being in service and maintained for another 1-2 years before being replaced by a python rewrite.
Ask HN: What “old” programming languages will you still be using in 2017?
221–230 of 502 posts
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#222I'm still using VB6 which was released in mid 1998 (19 years old in 2017)
I'm modernizing a VB6 app and still get to read through a bunch of it to get things done. Luckily for the moment we've managed to hold off on needing to release new bug fixes/features for the VB6 code.
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#223Perl 5, of course! It's an awesome language and both the language and the ecosystem is getting better and better all the time
What do you do in Perl?
I have written a number of Perl scripts (both CGI and batch) to make up for shortcomings in our ERP system, and to hook up our ERP system to our PDM and financial accounting systems.
Also, I have written a couple of reporting scripts to watch over our Active Directory (look for computers that do not exist any more but still have their AD accounts, stuff like that).
Oh yeah, and a couple of Nagios plugins, too.
For these tasks, there are not many languages that can match Perl in versatility and productivity. It's not the prettiest language, but it's extremely useful.
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#224C++ - I've started at a new company whose main product consists of 2 million lines of C++/MFC code. It's a pain in the ass and I'm hating my life now, but it pays the bills...
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#225Perl 5. Perl is awesome and versatile, and it's the fastest scripting language in common usage.
Ever benchmark it against Lua? But yea a whole lot more people use Perl.
Lua feels awkward to me when used as a standalone scripting language.
When embedded into a C host applications, it is really nice, though. There is also a port of Lua 5.2 to Go, which has a slighty confusing API (to me, at least), but the documentation makes up for that.
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#226- sh (I really don't use bash features in scripting) - awk - perl - sed, if that counts as language. It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with proce…
As always there's a relevant xkcd. https://xkcd.com/519/
Very true with perl, although for me it came a bit too late: Larry Wall published first version of Perl at the time of that course, so it obviously wasn't in the content, and I did the stuff with sh, sed and awk, and perl has unfortunately always been a bit of an afterthought for me (I have to look at a manual in some simple things where with awk I don't).
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#227Many folks have said it here but I'll say it again: Common Lisp. I have been using it professionally for 5+ years as a full-time employee at various companies. Some big-name ones, some smaller start-up ones. The mean Lisp team size has been around 4, but I did work on a project of 15 Lisp programmers. None of these projects were legacy code. Some were in places you wouldn't expect (embedded, multi-processor systems o…
>In every single case, we had no additional trouble hiring a Lisp or Lisp-capable programmer as compared to hiring for any other language, including Python
Doesn't that imply an over-supply?
I did my grad research on a highly specialized topic, involving plenty of math/physics.
Then I worked in industry applying my skills for 4 years.
Then I switched to programming - nothing related to my engineering degrees. This job requires only a BS (and not really that - one of my coworkers has no degree).
The highly specialized job was the one where I had little leverage, lower pay, and a miserable experience. Why? Fewer jobs than supply.
Whereas for programming, the supply is much larger than for the specialized work, but the demand is even larger than the supply.
The geek in me yearns for a job where I can go back to numerical algorithms and physics. But frankly, those jobs tend to suck when you don't have much leverage.
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#228lisp: It excels in "key algorithmic techniques such as recursion and condescension". http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
[deleted]
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#229- sh (I really don't use bash features in scripting) - awk - perl - sed, if that counts as language. It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with proce…
Any suggestions for a bash scripting tutorial to help me better connect the dots? Over the years I've learned some nifty one-liners, but I'm not really familiar enough with the patterns and art of of command-line thinking to solve my own problems in bash. Most of the bash resources I've found online are just loosely organized collections of magic spells. I'd really like to get better at it though.
Re: Ask HN: What “old” programming languages will you still be using in 2017?
#230Lots and lots of SQL, which is now 40+ years old.
I had not even thought of that. But yeah, if SQL counts, I'll probably be writing a couple of hundred lines of SQL in the coming year.
It can be surprisingly fun to see if I can get something done in "pure" SQL without any procedural code.
I feel a little sorry for the poor soul who may one day inherit that code, but on the other hand, at least I write comments to explain why I do things in a certain way, which is more than my predecessor did.