Why Static Typing Came Back • Richard Feldman • GOTO 2022 

Yeap, you pretty much need to run your code to understand the full behavior or luckily run your tests if you have them.

Only if you have some shared API repo, or using gRPC protocol buffers though

@@mattstyles4283 and it will have to be serialized to a type-less byte format for transmission & storage as well (plus handling stuff like endianness, encoding & locales).

@@switchblade6226 and all of those are already solved problems, thank you for polluting the comment section with a meaningless comment. Did you learned those words right before you made the comment?

I never understood this tradition of creating getters and setters for EVERY class member EVERYTIME. Sometimes it doesn't make sense to create a getter or setter for some members, specially setters (it defeats the point of encapsulation).

@@shimadabr if you think of it in terms of OOP, where messages are passed around, and objects can’t do anything but mutate their own state, send messages and receive messages, getters and setters are a must. Because they give the illusion that you’re doing proper OOP!

That’s a great observation

static typic is dogma I say!

@@Fs3iI don’t think he meant that getters/setters are always unnecessary; he’s talking about code where the developer mindlessly creates a setter for a field where it makes not sense to set that field from an external context.

Note that IDEs for dynamic languages had autocompletion, spellchecking, and type inference since ~2005, yes, they didn't get it right some of the time but it was right 95% of the time. I think documentation is important though, especially doctests.

Even as a solo dev working on small projects, static types stop me confusing myself. Instead of having to remember: "this function returns an anonymous obj in this specific format" I can read the function definition and go: "ooooh it returns one of those" and then go read the type defenition it returns

​@@huxleyleigh4856so return instances of classes instead

Returning instances of classes doesn't help in a dynamic language because the return type might still be opaque to the IDE.

yeah but type systems get in the way of reasoning about my code more often than not.

@jhoughjr1 The answer to this objection is simply time and practice. It may get in the way, but the upsides are incredible.

