HN Explorer

Ask HN: What's a strong “use everywhere” language for smaller problems?

2 points by auto ↗ HN
I constantly find myself hopping between all manner of machines. I use a Mac Mini and my MacBook Pro for work, and am ssh'd into servers and routers constantly, and my main machine at home is my Windows gaming rig.

Between work, personal projects, and being 4 classes into my Master's in CS, I'm really in need of dedicating myself to a language that's easy to write and execute across all 3 of the major platforms, that I can hack together solutions to smaller problems for. Up until about 3 years ago I was primarily an iOS dev, so my go to tends to be use my MBP and open a new XCode project in swift, but that obviously has its Windows limitations, and only slightly less so on the Linux side.

The majority of my back end work for my employer is Java, but that's anything but quick and simple for small problems. About 20% of my professional time is doing firmware dev for embedded systems, and I know how to write and run C everywhere, but it definitely doesn't feel like the right tool for the job.

Python? Ruby? Perl5/6/Other? I'd like basic stdin/out, probably file writing abilities, and db (specifically pg) integration would probably be a nice touch. Simple http servers are something I've got spoiled with as well. I didn't care a ton for node.js when I dabbled, but the < 40 lines required to have a http server with an endpoint up was handy. I had the same experience when playing with Go, but I haven't really caught up with it's usability in the last two years, maybe it has the sort of ecosystem I'm looking for.

I might be asking for a silver bullet that doesn't exist and I need to further tune where I'm willing to compromise for a single solution. FWIW, I've grown quite fond of the Swift closure style syntax, and just the process of writing Swift and Go both stand out to me as more positive experiences syntactically, as opposed to Java/Obj-C/C.

11 comments

[ 127 ms ] story [ 399 ms ] thread
bigiain
For me, it used to always be Perl5 (because I'm old, and it really used to be Perl4...)

These days - since I tend to need to share lots of my quick hacks and POCs with my much younger team, it's mostly Python2. (But I'm still not as fluent in Python, and occasionally it frustrates me enough that I go "Fuck it, I'm just gonna do this in Perl!" and reach for my old familiar toolset...)

I think Python is a pretty solid choice for an "available everywhere, high hack-it-up-ability, readily sharable, and with enough StackOverflow answers that you can copy/paste the first 85% of nearly anything you need to do" language.

(But Perl is still my first programming-language-love...)

blacksqr
Sounds like your use case is perfectly tailored for Tcl.

Runs everywhere, simple for the simple stuff, scales well to moderately complex tasks, integrates well with C, can write a web server in a dozen lines, made for embedding.

bigiain
The only thing I'd suggest missing out for TCL is the implied requirements in the "work" and "masters degree" comments - that at least some of this code is probably going to need to be shared and used/understood with others.

For that reason alone I'd say Python is likely to be a significantly better choice. (If I'm interpreting the implications correctly)

I've got experience with trying to find people who can work in Groovy on Grails projects - it's not easy. That's not a great reason to stick to "mainstream languages", but I won't be making the Groovy mistake again any time soon... And while TCL is definitely _capable_ of replacing Groovy, it is the wrong choice for me that same way that Groovy was...

auto
I definitely see how that could be inferred, but here it actually isn't the case. I need something that works just for me, so the ease of use from anyone else isn't really a concern.
bigiain
In that case, if it were me - I suspect I'd be jumping into Swift. It _feels_ nice to play with (but playing with it is all I've _really_ done, so take that into consideration when evaluating this advice...)
vorg
> trying to find people who can work in Groovy on Grails projects - it's not easy.

That's because many of the people who used Grails to build a website didn't intend sticking around to fix the bugs or maintain it -- they just wanted to get paid and move on to hawking themselves as experts in the next fashionable technology. Others chose Grails because they saw they could introduce loads of technical debt thus giving themselves an opportunity to charge a high hourly rate later on.

> I won't be making the Groovy mistake again any time soon

Oh, so you didn't choose Grails so you could skim an agent's fee from sourcing these people? Many did.

bigiain
Nope. I inherited this Grails codebase. The people and reasoning behind the decision were long gone before I started here.

There's a lot I actually (now) like about Grails. Hiring talent is definitely not part of that.

Ws32ok
Python, Lua, Perl, and oddly enough C. Embedding these in C also works well.

Interpret "Embedding C in C" as writing a dynamic linked library for an existing executable rather than something more exotic.

I recommend C here only for simple standard in/out style tools. Not complex all-in-c applications.

enkiv2
Try APL or Icon. They're terribly unpopular, but APL can't be beat for one-liners while Icon is substantially better at text processing than perl. Plus, both are still considered academically interesting, and both have open source ANSI C implementations that will build on any platform.
rurban
perl, bash and picat. C for the backbone work, picat for the hard problems, bash for simplicity, perl for the rest. and eventually pony for the massive parallel moonshot problem, when c++/openmp is too slow and insecure.