Ask HN: Do you use an old or 'unfashionable' programming language?

I use MATLAB for 90% of my day to day work, for a combination of reasons -

1. Historically it is what has been used at my firm. We have a lot of code already written in MATLAB, interfaces to internal apis, external data providers etc. Everyone at the firm understands MATLAB code.

2. It really is very good for numerical work - both in terms of speed, and clarity of the code (much better than Python and R for clarity - probably on a par with Julia).

I also used KDB+/Q very heavily in a previous job. It is blazing fast in its domain (financial time series) and enables extremely rapid prototyping. The fact that it is a combined query language / programming language is very appealing for data-focused research. I wouldn't want to write a production system in it though (though I know people who have done!)

When I was studying for my PhD I wrote a lot of Fortran 77 and IDL. Essentially because my supervisor used IDL and had a lot of code written in it, and because we were using an external tool which consumed Fortran 77 files as input.

Pascal - still use it today.

I started with Turbo Pascal 3.0, went through several versions of Borland Pascal (DOS and Windows), several versions of Delphi, and am now using FreePascal. I do most of my work on Linux nowadays. Pascal still gets everything done and after 20+ years I am really fluent in it.

Did a little bit of Javascript with Node.js, also looked at Golang. While I did like some aspects of them, there was always the downside of having to learn a whole new ecosystem. Didn't like the dynamic typing of Javascript. Golang looked better for what I do. But in the end I just wrote a small Pascal library to emulate Golang's channels which I really liked, and that was the end of Golang for me.

My main project in Pascal is a search-engine: https://deusu.org

Sourcecode for that is on GitHub: https://github.com/MichaelSchoebel/DeuSu

So yes, you can (still) do actual stuff in Pascal. Even pretty cutting-edge stuff.

To quote the classical piece on the subject ("PHP: a fractal of bad design"):

    There is a whole lot of action at a distance. 
    Consider this code, taken from the PHP docs somewhere.

    There is a whole lot of action at a distance. 
    Consider this code, taken from the PHP docs somewhere:

    @fopen('http://example.com/not-existing-file', 'r');

    What will it do?

    If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. 
    (Docs don’t say what “won’t work” means; returns null, throws exception?) 
    Note that this flag was removed in PHP 5.2.5.

    If allow_url_fopen is disabled in php.ini, this still won’t work. 
    (How? No idea.)
    Because of the @, the warning about the non-existent file won’t be printed.
    
    But it will be printed if scream.enabled is set in php.ini.
    Or if scream.enabled is set manually with ini_set.
    But not if the right error_reporting level isn’t set.
    If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.

etc. :) (Perhaps this particular issue is obsolete now, still it's emblematic of problems underlying the language, the ones I had to encounter when I worked with PHP few years back. Talk about "easy to use")

I use C as my staple language. Old and always unfashionable, but it's never going away in my lifetime.

> This sounds like other similar language will not get the job done.

That's not what they're saying. If someone knows a tool and it works for them, then it's more immediately useful than another tool which they don't yet know how to use, or how well it works.

> The truth is that there are much better alternatives which are a lot more pleasant to use and will get the job done in a much better way.

Quantify "better". PHP has its flaws (quite a lot of them), but it also has its advantages. It's a very popular language, so if you want to do something with it, almost certainly someone else has tried to do the same thing, so there will be libraries for it, guides, people who you can ask for help if you have trouble. It has a shared-nothing architecture, which aids scalability. It has extensive documentation. It has a large selection of battle-tested frameworks. There is an almost infinite selection of hosting providers.

> This is a myth. Php is not easy to use. May be, It is easy to start.

PHP's flaws can make it an occasional pain, but it is not really harder to use than any other ALGOL-like language. It is sometimes easier as it tends to expose simple interfaces to things, rather than requiring the user deal with a lot of complexity.

> But you need to know a lot of useless stuff (outside the context of Php), to get anything to work any where near reliably.

This is, to some extent, true for other languages as well. But yes, I'd agree with you here that PHP has more baggage than its contemporaries.

> Also, be prepared to write a lot more automated tests if you want to keep it that way.

This is true of dynamic languages generally. Though PHP has (limited, runtime) type-checking, which can reduce the burden here somewhat.