​@@jhoughjr1 I respectfully suggest that's because your reasoning process is not as rigorous as it could be and is not suitable to reasoning about very large and complex systems. For any large system with complex entity types in the problem domain, correctly determining those types and their relationships is a large part of finding the best solution for not just functionality but extensibility, maintainability, security _and_ stability. Something I've heard multiple devs say about Typescript for example is that once you fully understand its type system, you find yourself actually putting most of the business logic into type definitions, rather than in the algorithms which use variables of those types. From watching videos about Haskell, which I haven't tried yet, I get the impression that's the case with Haskell too, because of the way its types are defined (which I gather is based on all the things the type _does_). Type systems like this allow you to put system-wide constraints in one place in the code (the type definition), rather than redundantly replicated all over the code which tends to be the case when dynamically typed languages are used. I've worked with both statically and dynamically typed languages for 35 years (roughly 16 languages, I'd estimate), including procedural, functional, object-oriented and even stack languages, and like most people who've fully grokked the benefits of static typing, its obvious to me there is no contest in terms of which is better. The _only_ benefits of dynamic typing are (1) being easier to learn if you're new to programming and (2) producing less verbose code (for small problems). But they encourage far less rigorous ways of analysing problems and coming up with solutions that serve multiple desirable goals, rather than just the functionality that's immediately required, especially in products under continuous, incremental development. Statically typed languages are generally vastly better in every other respect (extensibility, scalability, maintainability, security, stability of code, et al) for any large complex system. The use of dynamically typed language can only really be justified when (1) the nature of the problem means the code will always be in small, self-contained units rather than integrated systems of any scale, e.g. code that wires up controls on a web form, plugins for 2d and 3d art apps and so on, and (2) for _prototyping_ systems rapidly, rather than for producing the final system the prototype is a proof-of-concept for. Make no mistake about it, dynamically-typed and idiosyncratic languages like Javascript and Python are not popular because they're good programming languages, but because they're easier to learn and in both cases there are other inducements to use them that have nothing to do with their virtues as actual programming languages. The "easier to learn" part comes with a catch: Because they demand less rigor of new developers and allow developers to produce useful results quickly with less knowledge and less careful thought, they also often result in sloppy solutions with long term technical debt, like making it a lot harder to extend the system later, or producing a massive ball of spaghetti as functionality is added over time without any rigorous thought, such that finding a memory leak somewhere deep in the spaghetti 5 years later is a nightmare. Where "other inducements not related to the virtues of the language itself" are concerned: In the case of JS its because it was the only language that could run in every browser (something webassembly is slowly changing) so you had to use it for client side web code and when Node brought JS to server code, it allowed web devs who only knew JS to write server code without learning another language. In the case of Python, which is a terrible language, its pretty much entirely because of Google being the driving force behind a lot of AI and data science in the 2000s, and adopting Python as the language for those efforts. And from what I can gather that decision seems to have been adopted because a lot of people working in that area were data scientists first and reluctant programmers second, so making it as easy as possible for them to convert their mathematical expertise into code, rather than making them good programmers, was the priority. As a result the language _ecosystem_, rather than the language itself, has a ton of stuff that is useful for data science and machine learning, like numpy. Equally useful libraries that do the same things can and have been developed for other languages, but the Python ecosystem has the most mature versions that the most programmers are already familiar with. It's a great ecosystem for machine learning and data science, built around a perfectly shit programming language. From a design point of view, since you're talking about reasoning about code, I worked on a lot of waterfall projects early in my career, where you spend 7 months just workshopping and designing a large system then only 2-3 months actually writing the code. And by the time you get to developing it, you're working from a rigorous technical specification which tells you exactly want you're meant to produce down to every last database table, class/module definition and all of their fields and methods, as well as a detailed description of every process flow and how all those structures interact at every step, before you even begin actual coding. There are no outstanding design decisions when you begin coding, you're just implementing the technical spec, which is often hundreds of pages long, with diagrams. There are no edge cases that take you by surprise after 3 months of going live because that's all been thought through and mitigated in the design process. If you designed properly and implemented the spec properly it just works. And its intimately documented if someone wants to add a feature later and wants to know exactly what they must change. Assuming some kind of impact analysis / change specification is done for those changes, the documentation is incrementally updated. too. And my personal experience is that determining the correct data structures/types (in both persistent data stores and runtime program state) for a problem of any size and complexity (like say developing an inventory management system for a company with many warehouses) is usually a huge part of that rigorous design process. A huge part of the technical debt I've had to deal with when working on legacy systems is due to poorly designed data structures that were dreamed up on the fly by some dev at 3am who just wants a solution to their present problem, not the correct solution for flexibility and long term maintainability, most often written in a dynamically typed language with lots of missing schema checks making it very easy to break things. Static typing at least compels the programmer to think about data structures/types more carefully when they're making those 3am decisions. I know test-driven development is very popular among dynamically-typed programmers and many seem to think that is sufficient to catch problems like missing schema checking that will cause nightmares later. But TDD always assumes that the tests cover all cases, which is hard to achieve in reality. And unit tests can't cover things that require integration testing, and replicating test environments consisting of dozens of interacting systems for integration testing is often a nightmare all on its own. Static typing actually removes the need for the majority of tests required by dynamically typed language in TDD.

