Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
Perl as a scripting language remains undefeated. As in, let's say you are considering Awk for some task. It's probably worth learning how to do that task in Perl instead. The same applies to many classic uses of bash scripts: today, the biggest reason to choose to write a shell script is to provide some service which will be universally available on plausible platforms, and Perl isn't that ubiquitous any longer. But for most of what shell scripting was intended for, Perl is a more powerful and less, let's say idiosyncratic, choice.
Of course, with a bit more verbosity, any such script could be written in Python. Perl was designed to fit this exact niche, so it has a bunch of small affordances for doing script munging eloquently (not to say elegantly!) but Python, or Ruby for that matter, can also get the job done. Most people who know either of those languages thoroughly would pick what they know: they'll do the job, and that spares learning another language, which is indeed a quirky one.
But for those who do know Perl, it remains a very good fit for a Practical Extraction and Reporting Language. For those who do a lot of 'scripting' tasks in the original sense, it's worth learning imho.
Except, I know how to slice and dice text with awk, and can do it without leaning on ChatGPT or studying language documentation. Never made the leap to perl, the few times I tried I was put off because to a newbie the language looks like gibberish.
I would never consider perl for anything new in 2024. I still use awk very regularly.
> Except, I know how to slice and dice text with awk
I meant to say something more like "if you need to learn awk to do it, you may as well learn Perl instead". I figured from context that if you're "considering using awk", you don't know it, or you'd be "using awk". But no matter.
Perl can do everything Awk can, at least as well if not better. As fiddly, arbitrary, and limited, as Awk is, it's a lot less language, and that does come with advantages.
But I know from experience that you can learn the Awk subset of Perl as easily as you can learn Awk, and then you have a basis for extension to more tasks of a similar nature. If you want to see what I mean, there's a utility a2p[0] which translates Awk to Perl, this suffers slightly from machine translation, but it's a good demonstration that Perl can do everything Awk can in not just a trivial sense, but in the sense that it's designed to make Awk unnecessary.
So if you can get over whatever aesthetic hangup you have about Perlian line noise, you might discover you like it. Anyone using Awk "very regularly" is leaving a lot of potential on the table by refusing to learn Perl. Then again, sometimes it's best to stick with what you know.
I've started to write my one off scripts with an AI prompt, and Python as a simpler and more verbose language with a bigger training corpus is easier for that. Or I ask for a bash script! Still writing my one liners in Perl but they're getting shorter and shorter.
Ok, but if you’re comfortable using it, Perl is really fun, pleasant, and easy to quickly express ideas in. One of its conscious design decisions is to be flexible enough to rapidly bang out some quick hack you’ll never look at again in absolute incomprehensible gibberish shorthand, or to use in a very methodical, disciplined, and structured way — so if you write something unmaintainable, that’s because you chose to.
I haven’t turned to it as my first choice in years, but it still has a place in my back pocket for if I ever need a quick and dirty text munging Swiss Army knife.
I've used Perl extensively for a few years professionally. For prototyping, say text-processing stuff, I reach out for awk/sh, which are usually sufficient.
If I need more than a prototype, I reach out for Go. I have two major complains with Perl:
- it's more difficult to deploy (Go can be cross-compiled to a single binary which can then be scp(1)'d around, solid stdlib, no need to deal with dependencies on the remote, or modules split in multiple files);
- lack of static typing. You can get away with writing additional tests, but at the end of the day, that's just more work.
So despite being quite confortable with a fair subset of Perl, I (genuinely) can't think of a reason as to why I'd want to use it.
I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.
In a previous company, I had to support TypeScript code that wouldn't even survive 12 months without something breaking upstream. Granted there were a lot of other things that company did wrong...a hell of a lot! But it's insane how little importance people seem to place on code longevity these days.
I’m not on about fixing tech debt. That’s a completely different problem to picking boring technologies that don’t need constant ongoing maintenance just to keep running.
Tech debt is going to happen regardless of the technologies you pick. But some technologies require more effort to keep up-to-date than others.
I’d also argue that keeping technologies up-to-date isn’t “tech debt”. It’s operational overhead. Tech dept is something else entirely.
In my experience, tech debt often requires too great an investment to fix so the team just ends up bikeshedding to show progress but without real benefits.
Look at C. Each revision has added a bunch of minor fixes but has never addressed the core issues of the language that realistically require a rewrite (function pointer syntax, undefined behavior, null safety).
And there’s the fact that features bring in money and tech debt simply doesn’t. It’s still a business at the end of the day.
Right. I started a perl codebase in 1999, which has slowly evolved and is still one of my main projects to this day. The language has slowly improved, there are decent libraries for everything you might want to do, and I've basically never had to rework or throw away my code because of incompatible changes in the language.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.
My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.
Are you kidding? Python code bases break week-to-week because pip is full of unversioned transitive dependencies, broken distro nonsense, and who knows what else.
As of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).
python 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/
Oh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.
I was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [1]
The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that makes them easy to misuse. Few people know how to use them correctly or will be able to provide help.
No, instead they have subinterpteters with all of the massive overhead that brings re: data sharing. And even fewer CPAN modules are remotely thread safe than PyPi modules, probably in absolute as well as relative terms. That’s a low bar.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
I guess if the team is (only?) familiar with Perl. But then again, its the same with PHP. Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
I guess some people just want to stick with what they know, and refuse to learn anything new.
> Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
That really depends on the use-case. If you need a batteries-included web framework, the top 3 that come to mind are Spring (Java), Django (Python) and Laravel (PHP).
I recently read a new idea of why PHP is useful to people - it's the lowest-overhead server-side Web page language available. If you want a tiny amount of functionality, you write a tiny amount of PHP and don't have to do anything else. So it scales much, much better in the tiny-to-medium-sized project range.
(I can't personally vouch for the claim but it's the best explanation I've heard for how such a reviled language has survived this long.)
I run a WordPress site for my wife's business. Would I pick it up again in 2024? Absolutely. It has nothing to do with what I "know", there's still no better CMS/ small diy e-commerce solution for, frankly, peanuts in hosting.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
I think there are worse things than modern PHP (speaking as somebody whose primary contact with PHP is being traumatized by legacy PHP 7 projects). Afaik, the only places that will start a new PHP application today are places where the expertise is in PHP and Laravel/Symfony. I don't see a big enough benefit from migrating to a whole new stack that wouldn't be accomplished by some focused maintenance and refactoring if you're already working with PHP 8.1.
I write PHP for a living and I only write headless apps with Symfony and Laravel. Blade is an awful template engine with a primitive parser. Twig is tolerable, but for me nothing beats the DX of Inertia with Vue.
You are most likely right. I just fear spreading complexity everywhere. But I also want to take advantage of the vast compute available at clients. So, I am conflicted. Vue is probably a good compromise. Please share your best references on Inertia/Vue.
Only deployments of Inertia I have are internal code I can't readily share, but all it does is replace the very typical pattern of passing json-encoded props to a a blade template that contains a single React/Vue/Svelte component. Now you just return Inertia::render('My/Component', $arr) from your controller or route handler function, and you're good to go.
It also has various magic for router links that do partial refreshes and working with classic (non-json) forms and whatnot. I use none of those, I'm all about json and useFetch() instead, and Inertia's pretty good about getting out of your way when you don't need it. It lets you write as much or as little in SPA style as you want, it's more or less your favorite JS framework as a view layer directly without having to interpose another view as a middleman (the middleman is there, but it's all implicit: you add the @inertia directive inside your <div id="app">, and that's it)
I don't "start a new project" in Perl, but I certainly write a lot of Perl. Mostly one-liners and small scripts, and mostly throwaway. Perl is a very efficient language for string processing, thanks mostly to its built-in regex engine.
Once it grows a little bit more and starts requiring maintenance, I tend to rewrite it in a more maintenable language. Preferably a statically-typed language.
I'm considering it. It might be a language that does not need constant changes because of useless churn. Especially now, with the Raku split worked out.
On the other hand, the changes in my Ruby project have always been very manageable. Both the language and the ecosystem were reasonable those last years.
It's been my first choice for 30 years for anything involving a lot of non-trivial work with textual data (Including xml, json, etc.). And one-liners and any quick throwaway script, of course.
All Perl code I have ever seen, has been "write-only". Just completely unreadable and it was easier to just look at the output instead of the code when converting it to Python to get actual maintainability.
You are getting downvoted, but for me, it is the same experience. It's a dead language, and we are switching to Python, that is far better to maintain for me and for all our new hires. I mean, Perl doesn't even has a debugger on Windows.
Not true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging.
Definitely not a dead language. A mature and stable language, which won't surprise you.
The author mentions lustre, the web framework for Gleam that was inspired by Elm. I really like Elm. However, the limitation for me was the lack of a really robust component library. When I say component library, I don’t mean aesthetics but function. For example, a feature complete search bar with autocomplete, multiselect, create, delete, clear, etc. functionality. The reason I use typescript is because of component libraries like Mantine where generic components such as a search bar are already implemented, fully functional and accessible. I hope someone sees this gap and tries to fill it so that functional languages can be viable on the web!
Author of Lustre here! Yeah I agree, lack of a robust headless component library like radix-ui or react-aria is such a mark against Elm. I think it's even more important for Lustre because really all our users are going to be backendy folks with little interest in the nitty gritty frontend stuff.
Lustre will eventually have a companion ui library to plug this gap but it turns out maintaining all this stuff is a bit of a time sink, so I'm taking baby steps ^.^
ReScript is really solid in this niche IMO. It's basically ocaml that compiles to js. The standard library includes excellent bindings to react, so you can use react components without too much extra work. You do have to write your own type annotations for them, but it's way way less trouble than elm ports.
Looks like a great idea! It doesn’t support languages I am interested in right now but I will be sure to go back and check it out again. One suggestion, for words that break a line, the effect of typing perfectly on the background disappears. It might be a hard problem to solve but if the word is going to be on the next line when written completely, it should be in the next line when I start typing.
Almost all frontend fuzzy search libraries I tried fail in correcting small typos (whoch is pretty common when searching). From the demo it seems this library can handle it. I will definitely be trying it out on my own project. Thanks for sharing it!
I don’t know where the translations are coming from, but the quality of the Turkish/English translation was lacking. Unfortunately, It does not inspire enough confidence for me to use this tool.
The same is the case for the "Spanish" example, which is only barely understandable and lacks basic grammatical gender concordance:
> Una carrera comparativamente segura y próspera con algún prestigio básico automático es peligrosamente tentador para alguien joven, que no ha pensado mucho sobre lo que le gusta realmente.
If that's what's being presented for the world's 2nd most spoken native language and 4th most spoken overall, I shudder to think what the ostensible "Polish" equivalent phrasing is like:
> Porównawczo bezpieczna i dostatnia kariera z pewnym automatycznym prestiżem jest niebezpiecznie kusząca dla młodej osoby, która nie zastanawiała się zbytnio nad tym, co naprawdę lubi.
Hmmm we assumed that the translations for the Paul Graham essays would have been properly translated. Someone else pointed out a French issue earlier, both the French and Spanish examples were taken from their 'official' translation. Now I'm questioning everything. Unless we seriously messed up a copy and paste, it's possible we just used a bad source.
It is a bring-your-own materials type of app, so if you bring an authentically translated work, you avoid this problem. We try not to do any translation ourselves (although we of course allow it for convenience if you choose it)
It reads as a direct word for word translation of English as opposed to native speaker conveying the overall meaning using native language idioms and such. Its very difficult to translate things word for word and have them sound „native”. That’s why when you have side by side text is something complex, like a novel, translating authors often take creative license with text to make it sound reasonable.
The demo article only had a couple translations, so we auto-translated some missing ones. Sorry the Turkish one isn't great!
Most of the app we try to encourage you to use professionally translated works to learn whichever language you're studying, so try to do as we say not as we do :D
As I’ve commented elsewhere, to the extent you are using machine translation: note that GPT is bad at translation to languages other than English. Telltale sign is not declining for gender. I saw this a lot with GPT4’s Polish. Better to use one of the standard translation services.
Honesty this whole site is a gold mine. Even if you are not interested in using a functional language, if gives you a different perspective which was very helpful for me. I would recommend other posts as well.
The series on building a parser combinator from scratch has been one of the most valuable things I've read and worked through. A lot of concepts and mechanisms from that have been just incredibly useful working with typed languages in a functional style. I still will never know what a monad is tho.
I think this is a good step. However, there is still many things that Apple can implement easily to show that they care about Web Apps. One simple example is that you cannot lock the rotation of a Web App like a regular app. There is plenty of stuff like this that would make Web Apps feel native. I hope they improve upon these things.
