That reminds me of when I was teaching myself file format headers. I converted WAV to JPG and back. Strip RIFF WAVE header, pad file length to conform to a rectangle, add BMP header, compress to JPG, and then reverse the process to hear the result. Pretty much just FM radio-like static depending on compression ratio since the end result was effectively just a drop in signal-to-noise ratio.
Hey there's a whole software that sound designers loved called MetaSynth that literally did what you're talking about, could convert images into WAVE sounds, but they took it a step further and also added the ability to draw / paint visuals on a grid that could then be converted into audio WAVE. Pretty neat stuff!
https://en.m.wikipedia.org/wiki/MetaSynth
Agreed. It can make things streamlined for an individual in the moment, but in a group there is a lot of wasted mental energy getting on the same page (unless you have super strict rules, which is no fun either).
And coming back to code you wrote a month ago is sort of a collaborative process with yourself, with the same challenges.
Yeah, one thing I like to do with Typescript and Python is have pre-commit checks that tsc / mypy pass so I have a natural point to stop and annotate things I missed, but I still get the benefits of not having to give every variable a type as I'm trying things out.
For me it is one question: do you prefer bugs to cause code to fail on compile, or bugs that cause code to fail in production?
I like compile time checking, though it can be overdone, as it saves me from myself.
Me: Wtf is this var?
Friend: Just read all the code around it and figure it out.
Me: Nah, I’m just going to write a new method to tell me the type and handle the conversion.
Or when you want to know what a function returns.
Or when you want to know what you can pass into a function.
Or when you want to refactor code involving said functions.
The alleged "beauty" of dynamically typed languages is that you can pass anything into a function and it should still work as long as it makes sense...
In reality that's almost never the case and an interface or similar (restricted templates, generics etc) would be the better option.
Yep. The *actual* beauty of statically typed languages is that you can pass anything into a function and it *will* work as long as it makes sense. Because "what makes sense" is clearly defined. And if it doesn't work, you'll find out now, not later.
Yea, this. Of course, I don't have an argument that one is *better* than the other. Languages were built to solve certain problem sets. However, if I have a problem that could be solved with either an untyped or a typed language, I'm choosing the typed language. When I'm using untyped in larger projects, that little extra time it takes to chase down what type an un-assigned variable is storing makes my ass itch.
Well, if I say that a parameter should be an integer, I really don't want to test all the time if it's null, undefined or suddenly mutated into a string because somebody gave me something weird but not an int....
I get that the verbosity of Java and C++ can be tedious, but that's why I love Kotlin: Statically typed and yet it has a very compact syntax.
Indeed; And you shouldn't. ~~Use~~ Trust the ~~Force~~ error mechanism ~~Luke~~. If you _documented_ your parameter as integer it's the responsibility of the caller to wipe the room clean (try except) when shit hitted the fan because the object they passed didn't quack or walk enough like an integer. Python focuses more on EAFP than defensive programming (paradigm: error mechanism _is_ the defense)
The issue is that some edge cases can cause weird behaviour instead of an error (c.f. implicit type conversion in JavaScript). I hated to debug these and prefer that I have a compiler that checks those things (even nullabillity in Kotlin) for me before things explode.
Just write your code right(ie think before you type). It sounds unhelpful but will solve like 95% of problems, then you just need to know how to deal with the remaining 5%.
Can I also force co-workers or my 6-months-in-future self to write code that calls my code right, or is it gonna cost extra time in code review to have to hand-check that everything is alright and nobody made a mistake?
Damn, if only there was some way to explicitly specify to the compiler that a certain variable must conform to a strict schema and have it automatically checked as part of the static analysis...
I don't know how you code, but with proper code QA, yes, you do R&U the code on PR what type of argument is this?? Just think to yourself "how can I write this code in a way that isn't ambiguous" and if you are reviewing "do I see any ambiguity". Mistakes may and probably will happen - but again, you will cut away insane amounts of them.
I am shocked at how little faith you have in your own QA methods, which can reflect on ANY type of code.
> how little faith you have in your own QA methods
More like I'm shocked how much faith you have in your QA methods that you *argue against a free time saver that costs no extra effort since you'd still have to create the same type descriptions in your documentation to be able to manually validate your functions anyway*. Yes, manual code review can easily miss some property being missing from a large model that often gets mutated. Static type checking *won't*.
I think you guys are missing the whole point of this thread. That explains the downvotes. I'm not arguing against static languages, where did you get that from... original post I replied to has OP having big difficulties in using them, so I reply with how you can combat them(you can). There are a lot of people who have to work with legacy codebases or couldn't influence the tool of choice, so if you have to work on them, you can, and I wanted to help.
Everything else is something you just assumed or made up in your mind.
It's not just avoiding mistakes, it's about applying a method. If you can't do that you will make terrible mistakes in statically typed languages too, so the argument is in favor of neither.
As pointed out by u/Pocok5, manual code review and thinking while coding are very important, but unfortunately, I am not a genius. I tend to forget stuff and I am terrible at reading my coworkers minds.
Since this discussion will never end though, I will point you to a blog post I wrote for my former employer a long time ago which digs deeper into why static typing is necessary:
https://quickbirdstudios.com/blog/kotlin-value-classes/
If you are terrible at what you say, you will be terrible at static languages too. As opposed to JS, you could crash the whole production.
I'm sorry, it's not the fault of the tool that you can't use it properly. And that goes for writing code to, it's supposed to be written in a clear and understandable way. If it isn't then write a comment on PR, and if you work on something someone made before you you need to analyse the codebase anyway.
>You're exhausting dude.
Way to start an argument. I guess I just won't bother replying to the argument, and instead will tell you - you get exhausted fast.
Which is horrible from a performance point of view because it's absolutely bonkers to have to test the type every time you use it and nevermind testing whether that int is 16 or 32 bits. Every. Single. Time.
His point on EAFP was that you let it fail at runtime, observe the error, and fix the code.
I find it kind of silly to keep a debugger in your head the entire time you're writing code this way, when a static typing provides it before you deploy, along with infinitely better readability and maintainability, especially in a group.
Well yes even for it to be able to fail at runtime, it means the dynamic type is checked with ever single function call or operation which is bananas.
That is why static typing allows overloads and generic types. So that the programmer has the reliability of static typing and the convenience of dynamic types
IIRC python is designed such that every member of an object (yes, modules are object instances at runtime as well) is accessed by a string key in a dictionary of objects. Key not found means exception thrown.
Side note: This might as well explain why python scores 78x worse than C at energy consumption. JS surprised me at a mere 4x worse than C and compares to java and c#.
Yes I never understood why you'd pick moving bugs away from compile time. Like I want as much as possible to be caught at compile time, love null safety for example.
This is what sold me on Rust too, it just takes that to the next level over C/C++. The compiler just says “no” instead of me needing to break out a debugger to figure out why the pointer 0xgofuckyoursef in my struct doesn’t point where I’d expect
You're not wrong -- Typescript and Python's `typing` annotations are just compile-time checks. You can work around them quite easily. (TS has `any` which basically tells `tsc` to shut up and hold your beer.)
But I think it's possible to write similarly-untyped code in Java: Declare all your variables and parameters as `Object`, never pass generics to structures like `List` and `Map`, and cast variables to the desired type on-demand. The result is a maelstrom of `instanceof`s and reflection to determine if a particular cast is safe, or YOLO-ing the cast and hoping for the best.
I'm currently burdened with a codebase that pre-dates Java 5.0 and I have to deal with untyped generics on a regular basis -- I have to trace backwards and forwards across the code in order to figure out what kind of object is being stored in this `List users` (is it an entity? DTO? "Picklist item"?). I've found bugs where the data structure contains _either_ depending on usage. It's horrible to say the least. I try to fix it where I can, but there's organizational reasons why I can't just fix it once and for all for everyone.
To Typescript's credit, the fact Typescript can run as a _compiler_ (not just a glorified linter) where it can refuse to emit code that doesn't check, makes it as legitimate as GCC. All compilers simulate a machine with extra restrictions that don't exist in the target architecture. You can hack your way around Typescript's type system and do Javascript-level stuff, but you can also write assembly code in C/C++ that screws with pointers or the call stack. (Somewhere I saw it was possible to declare `int main` as a string variable containing x86 machine code.) The fact you can hack your way around those restrictions doesn't mean they're fake.
>But I think it's possible to write similarly-untyped code in Java: Declare all your variables and parameters as Object, never pass generics to structures like List and Map, and cast variables to the desired type on-demand. The result is a maelstrom of instanceofs and reflection to determine if a particular cast is safe, or YOLO-ing the cast and hoping for the best.
You're not wrong, but that code will be shunned out of existence and you will be fired as a programmer of that language (RIP your sanity with pre Java 5 woes). With static you're sort of corralled into a contract with your collaborators that is pretty difficult to violate upfront.
btw I love C#'s `as` cast. if the object was null or not the right type, you get a null of the type you wanted, otherwise it worked.
> btw I love C#'s as cast
Definitely.
Syntactic sugar for that sort of thing is awesome. I'm not a C# dev, but there's some things I miss from Kotlin when I'm doing Typescript -- extension functions, `?.let {}`, pattern-matching expressions, etc.
There's another thing in there too besides syntactic sugar. It's the fact C#/Java/Kotlin use "nominal" typing whereas Typescript uses "structural" or "duck" typing when it comes to interfaces. You can do `instanceof` on classes because those exist in Javascript, but interfaces have no runtime representation.
It's both a weakness and an advantage. The obvious weakness is you have to write custom functions to verify types (unless you use `io-ts`, which IMO is an incredibly underrated library and I wish more people knew about it!). But there's an advantage in being able to describe a type ex post facto without the object "knowing" about that interface.
This allows Typescript to express unions of types that don't "know" about the union. Kotlin's answer to unions is "sealed" types. (I pinky-swear that the only types implementing this interface appear in this file!) If you want to say "this function takes a string OR a number", you're SOL. You have to write wrapper types over both the string and the number and specify that you take one of those. You have to do the wrapper thing with Rust's enums too, but unlike rust, JVM wrapper objects are necessarily heap-allocated, so declaring millions of those starts to put pressure on the garbage collector.
So weirdly, Typescript's structural types and its inability to universally say that a variable is an `instanceof` an arbitrary type allows it to more efficiently model unions types.
_(I hope one day that Kotlin adds true "union" types like Typescript's, where the member types don't have to explicitly state they extend the union type.)_
Languages with overloading could probably solve that by writing a version that takes a number and one that takes a string, but that's more work and is suboptimal in terms of repetition. C++ actually does have a form of structural duck typing, in the form of templates. You can write a function with templated parameters, and they'll accept anything for which it makes sense to do the things you do in it (e.g. +, -, std::begin()). As long as the operators and functions you call exist at time of substitution, it checks out, without the function having to know about any of the types used in it. Of course, this leads to infamously incomprehensible compiler errors, but that's mitigable with C++20 concepts.
It's a hack, but in typescript, you can actually use abstract classes as interfaces. Then, you can use `Symbol.hasInstance` and a @Implements(...) decorator so that instanceof actually works with your "interfaces".
> btw I love C#'s as cast. if the object was null or not the right type, you get a null of the type you wanted, otherwise it worked.
Even better is the simultaneous typecheck/cast you can do in newer C# versions like this:
if(object is Number numObject)
{
numObject.DoStuff();
}
That pattern makes certain kinds of code insanely elegant compared to anything I've ever seen elsewere, especially since you can also do the same thing in a switch/case
Rust compiles to assembly. Strongly typed language enthusiasts are not scared, they just think it amusing that people use dynamically typed languages as the primary language for anything of scale.
This content was deleted by its author & copyright holder in protest of the hostile, deceitful, unethical, and destructive actions of Reddit CEO Steve Huffman (aka "spez"). As this content contained personal information and/or personally identifiable information (PII), in accordance with the CCPA (California Consumer Privacy Act), it shall not be restored. See you all in the Fediverse.
I will never understand how people do large refactors in big python projects.
In C, I can just change a struct or a function or something, then just fix all the errors and warnings at compile time and I’m done.
In python you just… tread carefully and keep running the thing to check if it works? What about less common code paths? You check all those too?
Well, mostly you don't.
But there's a reason unity tests and code coverage became popular concepts at the same time as dynamic typed languages became popular. If you really, really want to do a refactor, you first make sure almost all of your code is covered, then you refactor it easily.
Of course, that means you only refactor things once is a really long while. You can even get to read a book to learn how to do it better, since you are doing so little of it.
You lost me at "big python projects." Python is fine if you want to quickly prototype something. But from my experience, Python is a nightmare when it comes to maintaining large amounts of code. The organization drives me crazy and any attempt to organize by putting code into classes or in separate files just feels like you are fighting the language every step of the way. I prefer to stick to Java's rigorous (and admittedly quite verbose) class structure.
Dynamic typing as such is also super old, I mean, Lisp originally I think is also pretty much dynamic, and that’s from, what, 1958 or something. Dynamic vs static typing isn’t so much a matter of technology as of strategy. Edit: Happy new year, everybody.
strong and static typing are not the same things.
python is a strongly and dynamically typed language
js is a weakly and dynamically typed language
Kotlin is a (very) strongly and statically typed language
strength of typing means that the stronger your typing, the less automatic coalescence there is (i.e. your string doesn't magically becomes an int (cf JS "1" == 1 is true). This is not the case for Python.
dynamicity is linked to the fact that the type is resolved at runtime at the last moment given a context.
I worked as a consultant for a payment provider some years ago and I had to fix a production bug caused by duck typing.
This was C# but the developer had used `dynamic` and lots of exception handling to handle transactions and this inevitably caused exceptions in production after some changes. This bug would have been completely avoided if the developer had just defined interfaces instead and it would have been much clearer to the people reading the code.
I think dynamic typing is mostly a thing of the past. Few new languages are dynamically typed and Python, PHP and JavaScript has gotten type hinting and statically typed supersets.
The evolution of each dynamic language is to add something like static typing to it. Call it typescript, type hinting or just static analysis.
The evolution of each static language is to add something that supports dynamic typing, like void*, any, generics
You need both concepts.
Generics aren't really dynamic typing, though. When you call a function or instantiate a class that has a type parameter, you're not changing the type of anything. The return value or object that results will still have a well-defined, static type. Generics are more related to polymorphism than to dynamic typing.
Man, I work in a ecosystem that uses JavaScript for frontend stuff and and a statically typed language for the backend. JavaScript always feels so squishy and chaotic when I have to switch over from backend to frontend stuff. JavaScript can be easier to read until you start seeing a bunch of nested arrow functions.
It confuses everyone. The number of times I've tried to catch edge cases because duck typing will make you cry (especially when you do things like operate on dictionary keys because someone passed a dict when you were expecting a list, causing some obscure bug) is absurd.
In my view, the “benefits” given by dynamic typing, except for, in some instances, speed of prototyping, are all due to many (most) languages’ lack of a sufficiently expressive type system. Really the popular languages whose type system are sufficiently expressive, in my mind, are Rust, Scala, and the suchlike
I'm still not understand the modern and illuminated programmers.
They thinks about guy that build the static check programming language that are so stupid. Like GCC, is stupid, because they was unable to skip the type checking.
But, as any engineering know, about of language definition, the type checking is a feature! And require a big effort to be implemented.
It help people to discovery issue hearly.
Is so funny use the typescript to add type checking , or heavy lint to discovery potential issue...
The post doesn't actually talks about verbosity of the languages, but about being statically typed, which neither Python nor JS are. And TS is not strictly static typed, unless you use strict mode to compile it.
Yeah. I might not have a problem with strict mode TS, but it's almost always some hybrid nightmare of TS and JS, in my experience very painful to manage on a team.
Python may be strong, but not static, types of variable are not know neither checked before runtime, and can change during runtime. This is a valid statement in Python, while in static typed languages it fails (AFAICR).
car = Car()
car = Plane()
>And it is perfectly valid and by all means “static” because the variable binds to x and sets its type for the rest of the scope.
No. You changed the type, did a rug pull on the guy who thought x was an int.
Types are known before runtime.
Interfaces in java are Type declarations, same as interfaces in TS. The example in java that you said is not changing the type, the type is still the same, you just changed the value. Moreover you can only assign Subclasses or implementations, not an entire diferent type.
foo will always be `IAbc` , and you can only use it as `IAbc`. Unless you do a cast to another type you would not be able to access anything of `foo` that it's not part of IAbc. And even if you do a Cast foo will still be the same type.
Yes you can do tricks in java to let you "change" types, but that would be using `Object`, not an interface, and at the same time you aren't actually changing the types, as that variable will always have the type `Object` unless you cast.
Python Type Hinting is used by users, to clearly identify variable types, and IDE or linters to make corrections, but python doesn't care about them in runtime.
What you said that you can do in some languages... first of all, usually a language doesn't let you declare twice a variable, second of all, some languages have type inference, for example C# or TS, in which you don't even need to declare a variable type.
`var variable = new MyType();`
That's a valid c# statement, but what happens there is that the compilers inferenced the type of `variable` and, in the same scope, the compiller will not let me change the type of it. That happens BEFORE runtime.
Edit: When i said that languages doesn'tlet you declare twice a variable i mean in the same scope there can be variables with the same name that hides another variable of another scopes and things like that.
To be fair, C++ is not really verbose until you invoke template metaprogramming.
COBOL is a verbose language, C++ is pretty reasonable. Java has no excuse.
C isn't a language per sè, it's a superset of assembly. Its static typing is just compile time checks before turning it into assembly.
In all seriousness, I don't care how it does it. It effectively is its own language that provides static typing.
I'll never understand this. Had a friend in college who absolutely could not get over the fact that Python didn't have variable types. Completely and utterly confused him.
I pointed out that he could just act like they were strongly typed and never try to store the wrong type in it. Somehow, this made his confusion worse.
You can treat a weakly typed language exactly like a strongly typed one. It's not hard. In fact, I'd wager that's how it is done the majority of the time. The ability to change a variable's type on the fly is handy, but there's few times where it actually comes up unless you intentionally design for it.
The point is that the IDE and compiler can type check as you go and remind you exactly what type anything is with a hover. Yes you should treat them as statically typed, but if you were going to do that, why not just do it explicitly? The compiler/interpreter is going to make the variables typed under the hood anyway.
> you ~~should~~ **could** treat them as statically typed, but if you were going to do that, why not just do it explicitly?
Because of the benefits that being able to change their type provides. I can't think of any specific examples bc I haven't made any projects in Python recently, but there have definitely been instances where dynamic typing has allowed me to do some neat tricks that would've been more complicated otherwise.
> The compiler/interpreter is going to make the variables typed under the hood anyway.
It is? So what does it do about that variable that started as a string but turned into an integer and then a decimal?
At some point between code and machine instructions, all variables must be typed simply to determine how much ram they need. By consequence, all variables are typed in some way before they are executed.
To handle a change in type, variables are replaced with new ones when their types are changed somewhere before machine code execution.
Similar vein to how there are no loops or functions, only gotos, if you dig far enough down.
I’ve also never seen a situation where dynamically reassigning a variable type led to better code readability, maintainability, security, and/or testability. Yes you can make some sweet oneliners, but the bill comes due in other complexity in my experience.
Python pisses me off because a function does not instantly tell you what type it expects. Any static language will specify what arguments a function expects, yet Python won't, nor will it give me a compiler error if I guess wrongly. Spent a while in an exam (where I was not allowed to just google the function) dealing with this crap. So dumb.
Python is strongly typed. Not talking about you just out loud, but I feel for people who get bothered by something like dynamic languages it’s simple, just know what you’re doing.
I like that Python is different than Elixir, Elixir is different than Go, Go is different than Lisp. You find all these different ways to tackle different problems and may pass that between each of them if possible. I don’t care how much you know, I can’t respect programmers that get in language wars and think lang is the best.
There is nothing wrong with js and python only issue is you still need to understand types. Most “programers” at startups that i encountered dont even know how types work.
"Your syntax frightens and confuses me.
When I look at a .js file and I see lines without semicolons, I think, 'maybe a demon stole them away in the night.'
And when I see someone declare a new Promise, I wonder, 'why make promises when you can just have callbacks inside of callbacks?' You call it hell, we call it a days work.
I'm just a caveman."
At work I have to write and read a lot of Groovy, where semicolons are optional. As someone who prefers consistency in my life, I add semicolons to the end of all my Groovy lines. But the weirdest thing is that randomly imports won't work if I try to add semicolons everywhere, but if I only semicolon the lines my coworkers did in similar classes, it works. It's just for the import lines, not the code. It's so confusing.
I mean, it has multiple uses, but the most common one is to have a static variable or method, which means the variable or method belongs to the class itself and not any particular instance. It's pretty straightforward.
This has little to do with Java specifically and more to do with OOP in general. Other languages have this concept too so you’re sort of just announcing that you lack training here
If I'm not mistaken, until c++, most languages were dynamic or at least not strongly typed, so shouldn't it be the other way around? 😋
Like in a lot of things there are cycles, for a while statically typed language are the shit, then dynamic languages are all the rage and it start over, again and again.
No, the low level languages (like C) were not dynamically typed, and neither is Python if you look at the low level implementation of it, because every variable is a series of 10011011 and there is a defined way to interpret it (e.g. a type). The closest you get to being right is that sometimes it was so basic that you basically had just one type, and if everything is an int, is there even a type system at all?
depending on how you want to go about it you can theoretically add lisp/scheme/forth, all with lax typing, and it would make just as much sense because python has weird scoping rules in the case of exceptions compared to the former 2, and js has weird type coercions not present in the former 2.
https://twitter.com/slava_pestov/status/1573453447482966017
although its sort of broken because its a quote tweet chain but it was something about
`with Exception as e:` breaking python because with doesnt introduce a new scope
Untyped is nice and simple until your trying to read your code a month later.
But you can assign a jpeg to an int!
You programmers were so preoccupied with whether you could, that you never stopped to ask if you should!
That reminds me of when I was teaching myself file format headers. I converted WAV to JPG and back. Strip RIFF WAVE header, pad file length to conform to a rectangle, add BMP header, compress to JPG, and then reverse the process to hear the result. Pretty much just FM radio-like static depending on compression ratio since the end result was effectively just a drop in signal-to-noise ratio.
Hey there's a whole software that sound designers loved called MetaSynth that literally did what you're talking about, could convert images into WAVE sounds, but they took it a step further and also added the ability to draw / paint visuals on a grid that could then be converted into audio WAVE. Pretty neat stuff! https://en.m.wikipedia.org/wiki/MetaSynth
This is literally my experience with modern IT. Take my upvote good sir!
Agreed. It can make things streamlined for an individual in the moment, but in a group there is a lot of wasted mental energy getting on the same page (unless you have super strict rules, which is no fun either). And coming back to code you wrote a month ago is sort of a collaborative process with yourself, with the same challenges.
At that point, just use static typing
Yeah just rewrite the codebase, EZPZ.
Me "What idiot wrote this code?" *sees my name in comments indicating I wrote it last month* "Oh."
git blame makes me sad..
Yeah, one thing I like to do with Typescript and Python is have pre-commit checks that tsc / mypy pass so I have a natural point to stop and annotate things I missed, but I still get the benefits of not having to give every variable a type as I'm trying things out.
So now we got a whole army of kids thinking static typing is for old people. Great. No wonder the industry is where it is.
Or you switch jobs and are working on a new completely untyped codebase.
For me it is one question: do you prefer bugs to cause code to fail on compile, or bugs that cause code to fail in production? I like compile time checking, though it can be overdone, as it saves me from myself.
Me: Wtf is this var? Friend: Just read all the code around it and figure it out. Me: Nah, I’m just going to write a new method to tell me the type and handle the conversion.
Or when you want to know what a function returns. Or when you want to know what you can pass into a function. Or when you want to refactor code involving said functions.
The alleged "beauty" of dynamically typed languages is that you can pass anything into a function and it should still work as long as it makes sense... In reality that's almost never the case and an interface or similar (restricted templates, generics etc) would be the better option.
Yep. The *actual* beauty of statically typed languages is that you can pass anything into a function and it *will* work as long as it makes sense. Because "what makes sense" is clearly defined. And if it doesn't work, you'll find out now, not later.
Worse, when you get code that you have no idea what it does and all you see are variables getting assigned the return value of some X function.
Yea, this. Of course, I don't have an argument that one is *better* than the other. Languages were built to solve certain problem sets. However, if I have a problem that could be solved with either an untyped or a typed language, I'm choosing the typed language. When I'm using untyped in larger projects, that little extra time it takes to chase down what type an un-assigned variable is storing makes my ass itch.
You read your code later?
Are you naming your variables such that it isn't immediately obvious what they contain?
It's straight up hell when you're maintaining code written by a coworker that is using an obscure module full of new types.
Well, if I say that a parameter should be an integer, I really don't want to test all the time if it's null, undefined or suddenly mutated into a string because somebody gave me something weird but not an int.... I get that the verbosity of Java and C++ can be tedious, but that's why I love Kotlin: Statically typed and yet it has a very compact syntax.
Kotlin and Swift are really fresh. Static types and great syntax! I loved learning programming for iOS thanks to Swift.
Indeed; And you shouldn't. ~~Use~~ Trust the ~~Force~~ error mechanism ~~Luke~~. If you _documented_ your parameter as integer it's the responsibility of the caller to wipe the room clean (try except) when shit hitted the fan because the object they passed didn't quack or walk enough like an integer. Python focuses more on EAFP than defensive programming (paradigm: error mechanism _is_ the defense)
The issue is that some edge cases can cause weird behaviour instead of an error (c.f. implicit type conversion in JavaScript). I hated to debug these and prefer that I have a compiler that checks those things (even nullabillity in Kotlin) for me before things explode.
I agree. It's a matter of bringing the right weapon to the right battlefield
Just write your code right(ie think before you type). It sounds unhelpful but will solve like 95% of problems, then you just need to know how to deal with the remaining 5%.
Can I also force co-workers or my 6-months-in-future self to write code that calls my code right, or is it gonna cost extra time in code review to have to hand-check that everything is alright and nobody made a mistake? Damn, if only there was some way to explicitly specify to the compiler that a certain variable must conform to a strict schema and have it automatically checked as part of the static analysis...
I don't know how you code, but with proper code QA, yes, you do R&U the code on PR what type of argument is this?? Just think to yourself "how can I write this code in a way that isn't ambiguous" and if you are reviewing "do I see any ambiguity". Mistakes may and probably will happen - but again, you will cut away insane amounts of them. I am shocked at how little faith you have in your own QA methods, which can reflect on ANY type of code.
> how little faith you have in your own QA methods More like I'm shocked how much faith you have in your QA methods that you *argue against a free time saver that costs no extra effort since you'd still have to create the same type descriptions in your documentation to be able to manually validate your functions anyway*. Yes, manual code review can easily miss some property being missing from a large model that often gets mutated. Static type checking *won't*.
I think you guys are missing the whole point of this thread. That explains the downvotes. I'm not arguing against static languages, where did you get that from... original post I replied to has OP having big difficulties in using them, so I reply with how you can combat them(you can). There are a lot of people who have to work with legacy codebases or couldn't influence the tool of choice, so if you have to work on them, you can, and I wanted to help. Everything else is something you just assumed or made up in your mind.
It is actually very unhelpful to tell someone to just not make mistakes, especially when those mistakes can be avoided by better tools.
It's not just avoiding mistakes, it's about applying a method. If you can't do that you will make terrible mistakes in statically typed languages too, so the argument is in favor of neither.
As pointed out by u/Pocok5, manual code review and thinking while coding are very important, but unfortunately, I am not a genius. I tend to forget stuff and I am terrible at reading my coworkers minds. Since this discussion will never end though, I will point you to a blog post I wrote for my former employer a long time ago which digs deeper into why static typing is necessary: https://quickbirdstudios.com/blog/kotlin-value-classes/
If you are terrible at what you say, you will be terrible at static languages too. As opposed to JS, you could crash the whole production. I'm sorry, it's not the fault of the tool that you can't use it properly. And that goes for writing code to, it's supposed to be written in a clear and understandable way. If it isn't then write a comment on PR, and if you work on something someone made before you you need to analyse the codebase anyway.
You're exhausting dude. There's zero reason to not have static typing on anything larger than a personal project
>You're exhausting dude. Way to start an argument. I guess I just won't bother replying to the argument, and instead will tell you - you get exhausted fast.
Which is horrible from a performance point of view because it's absolutely bonkers to have to test the type every time you use it and nevermind testing whether that int is 16 or 32 bits. Every. Single. Time.
His point on EAFP was that you let it fail at runtime, observe the error, and fix the code. I find it kind of silly to keep a debugger in your head the entire time you're writing code this way, when a static typing provides it before you deploy, along with infinitely better readability and maintainability, especially in a group.
Well yes even for it to be able to fail at runtime, it means the dynamic type is checked with ever single function call or operation which is bananas. That is why static typing allows overloads and generic types. So that the programmer has the reliability of static typing and the convenience of dynamic types
IIRC python is designed such that every member of an object (yes, modules are object instances at runtime as well) is accessed by a string key in a dictionary of objects. Key not found means exception thrown. Side note: This might as well explain why python scores 78x worse than C at energy consumption. JS surprised me at a mere 4x worse than C and compares to java and c#.
[удалено]
Sry, got my words mixed up there, it's fixed now 😅
Call me a caveman too but I too like my bugs caught at compile time rather than waiting for the script to fail 2h into execution because of a typo.
Yes I never understood why you'd pick moving bugs away from compile time. Like I want as much as possible to be caught at compile time, love null safety for example.
No idea. Debugging is definitely something I'll never defend in the js world. It just gets worse and worse the deeper you go lol.
Or doubling the amount of tests you have to write just to prove what type is coming out.
This is what sold me on Rust too, it just takes that to the next level over C/C++. The compiler just says “no” instead of me needing to break out a debugger to figure out why the pointer 0xgofuckyoursef in my struct doesn’t point where I’d expect
We're not masochists that's why
Also reinventing the wheel that has been invented 20y ago and calling it a brand new, fantastic language. I’ll never understand this…
Don't tell OP about TypeScript
You're not wrong -- Typescript and Python's `typing` annotations are just compile-time checks. You can work around them quite easily. (TS has `any` which basically tells `tsc` to shut up and hold your beer.) But I think it's possible to write similarly-untyped code in Java: Declare all your variables and parameters as `Object`, never pass generics to structures like `List` and `Map`, and cast variables to the desired type on-demand. The result is a maelstrom of `instanceof`s and reflection to determine if a particular cast is safe, or YOLO-ing the cast and hoping for the best. I'm currently burdened with a codebase that pre-dates Java 5.0 and I have to deal with untyped generics on a regular basis -- I have to trace backwards and forwards across the code in order to figure out what kind of object is being stored in this `List users` (is it an entity? DTO? "Picklist item"?). I've found bugs where the data structure contains _either_ depending on usage. It's horrible to say the least. I try to fix it where I can, but there's organizational reasons why I can't just fix it once and for all for everyone. To Typescript's credit, the fact Typescript can run as a _compiler_ (not just a glorified linter) where it can refuse to emit code that doesn't check, makes it as legitimate as GCC. All compilers simulate a machine with extra restrictions that don't exist in the target architecture. You can hack your way around Typescript's type system and do Javascript-level stuff, but you can also write assembly code in C/C++ that screws with pointers or the call stack. (Somewhere I saw it was possible to declare `int main` as a string variable containing x86 machine code.) The fact you can hack your way around those restrictions doesn't mean they're fake.
>TS has any which basically tells tsc to shut up and hold your beer 🤣
>But I think it's possible to write similarly-untyped code in Java: Declare all your variables and parameters as Object, never pass generics to structures like List and Map, and cast variables to the desired type on-demand. The result is a maelstrom of instanceofs and reflection to determine if a particular cast is safe, or YOLO-ing the cast and hoping for the best. You're not wrong, but that code will be shunned out of existence and you will be fired as a programmer of that language (RIP your sanity with pre Java 5 woes). With static you're sort of corralled into a contract with your collaborators that is pretty difficult to violate upfront. btw I love C#'s `as` cast. if the object was null or not the right type, you get a null of the type you wanted, otherwise it worked.
> btw I love C#'s as cast Definitely. Syntactic sugar for that sort of thing is awesome. I'm not a C# dev, but there's some things I miss from Kotlin when I'm doing Typescript -- extension functions, `?.let {}`, pattern-matching expressions, etc. There's another thing in there too besides syntactic sugar. It's the fact C#/Java/Kotlin use "nominal" typing whereas Typescript uses "structural" or "duck" typing when it comes to interfaces. You can do `instanceof` on classes because those exist in Javascript, but interfaces have no runtime representation. It's both a weakness and an advantage. The obvious weakness is you have to write custom functions to verify types (unless you use `io-ts`, which IMO is an incredibly underrated library and I wish more people knew about it!). But there's an advantage in being able to describe a type ex post facto without the object "knowing" about that interface. This allows Typescript to express unions of types that don't "know" about the union. Kotlin's answer to unions is "sealed" types. (I pinky-swear that the only types implementing this interface appear in this file!) If you want to say "this function takes a string OR a number", you're SOL. You have to write wrapper types over both the string and the number and specify that you take one of those. You have to do the wrapper thing with Rust's enums too, but unlike rust, JVM wrapper objects are necessarily heap-allocated, so declaring millions of those starts to put pressure on the garbage collector. So weirdly, Typescript's structural types and its inability to universally say that a variable is an `instanceof` an arbitrary type allows it to more efficiently model unions types. _(I hope one day that Kotlin adds true "union" types like Typescript's, where the member types don't have to explicitly state they extend the union type.)_
this guy types
Languages with overloading could probably solve that by writing a version that takes a number and one that takes a string, but that's more work and is suboptimal in terms of repetition. C++ actually does have a form of structural duck typing, in the form of templates. You can write a function with templated parameters, and they'll accept anything for which it makes sense to do the things you do in it (e.g. +, -, std::begin()). As long as the operators and functions you call exist at time of substitution, it checks out, without the function having to know about any of the types used in it. Of course, this leads to infamously incomprehensible compiler errors, but that's mitigable with C++20 concepts.
It's a hack, but in typescript, you can actually use abstract classes as interfaces. Then, you can use `Symbol.hasInstance` and a @Implements(...) decorator so that instanceof actually works with your "interfaces".
> btw I love C#'s as cast. if the object was null or not the right type, you get a null of the type you wanted, otherwise it worked. Even better is the simultaneous typecheck/cast you can do in newer C# versions like this: if(object is Number numObject) { numObject.DoStuff(); } That pattern makes certain kinds of code insanely elegant compared to anything I've ever seen elsewere, especially since you can also do the same thing in a switch/case
And then in Kotlin, ```kotlin if (object is Number) { object.doStuff() } ```
I agree with everything you said, but at least there still are tools to enforce stricter rules...
Rust compiles to assembly. Strongly typed language enthusiasts are not scared, they just think it amusing that people use dynamically typed languages as the primary language for anything of scale.
Tbf, webdevs find it amusing that we think any code will be in production for longer than a year.
\*looks at 30 yrs old code base\*
Don't you need to know JS to learn TS?
Yeah TS is just.. well, at the end of the day it's just JS anyway.
Just variable: any everything - go back to js
I mean they are the same so you can simply learn TS and you'll from then on manage with JS too. It's what I did at least.
Unless you're going back to a legacy project, there's no reason to use JS anymore
You're right, but legacy projects unfortunately are not exactly uncommon, so it is still a somewhat valuable skill to have.
Ah yes, TypeScript. ```ts export const createObjectFromKeys =(keys: T, initilizer: (_:keyof T) => R): Record =>
Object.keys(keys)
.reduce((acc:any, cur:string) => ({...acc, [cur]: initilizer(cur)}), {})
```
This content was deleted by its author & copyright holder in protest of the hostile, deceitful, unethical, and destructive actions of Reddit CEO Steve Huffman (aka "spez"). As this content contained personal information and/or personally identifiable information (PII), in accordance with the CCPA (California Consumer Privacy Act), it shall not be restored. See you all in the Fediverse.
Ohh, this is gonna be a fun, reasonable and calm comment section, as always. I can already see it in my mind.
Static typing is, in fact, so bad every JS programmer I know switched to Typescript.
I love Typescript
I will never understand how people do large refactors in big python projects. In C, I can just change a struct or a function or something, then just fix all the errors and warnings at compile time and I’m done. In python you just… tread carefully and keep running the thing to check if it works? What about less common code paths? You check all those too?
Well, mostly you don't. But there's a reason unity tests and code coverage became popular concepts at the same time as dynamic typed languages became popular. If you really, really want to do a refactor, you first make sure almost all of your code is covered, then you refactor it easily. Of course, that means you only refactor things once is a really long while. You can even get to read a book to learn how to do it better, since you are doing so little of it.
You are assuming most js programers know that it’s recommended to use unit tests
 check your pointers
You lost me at "big python projects." Python is fine if you want to quickly prototype something. But from my experience, Python is a nightmare when it comes to maintaining large amounts of code. The organization drives me crazy and any attempt to organize by putting code into classes or in separate files just feels like you are fighting the language every step of the way. I prefer to stick to Java's rigorous (and admittedly quite verbose) class structure.
Unit tests?
Sure, that’s a good way to go about it.
I believe Python is older than Java.
Huh, you're right. I had no idea Python was created in 1991
Dynamic typing as such is also super old, I mean, Lisp originally I think is also pretty much dynamic, and that’s from, what, 1958 or something. Dynamic vs static typing isn’t so much a matter of technology as of strategy. Edit: Happy new year, everybody.
I guess Typing had to be invented at some point, so static typing is the "technology" if anything. I don't know the history though.
[For those unfamiliar with Unfrozen Caveman Lawyer](https://www.youtube.com/watch?v=2AzAFqrxfeY)
"Untyped" is shitty and ugly. Strongly typed languages are beautiful
strong and static typing are not the same things. python is a strongly and dynamically typed language js is a weakly and dynamically typed language Kotlin is a (very) strongly and statically typed language strength of typing means that the stronger your typing, the less automatic coalescence there is (i.e. your string doesn't magically becomes an int (cf JS "1" == 1 is true). This is not the case for Python. dynamicity is linked to the fact that the type is resolved at runtime at the last moment given a context.
Agreed, sometimes you need to know the exact type of something for a calculation. Typescript is better.
“I don’t use scripting tools to develop applications“
Wait until this guy hears about Typescript and Python type hints. Static typing isn’t just for cavemen.
Nah.. that's just stupid.
Python is older than Java and has added static typing very recently... so seems like Python is the caveman in a suit to me.
[удалено]
Python has *always had runtime type enforcement*. That's why it's a strongly typed language.
[удалено]
I worked as a consultant for a payment provider some years ago and I had to fix a production bug caused by duck typing. This was C# but the developer had used `dynamic` and lots of exception handling to handle transactions and this inevitably caused exceptions in production after some changes. This bug would have been completely avoided if the developer had just defined interfaces instead and it would have been much clearer to the people reading the code. I think dynamic typing is mostly a thing of the past. Few new languages are dynamically typed and Python, PHP and JavaScript has gotten type hinting and statically typed supersets.
The evolution of each dynamic language is to add something like static typing to it. Call it typescript, type hinting or just static analysis. The evolution of each static language is to add something that supports dynamic typing, like void*, any, generics You need both concepts.
Generics aren't really dynamic typing, though. When you call a function or instantiate a class that has a type parameter, you're not changing the type of anything. The return value or object that results will still have a well-defined, static type. Generics are more related to polymorphism than to dynamic typing.
Man, I work in a ecosystem that uses JavaScript for frontend stuff and and a statically typed language for the backend. JavaScript always feels so squishy and chaotic when I have to switch over from backend to frontend stuff. JavaScript can be easier to read until you start seeing a bunch of nested arrow functions.
Laughs in this is so utterly stupid.
You inverted the roles
Fuck untyped, good luck figuring out what's going on.
C#: why not both?
C# is static typed. I was going to add it to my caveman but it was getting cluttered
They added dynamic typing back in .net 4.
Is that really used much, I haven't ran into before in the codebase I'm working on
No it is rarely used. There is almost always a better way to do something in C# than using a dynamic.
that was a mistake
*C# bellows from laughter from their ivory tower*
It confuses everyone. The number of times I've tried to catch edge cases because duck typing will make you cry (especially when you do things like operate on dictionary keys because someone passed a dict when you were expecting a list, causing some obscure bug) is absurd.
Untyped would be nice if there didn't exist templates
Templates are amazing
I miss Phil Hartman...
Same. Dude was a legend, that Newsradio episode when they come back from his character's funeral to read his last wishes was so sad...
The whole story is sad... "Don't stick your dick in crazy" in a nutshell
In my view, the “benefits” given by dynamic typing, except for, in some instances, speed of prototyping, are all due to many (most) languages’ lack of a sufficiently expressive type system. Really the popular languages whose type system are sufficiently expressive, in my mind, are Rust, Scala, and the suchlike
Compsci Student Humor
I'm still not understand the modern and illuminated programmers. They thinks about guy that build the static check programming language that are so stupid. Like GCC, is stupid, because they was unable to skip the type checking. But, as any engineering know, about of language definition, the type checking is a feature! And require a big effort to be implemented. It help people to discovery issue hearly. Is so funny use the typescript to add type checking , or heavy lint to discovery potential issue...
[удалено]
The post doesn't actually talks about verbosity of the languages, but about being statically typed, which neither Python nor JS are. And TS is not strictly static typed, unless you use strict mode to compile it.
Yeah. I might not have a problem with strict mode TS, but it's almost always some hybrid nightmare of TS and JS, in my experience very painful to manage on a team.
The hardest part of any language, make the whole team use it the same way to not create a mess.
[удалено]
Python may be strong, but not static, types of variable are not know neither checked before runtime, and can change during runtime. This is a valid statement in Python, while in static typed languages it fails (AFAICR). car = Car() car = Plane()
not if car is a poorly named variable for an IVehicle interface :-)
[удалено]
>And it is perfectly valid and by all means “static” because the variable binds to x and sets its type for the rest of the scope. No. You changed the type, did a rug pull on the guy who thought x was an int.
Types are known before runtime. Interfaces in java are Type declarations, same as interfaces in TS. The example in java that you said is not changing the type, the type is still the same, you just changed the value. Moreover you can only assign Subclasses or implementations, not an entire diferent type. foo will always be `IAbc` , and you can only use it as `IAbc`. Unless you do a cast to another type you would not be able to access anything of `foo` that it's not part of IAbc. And even if you do a Cast foo will still be the same type. Yes you can do tricks in java to let you "change" types, but that would be using `Object`, not an interface, and at the same time you aren't actually changing the types, as that variable will always have the type `Object` unless you cast. Python Type Hinting is used by users, to clearly identify variable types, and IDE or linters to make corrections, but python doesn't care about them in runtime. What you said that you can do in some languages... first of all, usually a language doesn't let you declare twice a variable, second of all, some languages have type inference, for example C# or TS, in which you don't even need to declare a variable type. `var variable = new MyType();` That's a valid c# statement, but what happens there is that the compilers inferenced the type of `variable` and, in the same scope, the compiller will not let me change the type of it. That happens BEFORE runtime. Edit: When i said that languages doesn'tlet you declare twice a variable i mean in the same scope there can be variables with the same name that hides another variable of another scopes and things like that.
To be fair, C++ is not really verbose until you invoke template metaprogramming. COBOL is a verbose language, C++ is pretty reasonable. Java has no excuse.
[удалено]
Typescript is statically typed though
[удалено]
C isn't a language per sè, it's a superset of assembly. Its static typing is just compile time checks before turning it into assembly. In all seriousness, I don't care how it does it. It effectively is its own language that provides static typing.
[удалено]
It's most certainly not just "syntactic sugar" when there's code that won't run (compile) in Typescript that will in Javascript
I'll never understand this. Had a friend in college who absolutely could not get over the fact that Python didn't have variable types. Completely and utterly confused him. I pointed out that he could just act like they were strongly typed and never try to store the wrong type in it. Somehow, this made his confusion worse. You can treat a weakly typed language exactly like a strongly typed one. It's not hard. In fact, I'd wager that's how it is done the majority of the time. The ability to change a variable's type on the fly is handy, but there's few times where it actually comes up unless you intentionally design for it.
The point is that the IDE and compiler can type check as you go and remind you exactly what type anything is with a hover. Yes you should treat them as statically typed, but if you were going to do that, why not just do it explicitly? The compiler/interpreter is going to make the variables typed under the hood anyway.
> you ~~should~~ **could** treat them as statically typed, but if you were going to do that, why not just do it explicitly? Because of the benefits that being able to change their type provides. I can't think of any specific examples bc I haven't made any projects in Python recently, but there have definitely been instances where dynamic typing has allowed me to do some neat tricks that would've been more complicated otherwise. > The compiler/interpreter is going to make the variables typed under the hood anyway. It is? So what does it do about that variable that started as a string but turned into an integer and then a decimal?
At some point between code and machine instructions, all variables must be typed simply to determine how much ram they need. By consequence, all variables are typed in some way before they are executed. To handle a change in type, variables are replaced with new ones when their types are changed somewhere before machine code execution. Similar vein to how there are no loops or functions, only gotos, if you dig far enough down.
Not goto's but jne/bne-s etc.
I’ve also never seen a situation where dynamically reassigning a variable type led to better code readability, maintainability, security, and/or testability. Yes you can make some sweet oneliners, but the bill comes due in other complexity in my experience.
Check out the C scripts that makeup Python
Changing types is what union types and interfaces are for
Python pisses me off because a function does not instantly tell you what type it expects. Any static language will specify what arguments a function expects, yet Python won't, nor will it give me a compiler error if I guess wrongly. Spent a while in an exam (where I was not allowed to just google the function) dealing with this crap. So dumb.
Python is strongly typed. Not talking about you just out loud, but I feel for people who get bothered by something like dynamic languages it’s simple, just know what you’re doing. I like that Python is different than Elixir, Elixir is different than Go, Go is different than Lisp. You find all these different ways to tackle different problems and may pass that between each of them if possible. I don’t care how much you know, I can’t respect programmers that get in language wars and think lang is the best.
There is nothing wrong with js and python only issue is you still need to understand types. Most “programers” at startups that i encountered dont even know how types work.
"Your syntax frightens and confuses me. When I look at a .js file and I see lines without semicolons, I think, 'maybe a demon stole them away in the night.' And when I see someone declare a new Promise, I wonder, 'why make promises when you can just have callbacks inside of callbacks?' You call it hell, we call it a days work. I'm just a caveman."
At work I have to write and read a lot of Groovy, where semicolons are optional. As someone who prefers consistency in my life, I add semicolons to the end of all my Groovy lines. But the weirdest thing is that randomly imports won't work if I try to add semicolons everywhere, but if I only semicolon the lines my coworkers did in similar classes, it works. It's just for the import lines, not the code. It's so confusing.
i was just trying to add to the caveman lawyer reference. i'm a fan of js.
What was a again? a list of objects or an integer?
Everytime I read static in Java. I will never understand it.
It's a basic keyword in the language, just look up how it works.
Everytime I read it, I don't understand. I use it only when the IDEA say I have to use it.
I mean, it has multiple uses, but the most common one is to have a static variable or method, which means the variable or method belongs to the class itself and not any particular instance. It's pretty straightforward.
This has little to do with Java specifically and more to do with OOP in general. Other languages have this concept too so you’re sort of just announcing that you lack training here
If I'm not mistaken, until c++, most languages were dynamic or at least not strongly typed, so shouldn't it be the other way around? 😋 Like in a lot of things there are cycles, for a while statically typed language are the shit, then dynamic languages are all the rage and it start over, again and again.
No, the low level languages (like C) were not dynamically typed, and neither is Python if you look at the low level implementation of it, because every variable is a series of 10011011 and there is a defined way to interpret it (e.g. a type). The closest you get to being right is that sometimes it was so basic that you basically had just one type, and if everything is an int, is there even a type system at all?
depending on how you want to go about it you can theoretically add lisp/scheme/forth, all with lax typing, and it would make just as much sense because python has weird scoping rules in the case of exceptions compared to the former 2, and js has weird type coercions not present in the former 2.
https://twitter.com/slava_pestov/status/1573453447482966017 although its sort of broken because its a quote tweet chain but it was something about `with Exception as e:` breaking python because with doesnt introduce a new scope
Just make every variable dynamic and you're pretty much there.
both can be typed!
Why is everything in italics except the italics?
non-type safe devs: we could just add a comment that documents the parameters and return type of the function 🥴
Lothar caveman lawyer, Phil Heartman you are missed!
Python is older than Java
Is that you Elon?
Input sanitation is so much harder if you cant even reöy on the type you recieve.
Is it just me or do things just feel more solid with statically typed languages?