Just to give context here, NodeJS doesnt support enums, namespaces and class parameter properties. All of these have been described as regrets by Anders Hejsberg, and none of them prevent advanced use of the type system at all.
Yes, they regret them because they hinder adoptions. Why? Because nobody chose to add TSC with all features in their runtime because TSC is extremely slow.
They know they can skyrocket adoption by limiting the language. That's the reason they regret it. This is just a strategy to increase adoption. Not because they are bad features. They are in fact very useful, and you should not stop using them just because your favorite runtime decided to go the easy way and only supporting a subset of TS by stripping types. You should rather switch the runtime instead of compromising your codebase.
I've actually used this once! I built a slightly overengineered HTTP client where it would use a Reader Writer lock on the auth token. That way, if a token refresh request was taking place, all new requests would wait for it to finish writing, before being sent
This definitely has a GPT smell, at no fault of the creator. Reminds me of a PR i reviewed about a simple security patch, where the description said "The following changes have been implemented to strengthen our role-based access policies and system security" - Like yeah, it's security patch. A small tweak to his prompt would probably do the trick
No AI-based tools were used to make the lore. One of our developers (not me) is more of an intense reader and retro gamer; he was the one chosen to write it.
I wrote that down as an inspiration of Paradise Lost by Milton. The original idea was to appeal to the phonology of English and structure it as a sonnet, but that got rushed
Play "Turing Complete"! It gives a very intuitive understanding about how electronics become computers, but the best part is that you basically make the entire thing from scratch. Just completed it and had a blast
The VIPER pattern is my biggest bug-bear (but older than I realised: I didn't see it until recently, and it still seems to only be described on the German Wikipedia and not the English one), which seems to come with more glue code than business logic.
I also get annoyed by HTTP 200 responses containing JSON which says "server error", and web pages which use Javascript to re-implement links, image loading, and scrolling — all of which are examples of a high-level abstraction reinventing (badly) something that was already present in a lower-level of abstraction.
FYI, In the article:
> I believe it is the same reason why Python does not allow assignments in expressions: Python wants to clearly separate statements and expressions
I'm using SQLAlchemy to access external data sources to build reports on.
Essentially, I'm using it as a dumb BI connector (mostly to access a Databricks metastore), while my Django ORM manages any app information.
I'm not sure it's the most elegant solution, but it has been pretty functional
Unless you’re writing raw sql, Django does not make it easy to build reporting type queries with the ORM so I’d suggest you’re probably doing the optimal thing here.
Fun fact (and a bit of a brag, apologies), I was the contributor that added the “new” Expressions API with the intent of building a reporting platform on top of it. That platform never eventuated but I’ve still got lots of use out of those APIs.
Thanks, and you are very welcome to post it here. Also, if you or anyone else wants to adapt more of the official examples, create an issue with the link, and I'll add them to the repo :)
Source: 49m 43s https://m.youtube.com/watch?v=NrEW7F2WCNA