@@farrenh Can't we agree that we should use the right tools for the right problem, and that sometimes dynamic typing is the more suitable tool? I would never go as far as claiming dynamic typing is always better (if I interact with other hardware, a database, network etc, then not only the datatypes, but endianness and exact lengths in bits as well as alignment etc are super important). On the other hand I'd argue that stating that "...languages like Javascript and Python are not popular because they're good programming languages, but because they're easier to learn and in both cases there are other inducements to use them that have nothing to do with their virtues as actual programming languages..." misses the point of these languages (in my opinion). In some cases it is extremely obvious what type/kinds of types/characteristics an argument to a function will have (good names, comments etc are good in all languages), and specifying the types explicitly adds nothing of value. Sometimes (again, I'm not trying to argue that this is true in general!) shorter is better, if it is allowed to mix objects freely in a list (without adding an interface/new type, inheriting it from multiple classes etc) then a simple runtime type-check to see if "is this a valid thing to exist in this list?" before processing it (plus a unit test or two) can have the same safety effect as hundreds of lines of static type word salad. If time/money was an infinite resource, all programs had to be at least a million lines long and lives depended on every single one of them, I might have agreed with you. But metaphorically speaking, if time/money had been an infinite resource, all my clothes might have been tailor made out of hand woven cashmere mixed with fine platinum threads and have built in air conditioning.

@@jhoughjr1 well a blade can get in your way of chopping wood if you grab the axe by the blade

Yeah, modern Java is nice. It's unfortunately got a lot of negative perception to battle though.

@@KyleSmithNH Nice may still be an overstatement, but it is a LOT better than it used to be and than people perceive it.

Its just @Data annotation with lombok which is basically industry standard by now...

Java's runtime is aweful!

@@bobweiram6321 Can you be more specific? There’s plenty to hate, so I’d like to know which part is grinding your gears.

all of the direction that Java and C++ was bad af, tell me a single feature of those languages you can think of that we haven't discarded or minimized because it wasn't harmful? every single feature those languages introduced has been discarded or replaced by superior features.

They were solving different problems. I've been programming about that long, too, and I have a clear preference for static typing. When your code base is 500 lines to assist your HTML, it's one thing. When your code base is 50,000 or 1 million lines, it's an entirely different thing. The scripting speed of dynamic languages pales in comparison to the time you spend figuring out "what fields does this method return?"

I was first introduced to programming with BASIC in 1973, typed into a teletype connected to a mainframe far away that we never saw. Why was that? Because people at the time thought assembler or ALGOL was probably a bit over complex to use for an introduction to programming for kids. WIth a few months we did move on to assembler and other things. The way I see it is that when personal computers and then the web burst onto the scene and all of a sudden there were millions of people out there who can now be introduced to programming for the same time. Naturally, following in the steps of BASIC, languages that were simple for beginners to get into and get the job down were developed and became popular. Something went wrong though, those millions of new programmers never did get pushed to "grow up" programming wise. They went on to build companies and mega corporations etc on the same beginners languages they were weened on. Really, they had little choice. Finally, the programmers of the world have grown up.

Yes! I learned programming in school and university with Turbo Pascal and Delphi and the first time I had to work with languages like Java or C/C++ I thought both about the IDEs/tooling and also regarding the speed: How is anyone supposed to work with that? It is like in the middle age.

@@mudi2000a I preferred the syntax of "curly braces" languages like Java/C/C++ than Pascal/Object Pascal but back then Delphi's IDE and components were indeed ahead of their time.

Yes it was never that you really need so fast CPUs to do "properly fast IDE"... I came up with an IDE idea that gives you these even on 8502 if you really want, because code would be not stored as text to parse but you would edit already parsed syntax tree for example. There are really ways to do it low-cost just there was no time to invent those (neither interest). Also pointing out delphi (or lets say Kylix which I used more in high school), these kind of things just worked fast-enough already on machines points this is again not really an issue of compuiter speed but implementation. Also if you look at completion of some good editor like vim and compare to VSCode for me even feels sluggish despite good computers (and despite people not feeling it) there is still a lot of waste. Btw the only reason why I can imagine the "pendulum swinging back a bit" is because nowadays even in dynamic or gradual typing people introduce as slow build steps like C++. Literally have a customer of mine where a full build takes MINUTES. It is like "what the hell? You still have type errors because its gradual typing but now you have build step which seems worst of both worlds"... But then that will only last as long as people realizing you also not need build step actually for static types haha., So even if pendulum swings back ever - must be temporary.

Delphi AKA OO Pascal

@@u9vata I think that on moderately recent hardware VS / VS Code are decent enough but indeed, responsiveness isn't perfect. For sure, they have more features than Delphi/Kylix (didn't use Kylix much, mostly only used it to get a Delphi console application running under Linux before switching to Free Pascal) but I can't help but think that there is not the same level of craftmanship or at the very least the same focus on optimization than in the old Borland days. That said, not all product from that time were as robust and well engineered than Delphi. I had barely tried it, but even C++ Builder from the same company felt subpar (I vaguely remember compile times were much longer and weird hard to understand compile and runtime errors - probably because of the constraints of the C++ language).

