Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

371–380 of 502 posts

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

#371

Post by lacampbell »

Ocaml (which will turn 21 this year).

It really hits a sweet spot for me:

- fast executables

- fast compile times

- very expressive

- good standard library in 'Core'

- a REPL so you can easily play around with code you have just written

- a type system that's really useful for catching bugs

- imperative programming is relatively easy

I find myself becoming more and more productive. I will have to see if writing a little server for JSON web API sitting behind nginx is feasible - currently using ruby for that.

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

#374

Post by alfalfasprout »

computerphage wrote: post #251
alfalfasprout wrote: post #123

Earlier quoted context omitted.

Hands down the best thing about C++ for me is that with modern C++ you can write relatively safe clean code while taking advantage of decades of robust libraries. Yeah, Rust is a big step forward in some respects, but it'll be almost a decade before we see it catch up to C++'s incredible ecosystem. C++ is almost the lingua franca of finance, for instance.

Rust can already take advantage of the C ecosystem quite easily. Rust/C++ usability is a major goal for 2017. I'm hoping that by year end you can have the best of both worlds. The advantages of Rust for new code and the mountain of code that exists for C and for C++.

Well, the C ecosystem has always been easy. The nice thing about C is that generating bindings is a breeze.

I've never been a fan of bindings to C++ libraries. They usually always feel cumbersome and hardly idiomatic. Like it or not, the best way forward is to bite the bullet and slowly natively reimplement the libraries we need in Rust.

I'm starting some work next year on writing some of the basic libraries that someone in the electronic trading world might want to start writing applications in Rust (a FIX/FAST engine and a port of the Aeron message transport). I'm already also writing a native Rust port of our internal consolidated market data library. We already have a Go port along with the C++ code and plan on open sourcing these pretty soon. This stuff tends to be highly proprietary and slow to develop so hopefully we can get some of the more cutting edge users to pitch in and get more people using the language.

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

#375

Post by protomikron »

reikonomusha wrote: post #209

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…

Can you elaborate on the work you did - in particular what problems did you have to solve, and why Common Lisp was used instead of other languages?

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

#377

Post by charlieflowers »

mercurialuser wrote: post #356

I will use Clipper open source alternative called Harbour. I started using Clipper in 1986 and some of 1986 code still runs today. Clipper was a compiler for Ashton tate dbase II language. Harbour now allows to run old code on windows, linux, Mac, Solaris and a bunch of other less common OSes, both in text mode or using some gui lib. It will also run on android and ios (using Qt).

Wow! I had no idea Clipper was still around. I was using it in 1993 with code blocks (essentially lambdas and first class functions, but not closures).

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

#379

Post by topranks »

disconnected wrote: post #191
networked wrote: post #77

Tcl. It works really well as a cross-platform (*nix/Windows) alternative to shell scripting that doesn't suffer from the same problems as the POSIX shell (see http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h... ). It builds on the same foundation of everything being text but with a few changes to the substitution rules builds something a lot like a Lisp on top of it.

I found expect (which is Tcl + some extensions, I believe) to be quite useful. Implementing something like modem initialization - "Send AT command to modem/wait for a reply matching one of several patterns or a timeout/handle result/rinse, lather, repeat until done" - is quite trivial to do with expect. It's not something I use every day, but it's one of those useful things to keep in your mental toolbox.

Came here to say this. Expect was and remains extremely powerful.

I've been using it for 15 years to automate network configuration deployment. Now that automation is all the rage in the industry it gets dismissed, but I find it is often much better than some of the other tools available.

Post reply on HN