That’s more of a weakness of yaml. There’s so many ways to specify the exact same thing. Not exactly what you need for configuration files maintained by multiple people. It easily becomes an big incoherent mess.
In JSON the default way is the only way. Nice and coherent.
I agree that YAML is painful and it really seems like it’s had a lot of feature creep.
JSON is painful in its own way too, though. There’s a lot of syntax noise from things like braces, quotation marks, etc, so it’s easy to make a mistake. Regular JSON doesn’t allow trailing commas.
YAML tried to solve some of that, and did succeed in some ways, but introduced its own issues.
TOML seems great to me, but maybe it has its own issues. TOML actually has defined data formats for things like dates (both offset and local) and times, which is missing from both JSON and YAML so every app ends up doing it its own way.
Reference: xkcd #1172 - Workflowxkcd: Workflow https://xkcd.com/1172/Hover text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
I’m guessing you’re using opencart cuz I’ve been working with an old codebase for around a year and I would love if any code analysis or intelisense actually worked… on xml files… with php in them… with javascript in php variables… with calls to php inside xml files…
QL was our first game and although it was a big disappointment losing the source code it was lost at a time before we understood decompiler and auto-formatter software.
The time at which the source code was lost is irrelevant for decompilation, decompilation uses the binary files. Those are the files that are out there being played right now.
Until recently decompilers tended to produce rough and useless code for the most part, but I'm looking forward to seeing what modern LLMs will bring to decompilation. They could be trained specifically for the task.
You’re missing the point of the comment you’re replying to, which is that the devs don’t understand decompilers RIGHT NOW, and it’s formatted in a tongue in cheek way similar to their current comment about VCS
I’m all for AI, but there’s gotta be a better way for machines to become intelligent. Not just “training and predicting without any thought in the process.”
You're welcome to try other methods but LLMs seem to be working best so far.
With a decompiler it should be pretty straightforward to automatically check for "hallucinations," the compiled code is still right there and you can compare the decompiled logic to the original.
'Yes boss, I need 16-Bit, 32-Bit and 64-Bit Arm and x86_64 ASM as well as MySQL, SQLite, Postgres, Firebird, Mongo and all other stuff too, so I need a lot of computers … of course all with Threadripper PRO 7995WX’s.
Hot take, C is better then C++. It really just has one unique footgun, pointers, which can be avoided most of the time. C++ has lots of (smart)pointer related footguns, each with their own rules.
Yeah. My journey of love, loathing, hatred, adoration, and mild appreciation for C++, ended with the realization that 90% of the time I can get the job done in C with little hassle, and a consistent, predictable, trustworthy set of unholy abominations.
Preach brother, I don’t think that’s a hot take at all. I’ve become almost twice as productive since moving from c++ to c. I think I made the change when I was looking into virtual destructors and I was thinking, “at what point am I solving a problem the language is creating?” Another good example of this is move semantics. It’s only a solution to a problem the language invented.
My hot take: The general fear of pointers needs to die.
I’m not a fan of C++, but move semantics seem very clearly like a solution to a problem that C invented.
Though to be honest I could live with manual memory management. What I really don’t understand is how anyone can bear to use C after rewriting the same monomorphic collection type for the 20th time.
Maybe I’m wrong, but aren’t move semantics mostly to aid with smart pointers and move constructors an optimization to avoid copy constructors? Neither of which exist in c.
I’m not sure what collection type you’re referring to, but most c programmers would probably agree that polymorphism isn’t a good thing.
That’s what std::move does, and you’re right that it’s quite an ugly hack to deal with C++ legacy mistakes that C doesn’t have.
I say move semantics to refer to the broader concept, which exists to make manual memory management safer and easier to get right. It’s also a core feature of Rust.
Also I’m talking about parametric polymorphism, not subtype polymorphism. So I mean things like lists, queues and maps which can be specialised for the element type. That’s what I can’t imagine living without.
Hahaha. I knew I was wrong about the polymorphism there. You used big words and I’m a grug c programmer =]
We use those generic containers in c as well. Just, that we roll our own.
Move semantics in the general idea of ownership I can see more of a use for.
I would just emphasize that manual memory management really isn’t nearly as scary as it’s made out to be. So, it’s frustrating to see the ridiculous lengths people go to to avoid it at the expense of everything else.
I definitely agree on the last point. Personally I like languages where I can get the compiler to check a lot more of my reasoning, but I still want to be able to use all the memory management techniques that people use in C.
I remember Jonathan Blow did a fairly rambling stream of consciousness talk on his criticisms of Rust, and it was largely written off as “old man yells at clouds”, but I tried to make sense of what he was saying and eventually realised he had a lot of good points.
Just watched this. Thank you. I think I’d agree with most of what he says there. I like trying languages, and I did try rust. I didn’t like fighting with the compiler, but once I was done fighting the compiler, I was somehow 98% done with the project. It kind of felt like magic in that way. There are lots of great ideas in there, but I didn’t stick with it. A little too much for me in the end. One of my favorite parts C is how simple it is. Like you would never be able to show me a line of C I couldn’t understand.
That said, I’ve fallen in love a language called Odin. Odin has a unique take on allocators in general. It actually gives you even more control than C while providing language support for the more basic containers like dynamic arrays and maps.
The only conceivable way to avoid pointers in C is by using indices into arrays, which have the exact same set of problems that pointers do because array indexing and pointer dereferencing are the same thing. If anything array indexing is slightly worse, because the index doesn’t carry a type.
Also you’re ignoring a whole host of other problems in C. Most notably unions.
People say that “you only need to learn pointers”, but that’s not a real thing you can do. It’s like saying it’s easy to write correct brainfuck because the language spec is so small. The exact opposite is true.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.