The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature.
Less is more.
If you can get a module to do the same thing with a simpler interface, then that's generally a better module; it's typically a sign of good separation of concerns. Complex interfaces are often a sign that the module encourages micromanagement of its internal state; a leaky abstraction.
A module should be trusted to do its job. The only reason a module would provide complex interfaces is to provide flexibility... But modules don't need to provide flexibility because the whole point of a module is that it can be easily replaced with other modules when requirements change.
It's even better than it looks in Europe: there are actuality 3 contact points but only 2 are salient which allows for 2 easily pluggable positions (rotate 180deg). The ground is positioned twice for that matter.
Only France has a variation around that to my knowledge, that is still compatible across Europe.
And no one notices and just plugs in and out without thinking twice about it.
There are some unsung heroes here.
AFAIK Italy is the major outlier in having widespread sockets[2] that do not accept the Europlug
[0] https://en.wikipedia.org/wiki/Schuko
[1] https://en.wikipedia.org/wiki/Europlug
[2] https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Ita... the one on the left, rated for 16A.
Speaking strictly on plugs - while I agree it is simpler/easier - I disagree that EU plug is better.
For the bulk and lack of directionality - significantly safer (pin lengths, shielded to tip), requires a ground pin even if dummy, carries 13A easy!
The safety aspects are incredible[0]. I do not worry about my small children at all.
Lived in HK where the EU (China) and UK (HK) are pretty common in one household.
The advantage of the U.K. plug is that live pins are physically blocked and only released when the Earth pin is present. This is why the Earth pin is slightly longer on U.K. plugs and why insulated devices have a plastic Earth pin rather than no pin at all. The advantage of this is so you cannot jam things into them (either accidentally or intentionally) without the Earth pin. Thus making the plug much safer.
I’ve found U.K. plugs to be much more secure inside the socket too. US plugs often come away from the wall when there is a little bit of weight or tension on the plug. U.K. plugs require a great deal more pressure to come loose from the socket.
If I were to bring this back to types I’d say one needs to evaluate what the requirements are: safety or convenience.
[0] https://www.amazon.pl/Konstructor-Oryginalny-zestaw-konstruk...
> except the polarity isn't fixed, that's its one theoretical disadvantage
Polarity isn’t fixed on any mains sockets. That’s why the A in AC stands for “alternating”
However I always understood potential to be different to polarity. And that AC (which, to my knowledge, all electric grids globally carry) is the literal oscillation of polarity. What am I missing/misunderstanding from the GPs post?
But that’s what I meant, the UK and US plugs (as well as switzerland I think?) theoretically have one pin always be hot, one always be neutral.
With Schuko, you can reverse the plug, and it'll still work, which is on the one hand awesome when you've got a tight space and want more plugs to fit, but can also require higher costs, as you've always got to switch both wires instead of just switching the hot one (although this is best practices everywhere, as you can never know how well the electrician followed specs when wiring your apartment 90 years ago).
Half the breakers are connected to one hot, and half are connected to the other hot. For 120V you wire hot/neutral to the receptacle, while for 240V you wire hot/hot. (Plus ground, of course.)
In the EU, receptacles are wired hot/hot, and there is no neutral conductor.
The typical EU configuration:
The transformer delivers a neutral and three phases, in a star configuration.
That means you've got L1, L2, L3, N and GND.
N to any L is 230V, any L to any other L is 380V.
That also means a typical grounded socket has e.g., L1, N and GND, so a neutral and a hot.
A high-power socket or e.g. a stove will have GND, N, L1, L2, L3.
My stove has the oven running on L1 and N in a 230V hot/neutral and the stove at L2 and L3 in a 400V hot/hot configuration.
(Belgium is the exception, having phases at 113V off the center point, so sockets are in hot/hot to get 230V between the phases)
Here in the US, where split-phase is the residential standard, a house with three phase is quite rare. The HV lines running on poles in a neighborhood are mostly single phase, at least in rural areas like mine.
Yes! And many electrical devices rely on it, though sometimes fallback to regular 230V single-phase at 32A is possible, e.g. for stoves.
And considering a typical stove runs at 11-15kW and a typical electric water heater between 15kW to 25kW, you'll need it as otherwise you'll need far higher amps than is reasonable.
Honestly, only due to the technology connections video did I realize that the US does not use triphase power in most homes, which was genuinely surprising.
I have a friend with a Bridgeport vertical mill in his garage/workshop. He had to build a single phase to three phase converter, so he could run its three phase motors.
I see way too many folks trying to use Omit<>(…) and Partial<>(…) creating absolute typing monstrosities. Feels like typing duct tape and it’s impossible to read the type definition when it’s generated in a tooltip.
But what is actually inside the HTTP-payloads can then have many constraints on them which are not declared anywhere. For instance your code might assume the payload is JSON with several required fields in it.
If the server is new and fresh, yeah it's ok to assume the payload of a request will be a JSON object with some required fields, but leave the parameter there in case someone decides they will start sending XML payloads to it
This is where a lot of developers go overboard - not just in type systems, but in general. They are so afraid of duplication, they over-generalize and end up in a quagmire of unreadable overly complicated code.
Some duplication is easy. It's just code volume, and volume shouldn't be as scary as complexity.
I prefer some duplicate lines over having to go back and forth over some source files only because some developers think that less code is better code.
The code we create should be made for humans to read, no to machines and specially not to brag about how clever is our code
Once types get so complex, I’ve no idea what’s going wrong.
Today I had code running fine but throwing errors all over the place because some deeply nested type mismatch between two libraries.
I just any’d it… i aint got no time for that shit
But just like you probably struggled with and overcame many things before, it will be the same now. It's just that you can opt out of the typesystem in typescript whereas you are forced to learn how to deal with the runtime.
But if you make it, your development experience will change drastically. The time might be very well spent.
The problem with typescript is that the types are very often wrong or needlessly complicated.
Having separate type definitions from the library is stupid. Having types missing from @types/node is stupid. Many libraries lie about their types.
You can act like typescript is some kind of magic miracle that will save you time, but in reality it is just riddled with many small time-consuming stupidities. Typescript is just trying to a polished turd. Shiny on the outside, but shit within, and this is by design because it needs to work with JS and other poorly typed libraries and code.
If I haven’t convinced you TS is a polished turd, just wait until you find out how to import a modern nodejs module in a typescript project. Hint: you have to import a .js file, even though your file is called .ts.
The tsconfig has so many options that every project is different and a lot of code isn’t interchangeable and can break if copied from one project to another.
Want to convert some TS code to JS without checking types? No can do! Ts-node can do it, but tsc cannot.
I'm not saying typescripts typesystem is perfect and I'm definitely not saying that most people use it correctly. But at least it has great potential, compared to e.g. Java and C# which still fail to let me describe basic data types and operations in the typesystem.
I kinda agree - often no amount of "this is a bad idea" will teach as well as just letting someone make the mistake and actually experience the consequences.
The only problem is that hard to maintain code often does not cause any problems until you write a critical mass of it and end up trying to develop enough non trivial extra features on top of it.
It's a matter of choosing a solution that is clear, easy to understand, and easy to maintain. There are nearly limitless solutions that can fit that definition.
Restraint comes into play because devs tend to "treat every problem like a nail when they have a hammer". When devs learn new concepts, they often look for places to use that concept even when it's a bad fit.
An example of this is excessive use of inheritance when simpler types fit better. Many of us have dealt with the greenhorn that creates a giant inheritance tree or generic mess after they first learn that "neat" concept.
The reasons OP encourage restraint might be the mental overhead of understanding what's "correct", as well as needing to rely on not only yourself but other people to be correct.
Sometimes simple is faster and harder to screw up.
I feel like readable dynamically typed code is more easily "trained" onto younglings than typed equivalent.
I understand no typings allow for much much worse code bases, but my experience has been the opposite.
The devs now have guardrails in place to make sure they follow the spec...
Advanced types are invaluable when you are writing a framework or library... But in every day implementation, I agree they should be used sparingly.
I have 7 years of ts experience and I'll still 'as any' a reduce function from time to time
Ignoring the 60 different character definitions isn't going to make the problem that you have 60 possible variants go away just because you didn't type it.