And generative testing!

I also like those, but I agree that as of now statically typed languages like those are superior to gradual typing, we have seen so many projects that were bootstrapped in Clojure/Script that have switched to something else like storm or aschiinema because the performance of clojure wasn't there. Now, his point of "I don't see a pendulum switch" doesn't make sense to me, because I do see a switch in the future, it just requires work from someone that knows about PLT & type theory & appreciates dynamic development workflow that only Lisp or Smalltalk can give. Things like dependent types, code synthesis, theorem proofing and having a dynamic runtime for development and fully compiled deployable binary with zero overhead, could be the future. but this is not something we are going to get from the clojure/script community. maybe from the racket community. I left clojure/script because I found the community to be very stubborn and irrational once that haskell & co had already proven with code that static typing is productive and very useful.

In gradual typing wouldn't you have to remember what every function does and how every time you use a function to make sure whatever you pass in doesn't cause compile time errors

@@laughingvampire7555 what are you using now? I want to be able to use Clojure more, but typing aside, it feels like it has a pretty small reach, not having a clear pure clojure path to mobile development or embedded systems or web assembly like other languages do so I'm a bit torn.

I remember around 2009 there was a talk by Steven Yegge about dynamic languages striking back, type inference on dynamic languages could give you type warnings instead of type errors and let you use autocomplete with 97% accuracy, and gradual typing could give you some of the benefits of dynamic languages, and the new jits (psyco, V8, luajit) were improving the performance of dynamic languages. Haskell actually soured my like of static typing since I didn't know about -fdefertypes and I kept getting difficult to understand type errors since I was relying too much on type inference, and I would often have to change types through the call stack to lift things into IO, State, Either, Maybe (Look up Clojure Maybe Not). More easy to learn static type languages like Kotlin & Swift & Elm are I think what swung the pendulum.

I've tried static analysis in PHP, 20k false positives. Fortunately PHP 8 has improved improved a lot.

@@aoeu256 That's interesting to hear! Haskell can definitely be a struggle to fight with sometimes, but for me, it actually increased my appreciation/reliance on static typing by a lot, to the point that Haskell is basically my go-to language for a lot of small ideas I have on the side and that I'm even doing some stuff in Idris, a dependently typed language.

This is exactly it. The code size of a modern web page is no longer 500 lines of HTML and 20 lines of JS.

Note that originally what OOP meant in Smalltalk wasn't the design pattern class fest in C++/Java. Smalltalk had closures (blocks) as methods were objects and loops were methods were objects and a lot of dynamic features like method missing/metaclasses to make coding much shorter and message oriented programming, while coding in the normal Java way actually caused your application to get more lengthy...

Also, pytorch. The fact that I can write code and it will navigate complex runtimes to execute on heterogeneous compute environments is practically magic.

I appreciate dynamically typed languages for their mutability properties the most.

On the contrary this has been extremely smooth in Python. I think possibly Ruby has more challenges with it, maybe due to having more syntax "already taken", so there is less "syntax space" for adding types. It can be somewhat difficult to add type annotations for example for a (fully generic) function decorator, you need to look up ParamSpec etc, but fortunately the vast majority of types even in dynamic code are actually simple (or generic over a single or few type parameters). The harder part for these languages is to make use of the type information to actually become faster. At least for Python, I think it will become more and more "reserved" for smaller scripting-type purposes simply due to people being more aware of its relatively poor performance for larger systems.

It's been my experience with early Typescript which is why I'm hesitant to use it till this day.

@@jolben Python3 Uses type hints. Just like Ruby typing checking can be turned off when the going gets tough for large code bases.

@@jolben But python's type hints are ugly and verbose. A simple type declaration requires typing a long list of spells such as TypeVar, Literal, and Protocol, which is only a little better than JAVA. Like the structure of T -> (False, None)|(True, [T]), this becomes Callable T Union tuple Literal False None tuple Literal True list T. And when the type hint warns about a issue, the message given is similar to the C++ template bullshit error message.

@@KevinSheppard Current TS is a really seamless experience, as long as you allow implicit any, it's really more a gradual typing approach in that case. Not only can you convert files one by one, even inside a file you can convert it bit by bit over time.

