

Even if you want it to be human readable, you don’t need to include the name into every field and use balanced separators.
Any CSV variant would be an improvement already.
Even if you want it to be human readable, you don’t need to include the name into every field and use balanced separators.
Any CSV variant would be an improvement already.
About the title; my condolences.
Lots of "maybe"s, I see…
On which of those application types there are developers that write most of one of the halves, but do not touch the other half?
(Oh, yeah, on the phone apps, but only the ones that are a web site cached on the phone.)
The entire meme is about web-dev. That split between backend and frontend isn’t anywhere else. (And is stupid for the web too, but well, that’s what web-dev do.)
maybe that’s all the customer needs
The food truck is often better than the restaurant experience in every dimension… The same is valid for the app analogies.
How many people worked on it is not a dimension that counts.
It’s a nicer syntax for inline styles.
If you want to use inline styles everywhere, it’s great.
I guess some people write code, and some people also read and maintain it.
Yeah:
parseInt("a") -> NoT a NuMbEr
The Javascript literal interpretation of NaN never fails to amuse me.
who will happily come in and sort out your security issues later
I really doubt anybody will be happy about it, even after considering the size of the fees. And also, you have a very high estimation of the capacity of those people to notice they have to call you, I really doubt it’s deserved.
The restaurant has exactly the average quality of everybody that cooks.
Not of restaurant chefs or people good at cooking. Everybody that cooks.
Some declarations terminate on the name, other declarations go one requiring more tokens. In C, the only thing that differentiates them is the type.
Parenthesis in particular are completely ambiguous. But asterisks and square brackets also create problems.
Good, now invent a keyword for variables you don’t want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.
Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.
Even older variants required both a let to declare the variable and a dim to set its size.
I remember a REDIM
command, but I really can’t remember what basic it’s from.
You’d be surprised.
But seriously, numbers can be used as booleans in an impressive number of languages. Including machine code for almost every machine out there.
Besides, the waterfall style is that you get the perfect car… eventually… or rather, tomorrow, tomorrow you read this again and check if it’s the day you’ll get your car.
Nope. The requirements were always the same, and you are as far from them right now as you were at the beginning.
At this point, you are better inventing another name and publishing your branch as a new piece of software.
Oh, cool. I didn’t know about this one.
Trying Zed now on the eternal quest of eventually replacing emacs…
The amount of people on the internet seriously complaining that both Rust error handling sucks and that
.unwrap();
is too verbose is just staggering.