Live data from Hacker News

Ask HN: What “old” programming languages will you still be using in 2017?

news.ycombinator.com

451–460 of 502 posts

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#452

Earlier quoted context omitted.

I once worked at a place that basically just used perl server side. In this decade (2010s). The codebase was just one tangled mess. They told a story of a guy who failed the cultural interview because he told a VP "you can't write a large web app in perl", and of course they had done just that. With the reflection of hind sight I think despite the obvious empirical counter factual, he was on to something. It really w…

In my company we primarily use Perl, but it's just on my team for our ETL pipeline. It works really well, especially since we modernized our older code and enforced really tight code standards. To use Perl end to end, well, there are modules for that (such as Dancer), but I can't comment on them because I've never had to use them.

I recommend Dancer, actually Dancer2 now. So easy to write web apps. Maintainable ones too! Most of the basics of app security are covered within the framework. And where there are gaps (like CSRF tokens), it's trivial to add primitives via DSL.

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#453

Earlier quoted context omitted.

Slime + emacs for your environment?

Yep, all the way. Slime + Emacs + Paredit.

Ah interesting. I thought paredit was standard in emacs.

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#454
post #69
post #55

Earlier quoted context omitted.

Objective C will always have room in my heart, but I'll never go back to it. There's too much .h ceremony.

Meh, I've spent about 20 hours on this project so far, and I'd estimate probably 2 minutes of that time was spent managing .h files.

Do you have any concerns about maintainability? So far Apple has been advancing Obj-C interfaces along with Swift, but time will probably come when some new OS features will only be available through Swift.

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#455

Many 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…

+1

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#456

Earlier quoted context omitted.

Perl makes it easy to write line noise, and only possible to write legible code. That possibility also goes mostly out the window as soon as you use the real strength of the language (regex).

Regexes support whitespace and comments, and can easily be composed. But I agree that an effort needs to be made to write legible Perl code. "Perl Best Practices" is required reading for any professional Perl programmer.

Aye, you know you're starting to reach expert level once you understand the parts of that book which should be ignored.

for OP: Perl is a rich and deep language. It's as or more comptetent as exactly the same things as ruby and python (although pythons maths, and keeping management happy libraries are better, perl's async and systems wrangling )support is better. It is more permissive than you would want in some circumstances, but in my experiencing running a competent perl team with supportive management is a pleasure.

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#457
post #177
post #138

Perl 5, I have been using it in Financial Services for the past 12 years. It is still a workhorse when it comes to reporting. Many large banks still use it, but most don't advertise it. I used it at places like Intel back in 1999. It really is a versatile language.

I switched to Python a few years back mainly for Django, but Perl still does a number of things better (regexes, interacting with the filesystem for example).

My understanding is that django/sqlalchemy and catalyst/dbix::class are equivalent. The former being better at keeping managers happy, the latter at keeping the right kind of programmers happy ( due to the superior flexibility).

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#458
post #75

IBM's High-Level Assembler and JCL mostly. I develop mainframe software.

I recently had to put together a small program with JCL for work, and had real difficulty in finding documentation. Can you recommend anything?

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#459
post #177

Earlier quoted context omitted.

I switched to Python a few years back mainly for Django, but Perl still does a number of things better (regexes, interacting with the filesystem for example).

My understanding is that django/sqlalchemy and catalyst/dbix::class are equivalent. The former being better at keeping managers happy, the latter at keeping the right kind of programmers happy ( due to the superior flexibility).

I did try Catalyst but being Perl and "more than one way to do it" caused me a lot of confusion (you could replace the template engine, the ORM and other parts to the point where I didn't know what the framework actually was).

Django was a bit more beginner friendly for someone new to a framework, and the documentation is really good. And the Django admin is one of the best ways to get something up and running quickly, there wasn't a Perl equivalent when I was trying Catalyst.

Re: Ask HN: What “old” programming languages will you still be using in 2017?

#460

Earlier quoted context omitted.

If you can't show the code, can you give any info about the overall design of it? I can't even think how you'd structure a "large" application in shell scripts.

It runs as a cgi, and uses files on disk instead of a database.

This is how many web apps in 1999 ran. As long as you treat your inputs carefully and properly handle file locking, there's nothing inherently bad about that approach.
Post reply on HN