I can't for the life of me see the difference between these two meanings. To my mind an abstract value is a definition of a value, be it a definition what is an int or bool or some agregate like an array structure or class. Actual, concrete values being instances that match the abstract description. But at the same time that abstract definition also implies the bounds of the type, the range of ints, the size of arrays, etc. What is the difference I am missing?

@@Heater-v1.0.0 I think by "predicate bounding a parameter domain" he means things like int and by "concrete representation of abstract values" he means things like structs.

I think the Java example specifically is more an argument against (past?) Java's brand of OOP.

@@Kenionatus That's true, it feels like Java encouraged overengineering

@@Octal_Covers I don't think it's Java exactly. Maybe J2EE. Maybe certain segments of the Java community that were coming up with rules for Fortune 500 companies to try to wrangle certain types of problems. The main argument for getters and setters, after all, is reengineering -- which is inevitable in any real project that actually lasts for more than 5 years. There are good reasons you should "program to an interface". Doing so is more work up front, but it sure makes reengineering (and polymorphism) a whole lot easier down the road. You could implement his example in Java with only slightly more code than the JS version. (It's been a while since I've done Java, and I don't remember what JSON support is like.) You don't need getters and setters and all that other boilerplate, after all.

​@@jplflyer Yeah, I also felt that the Java felt a bit... off. His Answer class could perfectly well have just been field, field, constructor, all public. Because that'd be 1:1 the functionality the JS object gave him. Setters, Getters/encapsulation, he could have done those in old JS too. Equals and HashCode? JS didn't give him either of those (===/== is only object identity in JS after all) so if it's not needed in a Java class, don't implement it. Also, if he really wanted to display all the "possible" ceremony in the Java example, where's his toString? :D Interestingly enough, his explanation for POJO also seemed different from what I'm used to - the thing on his left is what we'd call a POJO back then.

@@Adowrath Overall, his talk had some interesting points. On the other hand, I was watching it and saying, "We told you. We told you."

I end up going in and inserting panics (or todo!()) myself to tell the compiler “don’t even bother with this chunk of code”. Wish I could automate that

This is the unsung benefit of the TS/JS paradigm: no matter how much TS is complaining, you can still run the program and see what happens.

todo!() and unimplemented!() should do the job

Absolutely! There’s no reason not to do that. It worked really well for Haskell.

Typescript is transpiled into JavaScript. Not actually compiled

@@-Jason-L A distinction that doesn't matter in this context.

This already started in 1987 with Turbo Pascal 4.0, 36 friggin' years ago. Why has it taken so long to figure this out ?

@@goblinsgym I'd say it started with Turbo Pascal 1.0; the compiling speed and the OG IDE workflow (write/compile/run/debug in the same program) gave serious heartburn to the juggernaut of developer tools at the time - Microsoft.

I think snappiness was also related to code size. If he was programming J2EE for a fortune-500 company, then there would be serious code bloat. It wasn't that the IDE was slow so much as the IDE had 200,000 lines of J2EE code it was indexing.

@@jplflyer Delphi is fast for large projects thanks to a very efficient unit system. Only changed code needs to be recompiled, and you never ever have to futz around with Make files. I remember reading the C++ book in the late 1980s, and trying to visualize what it would take to write a compiler for this mess. If it is hard for a computer to read, imagine what it will do to humans...

can you think of any traditional OO feature that hasn't been discarded, replaced or minimized? think of any feature of Java/C++ 2000?

Amen.

Unfortunately if you're using Java you're probably using it in a company that hasn't upgraded from as far back as Java 8...

PHP was not made with speed in mind, like, at all.

@@NXTangl The first version probably wasn't, but a lot of thought has been put into the speed of more recent versions.

An Option type or Maybe type that wraps around the normal type you'd return: Option may be a String or may be nothing and the caller will have to deal with it

I'm working in a 1.2 million lines lua game project... Project was started ~10 years ago... not sure how many programmers have been on it... but it must be more than 50 now. The problems I see in the code are old sins (crappy written early systems) and code complexity. The hard nasty bugs are not on the lua side, but the on the engine c++ side.

Not quite all uses (Typescript is "statically typed", but still interpreted). But I also felt like most of his problems were not about being statically or dynamically typed, but about being compiled vs interpreted.

Traits in Rust

That sounds like a good thing to me. Fewer people reinventing the wheel.

@@ThaJayyes!

what you're describing is pretty much what statically typing with type inference is! many statically typed languages have that. the difference is that, in a dynamically typed language, it would be perfectly fine to pass either an integer, a string, or a float, to a function, and expect it to work. in a statically typed language, even with inference, you wouldn't be allowed to place a string where an integer is supposed to be. for example, in the following Rust code (extremely statically typed): let a = 10; let b = "10"; let c = 10.5; no type annotations are required, since the compiler is smart enough to tell what the types are. If you then did something like this: let list = vec![a, b, c]; it would not compile, since it would see you're trying to create a list of mismatching types. it is so smart that you could even do this: let a = 10; let mut list = vec![]; list.push(a); list.push("5"); and it would not compile. despite you never actually saying that "list" is a list of integers, it was able to infer that based on the line where you push `a` to it. so adding a string to the list isn't allowed.

Type inference. Languages like ML and Haskell are strictly typed with minimal type annotation. The types are also parameterized so functions may be much more generic.

C# may have added syntax to declare dynamic types, but I’ve never seen anyone actually use them.

@@TehKarmalizer Haskell also has dynamic types, but no one uses them...

@@aoeu256 The "issue", so to speak, with Haskell's Dynamic, is that once you have it, you can't really do much with it apart from explicity try and convert it to another type, which gets tedious and defeats the point a bit, or code your entire codebase with Dynamics - which is still a bit painful. C#'s dynamic at least just lets you do what you want and then yells at you at runtime - also the ceremony needed for casting dynamic->string, for example, is much, much simpler.

Could you elaborate? How are we going to solve scaling monolithic software? Or are you referring to that microservices in the true sense are overkill and a bit bigger units are better?

​@@kc3vv I am not even sure monolithic software is the answer. It may be something completely different that we don't even know about. Anyway, microservices seem to be a workaround for today's limited technologies rather than a solution that adds value for the customers. Similar to dynamic typing.

This is an interesting take on developments in the programming language space. Microservices are indeed interesting based on the problem that they aim to solve which is probably more related to scalability. There are added benefits in that an app can be split up into different "independent" modules that are language agnostic. There are clear benefits to microservice architectures when done right, but I think that a lot of companies (especially startups) use microservices for the wrong reasons. For example if you build your server in nodejs, which is single threaded, and you want to scale it up, a microservice architecture will help since you can spawn multiple instances, but maybe nodejs was not the best choice in the first place. Also, if you are splitting your app into multiple microservices but stuff breaks if one of the microservices goes down, then this architecture is also probably not the right choice.

@@Voidstroyer I am not questioning the benefits of microservices from developers point of view. I am just saying that they don't add value for the users, as the users don't care about languages used. Scalability does indeed matter for the users but I don't see why the same horizontal scaling cannot be achieved by replicating a monolith.

@@aybgim3850 No I completely agree with you on that users wouldn't really care about what the architecture of an application looks like, as long as it does what it needs to do, and with acceptable performance. I am personally against microservices architecture because I think that some apps (for example in my current company) use microservices prematurely (or the application is split up into too many unnecessary isolated services). I would definitely prefer going monolithic first and only splitting into microservices whenever necessary.

That's kinda what it is. It's a superset of Javascript with added type checking.

The usage of static/strong type is often used interchangeably, but in theory no: * Dynamic/Gradual/Static is about the question "does the language assign a type to every variable/function/etc..." * Weak/Strong typing is how fussy the language is when these types end up not matching, at either compile or runtime These often align, but there are lots of exceptions, for example, JavaScript is very weakly typed as it will convert anything to anything else silently, but the equally dynamically typed Python is very strongly typed, requiring explicit conversions, while C is an example of a fairly weak statically typed language, where it is quite happy to silently convert a bunch of types.

Gradually typed is just what they call a dynamically-typed language that allows adding type annotations (and that then enforces static typing where those annotations are made). For instance, TypeScript. You can use it exactly like regular Javascript, but if you add an annotation saying a variable is a string, it will no longer let you assign any old type to that variable.

It's not necessarily true early 90s code had to run in machine code. Early versions of Microsoft's programs for Windows were written in C...however they were not compiled to machine code. They instead were compiled to pseudocode, that was then interpreted at runtime. Executing the programs ran the interpreter, and loaded the interpreted code. This is the secret for how Microsoft managed to get programs like Word, Excel, and Access to fit into the 1MB memory constraints on an 80286, while their competitors failed. Microsoft sacrificed some program speed for smaller memory constraints. The instructions of the pseudocode could be more powerful than the machine code instructions in a smaller amount of memory. The C compiler they used for this was not made publicly available. By the late 90s the memory constraints no longer mattered and Microsoft changed to compiling to native code.

@@grr986 Could you please elaborate more about that? As far as I know, 286 had protected mode already so it could easly go with >1mb. I'd love to see more sources about that, because I'm curious.

@@martinchya2546 My memory is a little fuzzy because it's been more than 30 years. The 80286 had a 1 MB memory constraint at least under Windows, and only 640K was usable by Windows. There was a protected mode on the 80286, but if I recall right, its limitations kept Windows from using it (see Protected Mode on Wikipedia). You could cheat a little and get an extra 64KB out of it with the segmented memory. There was a hack where you could access the first 64KB of the second MB (see High Memory Area in Wikipedia). It wasn't until Windows 3.0 running on a 386 or later that you really were able to get past the 1MB limit. I just looked at my Microsoft Access 1.0 box sitting on my shelf which shipped in late 1992...it required Windows 3.0, 386, 2MB memory, and I believe it still ran pseudocode at the point it shipped. It was certainly pseudocode for most of its development.

JSDoc goes with Typescript or mypy in his taxonomy (static type retrofit to a dynamic language). ActionScript and Dart were singled out as the only mainstream languages that *started* gradually typed.

JS survives through mob mentality not any actual advantage over other languages

It has much more to do with the native support of JSON in JS which makes this comparison kind of unfair.

Yeah, I pressed stop after the ceremony bit.

The java boilerplate seems to be more about the patterns chosen in this case. There is no reason that the answer class can't just look something like the json class.

The ceremony in enterprise Java is far, far higher than the ceremony in enterprise Javascript or Typescript. A lot of 90s era programmers conflated the ceremony of the major static languages of the day with static typing, and disliked static typing because of that. Modern mainstream static languages typically have much, much less ceremony than Java, which is something that he points out. If you watch the video, a decent part of his point is that when the options were Java and python, many people preferred python. When the options are Javascript and Typescript, many people opt for Typescript.

Python is a garbage programming language

@@zachb1706 lol ok? this is relevant how?

what about them?

@@encapsulatio indeed !

@@leyasep5919 no one uses Forth in anything other than small embedded projects, forth is also kind of useless for readability when others read your code since it encourages developing your own DSL for every project you write. As for lisp , why does Coalton exist if default Lisp is enough without static typing? You just gave a useless troll answer.

You have listed all the bad things :) Especially dictionaries are the worst. You have a method which accepts a dict, but that dict must have certain fields and you have no idea what are those fields. An exact well named class/object is much better.

In C#, a lot of the clutter has been made unnecessary eg auto-properties, Record over Class....

Your ide could hide static types maybe and auto inference them. Now that I think about it, you could show different properties of your program depending on different powered type systems like dependent types for behavior, effect types, and normal types.

It’s always a relief when the IDE infers a type :)

Rust has some of the best, most impressive, at times shocking type inference. 90% of your code won't need type annotations whatsoever. you can declare a variable with a very ambiguous type (for example let foo = None) and if at any point afterwards anything restricts its type, then it is inferred. it could be returning it from a function, passing is as an argument, or even adding it to a list of known (often inferred!) type.

Oh yes, I agree. I love lua for it's super readabillity for example. It contains almost no annotations, that is no the code itself.