I'll just come out and say that I hate every single configuration language. All of them suck in their own unique way and every time a new one comes out it fixes some issues of the language it's supposed to supersede but never without introducing new problems. And eventually you're left thinking that you should've just used a .ini file.
"Configuration" languages are fundamentally necessary and it's tragic that people don't understand why.
There are declarative and imperative paradigms. Software engineering layers them on top of each other. Frontend devs write imperative TypeScript to manipulate declarative JSX, which instructs a React library to imperatively decide how to layout declarative HTML, which instructs a web browser to imperatively decide how to render, and so on. The frontend sends an imperative API call to a declaratively-specified API gateway, which imperatively forwards a declarative request body to a backend service, which imperatively goes through validation, authorization, etc. before submitting a declarative SQL SELECT to a database, which imperatively plans out a query over declarative representations of data on the disk, sending imperative system calls to the kernel/disk controller, etc.
Python, JavaScript, Rust, Go.... these are all fine programming languages that allow expressing an imperative paradigm.
But we have fewer languages for declarative paradigms. So-called "configuration" languages are attempts to build higher-level declarative paradigms. Nothing more, nothing less. We need higher-level declarative paradigms to build on top of the current imperative paradigms. It is the next step in the march towards more power and expressiveness, and therefore more productivity and ease of maintenance.
Agreed and they don't have good escape hatches. What was supposed to be declarative always ends up requiring some logic here and there and then you're stuck with a terrible language like YAML and you have to turn to templating, references to anchors and whatnot.
What I don't like is when you need to use a configuration language like Bicep or Terraform when the underlying architecture cannot be represented declaratively. You can create resources and provision them, that's fine. But any time you need forking paths, specific conditions, iterations over some resources, etc. You're done for, unless the configuration language has built a command or keyword for your specific use case. You can always tell me that I'm holding it wrong but when the platform requires me to use those config files or the SDKs for whatever languages are useless, it's infuriating.
Side note and not related to configuration languages but how they're used on $cloudProvider. But when you declare resources or operations that are legal in the language but invalid on the plateform, I die a little bit inside. The platform has all the knowledge about the existence of resources, policies, behavior; there's a whole class of problems that shouldn't exist before you're even trying to run a pipeline!
I like how you shifted the goal post from “I” to “you” to justify your point of view. I don’t care, give me yaml, toml, json, jsonnet, ansible, who cares. It’s a tool. I’m not married to it.
I'll use what I'll have to use, it's a tool like you said. But I don't have to love it. Configuration is a necessary evil and whatever I end up using, I'm never fully satisfied with the end result.
Don’t comment then. You may not agree with me but I feel it is important to comment because it’s important to share an opinion shaping the path of new engineers joining the field. Tools are tools. Some are better than others. There’s no reason to have an emotional connection to them. Five years from now there will be new tools we never imagined we need. We are paid for getting the job done, not for an emotional opinion.
I actually really like the fact that my Garmin Instinct is not really a smart watch, it makes connecting it to your phone optional. Mine has never connected to a phone because I don't like to run Google's spyware on my phone. Yet, I can use most of it's functions I care about (time & date, GPS, moon & sun, compass, steps, heart rate, temperature, sports-specific stuff) without giving up my soul to Big Tech.
That probably doesn't work either unless they work in an automated fashion. Did the chef put two or three dashes (official SI unit) of this or that on your meal? A a "dash" or "splash" or "spritz" of certain things can easily mean 100-200 kcal. And if you deal with things like meat, maybe the cut you get today is more or less lean than what you got last week.
I think tracking calories for a couple of weeks can be very enlightening for a lot of people, granted you don't have a personality type where this can get you into trouble. But for the long haul it's not really useful or even feasible, you're better off getting to know what sort of way of eating suits you best and how to correct if you're getting off course. Anyone can stick to a very strict regime for three months, but the trick is to stick to a proper diet you can enjoy for three decades and then three decades more.
Healthy foods are not healthy in an excessive quantity. Diets don't need to be tracked to the individual calorie. We don't burn the same amount l number of calories each day and food labels show an average of the nutritional value. If a person is consistent, they will achieve the desired result; either gaining or losing weight.
I've been tracking consistently for about 5 years. It's feasible.
I'll second the recommendation of fiction (I love the classics) and add a recommendation for reading philosophy and specifically the history of philosophy. Learning how our frame thinking evolved from the time of the Greeks to the middle ages to more modern times has been nothing short of illuminating for me personally. I don't think you need to read the original works or the really academic stuff (you can if you want to) but having a feel of how our thinking got to be is really useful.
This shouldn't come as a surprise to anyone who has paid attention to their cats' behaviour when another pet dies. I remember when one of our four cats didn't come home, there were definitely changes in how the remaining three behaved. Apparently the cat got hit by a car and was found by someone and dumped in one of those bins where they dump dead animals for rendering. We took her home and laid her on the lawn so the other cats could know that she was dead. Each of the cats came one by one, giving it a sniff and concluding that she was dead. One of them however stayed with her until we took her away to bury her, an incredibly endearing display. It took a while before they all started acting like they did before.
And with the subsequent deaths of all the remaining cats, as they are all sadly deceased, I saw similar things happen.
We should not anthropomorphise animals, but that doesn't mean they don't have complex feelings or thoughts. If we find that even bees can "play", it's not that weird if cats can "grieve".
It isn't just cats. Elephants mourn as do whales and dophins, dogs, cows, pigs, parrots and other birds, and apes (including humans) among others.
If one has any sort of biology background the silliness of these types of studies is clear. Humans are simply animals, there is nothing distinct about us aside from being further out on the distribution of cognitive ability.
It would be news if an advanced member of animalia didn't experience grief from the death of another. If an animal can enjoy the presence of another animal (as they clearly can) it should be assumed they can mourn their loss.
Recently I attempted to buy concert tickets from a well known ticket seller. It insisted I was a bot, even after disabling my uMatrix and uBlock Origin. There was no way to prove that I was not, not even a CAPTCHA. So I decided to simply not buy any tickets.
This is just one example. I get increasingly frustrated by how shit everything is and my way of dealing with it is to disengage. It is rather sad, but I was not put on this earth to wrangle apps, QR codes, verification codes, passwords, usernames, e-mails, TOTP codes, updates, activation codes, etc.
I recommend buying tickets directly at the venue instead of ticket resellers. In most cases they will presell tickets at the door and you can almost always buy some at the door on the night of the show - unless it some superstar probably ymmv
I would have done that if the venue were closer to me, but it's just a little too far away for that. There might be tickets available just before the show, but I'm not willing to risk driving all the way there just to be disappointed and drive all the way back.
I am blessed that I have a number of excellent music venues in public transport distance and a very good ticketing agency about 30 min walking from my home.
So I often go there and by them in person - still I also use the online services when in a hurry, lazy etc…
Sugar alcohols will never be as popular as more obvious choices like aspartame and sucralose. Most people have at least some adverse reaction to sugar alcohols. Personally, all of them, used in any meaningful quantity, turn me into a bloated farty mess that ends with diarrhoea. Absolutely terrible stuff.
> Most people have at least some adverse reaction to sugar alcohols.
Citation? I have a decent number of friends who are sugar-free soda enjoyers. They don't seem to have any adverse effects from these sugar substitutes.
Can you link any papers about these adverse reactions?
I have yet to encounter a soda that uses sugar alcohols, most use aspartame, ace-K, sucralose, or stevia. Those don't bother me at all.
But the side-effects of sugar alcohols are pretty well known (especially to anyone who has had the pleasure of eating beyond their threshold). I haven't searched for any papers but I'm sure you'll find plenty that conclude that many people have adverse reactions to sugar alcohols.
This is very easily searchable. Here's the first result:
Gastrointestinal Disturbances Associated with the Consumption of Sugar Alcohols with Special Consideration of Xylitol: Scientific Review and Instructions for Dentists and Other Health-Care Professionals - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5093271/
Nothing is the way forward. It's programming, we make stuff that does stuff. Preferably with stuff that makes making stuff that does stuff easier and with stuff that will be supported for a long time.
Maybe I'm too cynical, but whenever something is presented as some messianistic "way forward" I just think "ah yes, another way forward" but feel we're mostly moving laterally.
It is exactly that. We make stuff, problems arise, we make new stuff that does not suffer from said problems.
Because everything is a trade-off, new stuff creates new problems. Those are the problems complainers complain about, ignorant of their history.
The cycle then repeats.
Maybe I am not cynical enough but doing easy things from the past is completely trivial and doing unimaginable things from the past is not that hard anymore. Looks like the cycle has some forward momentum in the end!
React since 17 feels like coding with LLMs: it had a bug, they asked ChatGPT to fix it, it addes more bugs, they asked ChatGPT to fix all of them and now we have a useless piece of software completely unrelated with the initial solution
But it all suffers. We have been doing web dev for 30 years and it all works fine, fast and scalable. I am not sure what other people are so obsessed with but we don’t have these issues.
So if we use stuff to make stuff easier why are people still trying to bang nails in with a piece of glass by using react when easy was using html/css/js made easier with htmx?
Well call me a heathen, but I've never even considered React. Instead I always generate HTML server side and spruce it up using a little JavaScript if necessary (I even use jQuery sometimes). It's reliable, works fast, easy to debug, requires little maintenance, doesn't require a build chain of >100K files of several hundreds of megabytes.
Of course I'm open to the possibility that I'm Doing It Wrong™.
