Original post: hachyderm.io (Mastodon)
Could be worse. At least it’s documented
To me the biggest problem, that AI might solve is documentation.
Have you tried to use AI for documentation? It’s pretty shit.
Have you tried to use AI for <thing>? It’s pretty shit.
Translation, proofreading, summarizing, brainstorming, boilerplate code, protein folding…
protein folding
We’re at the point where, due to how b2c tech services work, I think a lot of people think AI === LLM
How about this:
Humans (or humans assisted by AI) write documentation
Users (devs included) can either choose to read the manual the old fashioned way or utilize it like a sort of swagger api documentation to give- Information to a question (How to do x)
- Provide a general example
- (Assuming it’s used with an IDE or has information about the project) Provide a personalized example on the implementation.
I’ve used AI to give me a good enough guess that I know the right keywords to search for too find the real documentation.
I’ve had pretty good experience with using AI to find what I’m looking for in documentation, especially if the docs are in context
I think they mean having an AI read code and then write documentation for it. Not having an AI read documentation.
And you all complained when in C we used 1 and 0…
We use 0 and not 0…
Akcshually we use 0 and “not equal 0”, since “not 0” would be 0xFF…FF, and (at least gcc) gives back a 1 for a true expression. No idea about the spec, probably undefined…
Damn you for correcting me correctly! :D
Glorious. I remember some hilarious nonsense in an API where the devs I worked with hadn’t known they could just use boolean in JSON and had badly implemented it through strings, but this… This is amazing!
At my last job we had a lot of old code, and our supposedly smartest framework people couldn’t be bothered learning front end properly. So there was a mix of methods for passing values to the front end, but nobody seemed to think of just passing JSON and parsing it into a single source of truth. There was so much digging for data in hidden columns of nested HTML tables, and you never knew if booleans would be “true”, “TRUE”, “1”, or “Y” strings.
Never mind having to unformat currency strings to check the value then format them back to strings after updating values.
I fixed this stuff when I could, but it was half baked into the custom framework.
A system I work with gives all keys a string value of “Not_set” when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.
Of course, it’s up to individual developers to never forget to set a key to “Not_Set”. Also, they forgot to standardise capitalisation and such so there are all sorts of variations “NOT_SET”, “Not_set”, “NotSet”, etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).
Implying Hell is frontend… yeah, actually, that tracks.
Baseball, huh?
var true = false;var false = true;What happened to the good old
1Backend:
1Frontend:
¹2happened
Hear me out, what about using JSON to store the configuration in the Python backend?
You need to use as many different formats as possible, otherwise you look unprofessional
I like your idea, but hear me out:
A Python file for configuration is the best way to guarantee that any friendly code I write to help the user with config usually won’t execute. And I hate my users.
I’ve always hated case sensitivity. I know that at an ASCII level “variable” != “Variable” but is there really a reason to have a distinction between them?
You stated the reason yourself. Those are different values and matching in a case-insensitive manner is more work under the hood.
We do plenty of stuff for human consumption. Computers work for us, not the other way around. Insensitivity should be the default. It’s okay to give options. I’m not saying take that away.
Humans have to make it do the work. And that’s how Mr; DROP TABLE makes his money.
✋ Case insensitive filesystem
👉 Case insensitive file sortingFor some reason we decided that a lot of formats written by computers and read by computers would use ASCII encoding instead of raw data.
Making a json or XML deserializer case insensitive would just make it slower for almost 0 benefit.
You are thinking it’s easy because you only think of e == E, but I’ll let you look up collation and accents and, you know, Unicode and let you think about it.
There is nothing trivial about case sensitivity, except in trivial cases.
The backend and frontend on the product I work on are like this.
As long as you remember that booleans are not strings and should always be parsed if they are, this won’t be a problem.
I am yet to see a boolean.parse() implementation in the wild that is case sensitive.
The could be using .js and .py files directly as config files and letting the language interpreter so the heavy lifting. Just like ye olde config.php.
And yes this absolutely will allow code injection by a config admin.
That makes me think, perhaps, you might be able to set it to
exec("stuff") or True…isInHell = '(x + 1 > x)'Fun and games till x overflows.
LOL but it was ’ x + 1’ not ‘x += 1’ tho.
We don’t know what value X has. If it isn’t initialised it could have any value including the maximum. Then it would overflow.
But let’s be honest, that is unlikely.
Cap in the back, low-key up front. Got it.
!!true't'+'r'+'u'+'e'Why have the options be “frontend”, “backend”, or “none” when you can be this creative?
