Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.
Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.
Just remember that if you aren’t actually concatenating files, cat
is always unnecessary.
https://porkmail.org/era/unix/award#cat
jq < file.json
cat
is for concatenating multiple files, not redirecting single files.
Meanwhile, I can open a 1GB file in (stock) vim without any trouble at all.
Formatting is what xmllint
is for.
:syntax off
and it works just fine.
I understand what you’re saying—I’m saying that data validation is precisely the purpose of parsers (or deserialization) in statically-typed languages. Type-checking is data validation, and parsing is the process of turning untyped, unvalidated data into typed, validated data. And, what’s more, is that you can often get this functionality for free without having to write any code other than your type (if the validation is simple enough, anyway). Pydantic exists to solve a problem of Python’s own making and to reproduce what’s standard in statically-typed languages.
In the case of config files, it’s even possible to do this at compile time, depending on the language. Or in other words, you can statically guarantee that a config file exists at a particular location and deserialize it/validate it into a native data structure all without ever running your actual program. At my day job, all of our app’s configuration lives in Dhall files which get imported and validated into our codebase as a compile-time step, meaning that misconfiguration is a compiler error.
You’re just describing parsing in statically-typed languages, to be honest. Adding all of this stuff to Python is just (poorly) reinventing the wheel.
Python’s a great language for writing small scripts (one of my favorite for the task, in fact), but it’s not really suitable for serious, large scale production usage.
Ah gotcha, fair enough. Definitely depends on the workload. If you have compute you want to dedicate to solely to a single task, have at it.
Umm, queueing is standard practice particularly when a task is performance intensive and needs limited resources.
Basically any programming language using any kind of asynchronous runtime is using queues in their scheduler, as well.
This whole situation just emphasizes the fact that rebasing >>>>>>>>>> merge squashing.
I definitely associate “ninja” with wannabe JavaScript developers.
Pureblood is pretty funny, though of course we actually use Haskellers. Honorable mention goes to “Haskellnaut” to (playfully) describe taking the language as far as it can go.
It’s perfectly stable. Linux just generally attracts people who like to tinker and tweak things, in particular because it’s much easier to do and gives you a lot of power and flexibility in making the machine your own.
My laptop running Arch Linux has remained problem-free for the last 6 years or so since I installed it.
Oh, if you worked at a company that uses them (which is a lot of companies), you’d definitely be familiar with them as they hog up a ton of fucking CPU/disk. I basically had an entire CPU core dedicated to running their bullshit.