And it was very condescending as well, like explaining to you that the sky is blue while you were debatting of the weather implications of the cloud shapes.
Oh! I am blind, and due to my disability, am treated in a condescending way on a regular basis, so I didn't even notice. But now that you point it out... I can see what you mean. However, being used to being treated like a small child by random (supposedly well-meaning) strangers is so normal to me, I failed to recognize the pattern...
Yes. I like to use type annotations on functions because it's documentation. If you use good names then it makes docstrings redundant. I'm thinking something like this:
def bounding_box(points: list[Point]) -> Box:
...
A decent IDE will be able to quickly jump to definition of those Box and Point etc. if you need it. This is much better than having a docstring and having to look stuff up manually. The fact you can run a static type checker like mypy is a bonus!
I also really like being able to document the imperative code like `def do_thing() -> None`. Of course, it's completely up to the programmer to follow the rule of not doing side effects in routines that return something.
But having to do it everywhere? Ugh. I don't think people realise how powerful duck typing is for doing polymorphic code. I can write something like:
def mean(things):
return sum(things)/len(things)
And I don't care what concrete type you pass me as long as it supports `sum` and `len`. What am I going to do, define an ABC or typing.Protocol called `ListLike` or something? Hell no, I've got better things to do.
But of course learning when to define static types vs when not to comes down to experience. Python treats you like an adult. I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls.
You picked a poor example for `mean` because there's a very easy answer: collections.abc.Sequence – typing.Sequence in earlier versions – an object that supports __getitem__ and __len__. You can check the collections.abc documentation[1] for the available protocols; you might be surprised about how much they cover already. I often use Sequence/Iterable or Mapping as parameter types instead of concrete types like list or dict.
> I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls.
Now, I want it because it makes my life a lot easier. It finds many classes of errors before runtime and improves auto-completion in my editor. For most programs, it's not a lot of effort. The frustrating part is interfacing with untyped libraries while using strict type-checking, but thankfully, more and more libraries are adopting typing. The type system itself is fine: most things you want to express are doable, but it's not at the same level of complexity as Typescript. It's certainly a better type system than Go's for example.
Hmph, I knew someone would point out that `Sequence` exists or whatever... The point was really that this could be a new type that isn't fully captured by something built in.
As for `collections.abc.Sequence`, using an ABC sucks because then you have to define a class and inherit from it. I don't want to do that. I just want to pass something that conforms to the duck type. Are these now also defined as structural types/Protocols?
> But having to do it everywhere? Ugh. I don't think people realise how powerful duck typing is for doing polymorphic code.
Duck typing is indeed powerful, but it does not need to be a runtime check.
> What am I going to do, define an ABC or typing.Protocol called `ListLike` or something?
Yes, how am I going to know what types I can pass to mean instead? I would go to the extreme of saying that a lot of python code should be type annotated (if annotated at all) with protocols instead of concrete or base classes.
Of course until type checking is properly integrated in the interpreter this is all kind of pointless.
> Yes, how am I going to know what types I can pass to mean instead?
Oh, if I'm writing it for you (ie. I'm writing a library) then I'll put documentation (probably as type annotations, as I said in the first half of my comment). But a lot of code I write is just for me, or is going to be part of a completely self-contained project and it would be obvious from context what to pass. Like I said, it's a judgement call that Python expects you to be able to make.
As an undergrad, Python was my favorite language. Now it's one of my least favorite because of dynamic typing and the poor dependency management.
Python dicts, when used as composite types or records, are a literal hellscape. Grepping through the code to find out where stringly-keyed fields get written takes way more time than thinking about types ever would. These should be structs.
Static typing has so many advantages:
- It lowers the software defect rate. All type errors are caught for free at compile time instead of runtime. This makes the software strong and rigid instead of brittle, and it removes an entire category of tests you would have to write and maintain.
- Static typing makes code maintainable for other people, including future you. It's self-documenting. You know precisely what things are in the immediate scope.
- Static typing makes bug-free automated refactoring with tools possible. There is no greater pleasure than mutating code via its AST.
Static typing is not hard, either. Most typed languages don't require type declarations except in structs and function declarations - that's really not a lot of effort.
a type system is useless if you have no guarantees whether it will be used by any code you use. And if any code that declares types can violate them at will.
Optional is equivalent to no type system at all, in my opinion.
Just because a type system is optional doesn't mean it doesn't do anything, it just means that you can control how much checking you get, both in terms of the code that is typechecked and how strictly it is checked. Avoiding some type errors through type checking is much better than not having any type checking. Or put another way, optional seat belts are much better than not seat belts at all.
except in the real world, seat belts are mandatory. Because not wearing them is always a net negative.
giving me some confidence is completely useless on a large scale, especially because the type system could literally be lying even when it does give me something when it is optional and unenforced (an external linter does not count as enforcement, because it is not exhaustive). I still have to write tests for everything to check types, or run some external type checker which is guaranteed to not be able to catch all errors because the language semantics don't even allow for it.
giving me full confidence is not. In typed languages, if the compiler (not some external tool) says there are no type errors, then there are no type errors. I'm not "reasonably confident". I'm sure.
i also care about usability of the dependencies for myself, the dev. If the dependency doesn't provide type information, I can miss bugs in my own code.
That misses the primary reasons many people use Python: the ecosystem and network effects. I would not use Python if it weren't the only language my colleagues know (many of them not computer scientists by training) and if it didn't have the best (or second/third best) libraries for almost everything.
I have no inside knowledge. But given the performance and scale chatgpt runs at (and the caliber of the team), I think it’s safe to assume a lot of their production code is written in C++ / cuda.
Python is really popular for both training and inference, and in both cases it uses native-compiled libs under the hood to ameliorate performance problems. I mean, maybe they’re chasing the last few % now, but it looks to me like most of their R&D is focused on their models and their interactive capabilities.
It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets...
It also has complex rules for:
- scoping (plus global variables by default and hoisting)
- "this" values (and manual binding)
- type coercion (destroying commutativity!)
- semi-column automatic insertion
- "typeof" resolution
On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM.
There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway.
There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.
I feel like a large slice of JS’s complexity comes from footguns you aren’t really supposed to use anymore; whereas with C# the complexity feels quite layered, multiparadigmatic, something-for-everyone, syntactic-sugary. But I probably know too much about JS and not enough about C#.
At least in C# you can ignore most of it and the complexity doesn't really come from numerous foot guns. You can still write Java 1.6/.NET 2 style C# code just fine, it's all there. The rest of the features can be fully ignored and they won't hurt you.
But then again the newer features they do make writing code a lot nicer, giving more compile time analysis warnings etc hopefully resulting in slightly better code. And the new features also enabled a lot of performance improvements in the runtime which is nice. .NET 2/4 wasn't all that fast, .NET 8 can be a lot faster.
Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.
Does Crockford "like" OG JavaScript? He's most famous for writing a book that shits on how much of the language should be ignored and avoided. To be fair, a lot of that was right, but it's far from comprehensive for the language we have today. Seems like despite another decade of improvements on the language The Good Parts lives on in the minds of readers as something relevant today-- while a new treatise on The Good Parts of modern JS is not present. There are definitely parts of JS today that should be discarded, like "var", but The Good Parts cannot help you with that, because when it was written you could not discard it, as there was no other option.
I've seen developers make complete messes of codebases that when using modern JS features would be mostly trivial, and they hide behind The Good Parts to justify it. And this includes suggesting that classes are somehow bad, and avoiding them in favor of POJOs and messily bound functions is preferrable despite JS not receiving a dedicated class concept until years after The Good Parts was published...
Does TS make JS non-smalltalky? Static typing which is optional.. and you still get a REPL, online compiler and the ability to dynamically inspect objects in your global object...
v1 of TS had a heavy "OO"/class-based bias to it, v3 and v4 made it viable for real-world JS code but peoples perception stayed both due to those who looked early on seeing something they didn't like or the code produced by many who loved it early on.
> the original small talk-y beauty of The Good Parts
Javascript seems much, much, much closer to Lisp than to Smalltalk. Granted, all three are very dynamic, but message passing needs to be bolted onto javascript. Meanwhile pretty much all of lisp is included "for free" (...via some of the ugliest syntax you've ever used).
Totally agree, if JS had further leaned into it's smalltalk-y-ness and ended up with dynamism similar to Ruby for example, I'd actually be really happy with it personally. True message passing and more metaprogramming features allowing you to change execution context would be fun to play around with in a forked version of JS somehow.
How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well.
Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style without adding maybe more than a few type declarations and some functions typings.
I'm all for people writing functional code with Javascript-- but when people eschew classes because of their "stink" and proceed to use all of the stateful prototypal archaic features of JS instead of classes, I have to protest. If you are using this and function binding and state extensively in your "functional" JavaScript, you are reinventing classes poorly. And classes are a part of JS itself, not something added on to JS by Typescript (in the current day).
The Crockford crowd would like us to live in a world of ES5 as if that's some kind of badge of pride, while justifying it with a warcry of "functional", while breaking the preconceptions of functional programming all throughout.
My point was rather that a functional style with plain old data was always preferable, the "stink" was that early TS versions _favored_ non-functional OO style that suited the TS type system at a time when most modern JS code already had a functional approach, so you ended up writing non-idiomatic JS because the TS type system wouldn't handle idiomatic code (this also contributed to a lingering distrust in TypeScript that persists to this day despite the upgrades to the typing system).
Personally I prefer neither prototypal or classes, 90% of the time you just want the interfaces, unions or inferred types and the few places where you actually want inheritance and/or object methods you really are just better off with a factory method that then creates a literal that is used or suits an interface.
Using JS/TS in a functional style doesn’t mean using prototypes or function binding or anything. I’m not sure how you inferred that from the comment you’re replying to…it just means using plain objects (TypeScript even, a little awkwardly, lets you express ADTs) and plain functions, perhaps with the module system to organize them.
Yeah, iirc private properties (added in ES2022) are currently the only part of ES6 classes that can neither be created nor accessed using prototype-based code, to the consternation of some people when they were added. Of course, provate properties can still be readily emulated with a WeakMap in a function scope.
Hmm, I understand what you mean. But I think there's a difference between complexity and optionality / versatility.
For example, it has different ways to declare functions because assignment is generally consistent (and IMO easy to understand) and the "simplicity" of Javascript allows you to assign an anonymous function to a variable. However, you can also use a standard function declaration that is more classic.
But I do understand what you're saying. If anything, I think it's generally in agreement with my feelings of "Javascript doesn't need to be more complex."
> There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.
This is hilarious and probably true. I think I am the former since I've been working with it for 20+ years, but I also think there's a reason it's the go-to bootcamp language alongside Python.
I do appreciate the modern features a lot personally, and the fact they have been added without breaking the world. Interpolation, spreading, map and arrow functions are a huge usability boon. Plus I'm glad I can use classes and forget that prototypes ever existed.
But I train beginners in JS and boy do I have to keep them in check. You blink and they shoot their foot, give the pieces to a dog that bite them then give them rabbies.
In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.
I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset.
In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that.
I do wonder if there will, one day, be a breaking fork of JavaScript that only removes things. Maybe a hypothetical "super strict" might do the job, but I suspect the degree of change might not allow "super strict" code interacting with non "super strict" easily.
BiteCode_dev has provided a pretty good summary of a lot of the issues. A lot of them have easy fixes if you are prepared to make it a breaking change.
ESM is the closest to a major version for JS. It forces strict mode, which includes many non-backwards compatible changes [0]. Most notably, it removes the `with` statement. Other examples of removals are octal literals or assignments to undeclared variables.
Yep, it's going to take time but eventually one day the vast majority of JS code in the wild will be strict mode and the non-strict stuff will be de facto deprecated and not expected to work everywhere
That's certainly true when writing code, but when you are reading code someone else wrote that flies right out the window. This is hardly a unique problem with Javascript, many languages get tagged as "write only" because there is such a large array of available features that you never know which subset someone is going to use. C++ is notorious for this for example.
after the success of the Good Parts book there were a few other books with the "Good Parts" in the title - like HTML and CSS the Good Parts, and Java: The Good Parts. I seem to remember looking through PHP: the Good Parts and feeling that it was just a learn PHP book, that it did not really differentiate between any core good parts of the language, the parts you should really learn and use.
I sure would like a real "Good Parts" series of books.
it's because people are talking past each other, and that's because people are using language wrong, and are merely talking past each other. The word simple is often used to mean "easy" or "familiar".
Simple is very different from easy, and familiar things are easy but doesn't have to be simple at all.
There is no wrong use of language; there's just people who don't bother to communicate well in the most effective language available. In this case you could simply cohere the two viewpoints since you have insight rather than blaming one party and calling them wrong (...which is wrong).
I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.
> what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?
Trying to understand the speaker, presumably, and not wielding your pet definition like a semantic argument. It's fundamentally boring conversation with no benefit to either party and it makes you look like an illiterate ass.
Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing something particularly clever. It's a unique mess that has lead to something no purer language could dream of.
It would have worked out fine if we managed to lose the prototypes without ramming classes into the language and baiting all the Java dickheads over to the web ecosystem.
Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".
> Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".
I still don’t understand how someone looked at Spring and thought “Wow, that’s pretty good! I’ll bring it to platform that has worse performance than Java, to language that was designed with dynamicity in mind and has no native static typing”.
Asking out of curiosity. What's your rationale behind Spring is slower? Worked on couple of greenfield and existing Spring Boot applications and we never had any performance issues caused by Spring. Spring has its own bad parts but calling that it has worse performance than Java is not one of them. Its not even a valid comparison. Java is crazy fast for a VM based runtime AFAIK.
The "scheme inside" might be missing the mark in any number of features, but in the end the resulting effect it had have been profoundly, well, effective. It's there.
People have been going all SICP (Abelson/Sussman) on JS ever since Crockford exposed the hidden scheme (or hidden not-scheme-at-all, if you insist) and moved JS far, far away from the humble prototype OOP it started as. And that had little to do with any language extensions that had been creeping in very slowly given the lowest common denominator nature of web development, and everything with the funky scope binding tricks that generations of programmers had been taught in the memorable "let's make Scheme OOP" drills of SICP and the MIT course (that so many other universities based their teaching on)
This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons.
That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.
I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.
I prefer languages with a small instruction set, as then you can learn all you can do in the language and hold it in your head. JavaScript used to have a small instruction set, I don't feel it does any longer.
Aside from this I don't know that I see any benefit to these structs, although perhaps that is just the article doing that whole trying to write JavaScript like Java thing that making classes and constructors enabled.
Complexity isn't bad. If you have a simple language and you have to something complicated then you still have complexity, it's just expressed differently and uniquely in every code base.
Java doesn't have unsigned integer types because that is "simpler" but that doesn't remove the need to deal with unsigned integers in file formats and network protocols. But now you have to do a convoluted mess of code to deal with that. I'll take a complex language that solves real problems over a "simple" language any day.
And ESM vs CJS. What should be an inconsequential transition, has turned into a minefield where adding a dependency to your package.json might blow up your build system, testing library or application without warning. Literally wasted weeks of my life debugging this pile of poop that is the JS ecosystem.
I guess technically Node, but in practice JS, since Node is still the de facto standard non-browser JS runtime. "Just use X" where X is some other build tool/runtime/testing ecosystem is another weird trope that's somehow considered acceptable advice in JS, but would be a massive undertaking for any non-trivial project.
Maybe if someone suggests Deno or similar, but Bun is a drop in for Node and is as such completely interoperable with your Node code. Its similar to how you can adopt PNPM easily because it’s a drop in for NPM, where as yarn and others are their own things.
Edit: And speaking of assignment versions, there's a new comment that adds a third of the same. I kinda get the feeling a lot of the "multiple ways to declare functions" is just people who don't understand how the pieces of javascript fit together and think these are all independent. They're not. Just declaring a function has only a few ways, but declaring a function and giving it a name multiplies that out to some extent.
In javascript, functions are first-class objects: they can be assigned to variables and passed around just like numbers or strings. That's what everything except "function foo() {}" is doing.
Python's `with` and Javascript's `with` don't do the same thing. In Python it introduces a context, which is a scope within which certain cleanup tasks are guaranteed, which improves the ergonomics of things that require you to close() at the end, similar to `defer` in Go. In Javascript it allows you to access object properties without prefixing with a name, which leads to confusion about scope.
Yep and TS has all of that plus a gigantic layer of bullshit on top.
The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.
I'm not sure what setup you have, but debugging TS code is pretty trivial. I use vite for all my projects at work and when running the dev server there is seamless integrations with the debugging dev panel in Chrome or Firefox.
Yeah I was almost gonna say it makes this proposal feel redundant. I can enforce object shape pretty well using TS, not sure why we need another OOP like thing that tries to do the same.
Yeah I recommend reading “JavaScript the good parts” and don’t use anything far beyond those. Instead of “compile-time safety guarantees” by these vendor-lock-ins-masquerading-as-open-source, just use the language as it was designed: dynamically, and unit test—because you’re gonna be doing those anyway.
Have to agree, 3 body problem is fascinating from technological future fantasy perspective, but high quality reading overall in English it was not. Shallow characters, very pro-china and anti-whole-western-world black&white mindset that modern free world grew away long time ago.
Had to force myself reading to the end of trilogy, above goes into overdrive.
You read a pop sci fi book and are surprised when you get pop sci fi? Chinese culture tends to place much more emphasis on prose in general in pop books in my experience but you picked one of the worst examples of that. That series is very strongly influenced by western sci fi culture so I find it really funny that you use it as an example of chinese culture being worse.
Whoa I never said Chinese culture is worse and I certainly dont think that, why the needless fabulated attack?
I just didnt like the books apart from technological aspects that much, is it that hard to understand and accept that some folks look for more than just wow-what-a-cool-description-of-4D-in-3D?
It was pushed from all directions as something spectacular and well, that bar lies much higher for some, thats all.
I feel like someone who wasn't familar with Chinese history or culture would miss a lot of what was happening in that book. A lot happens that isn't directly explained.
Also depends if you read the version with the cultural revolution scenes in the beginning or in the middle.
I'm apple hater but you got to recognize they do better at privacy than Google.
If you care about the NSA, then you better not have any phone. Whatever it's a android, iphone, grapheneos, anything. Israel blowing up pagers is a proof that nothing is impossible to them.
But if you want to say fuck off to the big data harvester like Google, Microsoft, Facebook, and so on.. then apple isn't bad at all.
You just got to deal with the usual apple bullshit, no side loading, repairability, thunderbolt charger, no headphone jack, etc.
Your privacy is as strong as your weakest Link. NSA only need one a few vulnerability to be able to monitor what you do, it may be on chip maker, network provider, operating system, compiler, etc..
That's a lost battle, if they want to see what you do, they do and there is nothing one can do but force them legally not to do so.
I am sure there is a name for this fallacy, but being better yet not enough at something where bar for reaching privacy is so high isn't cutting it. The result is the same, sans warm fuzzy feeling not anchored in sad reality of 2024.
so instead of an actual improvement just settle for second least worst? ironically google pixels are 100 times more private than any apple device will ever be because you can securely run your own 100% controlled open source OS such as grapheneos.org which is an actual private as in feature not marketing OS.
A phone has several levels of software and hardware, the OS that the user knows is not in charge of communications, its main role is to interface the user to the computer inside the phone. The phone OS sees the phone communication hardware akin to the way it sees an Ethernet card. The phone communication hardware (named baseband modem) is also under control of the SIM and every time the mobile operator wants to change the behavior of the baseband modem it can through the Sim toolkit.
Believing the software can somehow be separated from the hardware is a lie. They can mitigate at best the the amount of information one can extract but at the end whoever control the hardware can have access to extremely private information.
A gyroscope sensor is able to accurately record what one say close to his phone. It doesn’t even need Android to run he has access to private information.
And if you've missed it, note the prior "verified contact" key exchange added to iMessages, as well as the "sorry we can't read your backups to help you recover your data" security added to iCloud (provided you only use devices up-to-date and opted in). This one is a customer service nightmare, they added it anyway.
All that said, this article is less interesting since (a) if your cell phone uses a telco, "they" know where you are, and where you've been, no Apple needed; and (b) unlike Apple segmenting your Maps directions to prevent themselves from knowing where you are going, Google's always been about your location.
Apple was caught issuing issuing OCSP queries (hello, XKEYSCORE) every time an app was launched, promised to stop logging and build an opt-out, then reneged and memory-holed the promise.
