
Ask HN: What's a strong “use everywhere” language for smaller problems? - auto
I constantly find myself hopping between all manner of machines.  I use a Mac Mini and my MacBook Pro for work, and am ssh&#x27;d into servers and routers constantly, and my main machine at home is my Windows gaming rig.<p>Between work, personal projects, and being 4 classes into my Master&#x27;s in CS, I&#x27;m really in need of dedicating myself to a language that&#x27;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.<p>The majority of my back end work for my employer is Java, but that&#x27;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 <i>how</i> to write and run C everywhere, but it definitely doesn&#x27;t feel like the right tool for the job.<p>Python?  Ruby?  Perl5&#x2F;6&#x2F;Other?  I&#x27;d like basic stdin&#x2F;out, probably file writing abilities, and db (specifically pg) integration would probably be a nice touch.  Simple http servers are something I&#x27;ve got spoiled with as well.  I didn&#x27;t care a ton for node.js when I dabbled, but the &lt; 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&#x27;t really caught up with it&#x27;s usability in the last two years, maybe it has the sort of ecosystem I&#x27;m looking for.<p>I might be asking for a silver bullet that doesn&#x27;t exist and I need to further tune where I&#x27;m willing to compromise for a single solution.  FWIW, I&#x27;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&#x2F;Obj-C&#x2F;C.
======
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...

~~~
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.

------
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.

------
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.

------
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.

------
juststeve
python, go or possibly rust?

