Types are important for type safety, so you don’t access properties that don’t exist, can use polymorphism etc. However, having worked in both duck-typing and hard typing languages, I believe the most important part of a type is it’s name.
Classes are are arbitrary constructs we create to help us understand and manage code. They are inherently organisational structures.
That may sound like an argument FOR putting the name of the class first. “If I know it’s a ConnectionCredentialsQuery, I don’t need to know it’s name, the use-case is evident!” Classes often get reused though, like a CartesianPoint. You may create several instances of them. Which of the name and type below are more indicative of use?
CartesianPoint PlayerPosition;
Types are, to some extent, implementation detail. The name tells you what the variable is for, which is more important.
Another point: You will always need to name variables well, because after declaration, whenever you see a variable, you will only see its name. You want to be able to fully understand what you are looking at without having to mouse over or go back to the declaration of a variable.
Additionally, many typed languages will allow you to use a syntax to altogether avoid declaring the type of a variable if derived from somewhere else.
var result = a + b;
var customer = new Customer();
Given that the type can be inferred, and therefore specifying it explicitly is optional, why make it the first thing you see? That means you need to move your eye back and forth when looking for the names of things. Which of these two are better for legibility:
var result = a + b;
CartesianCoordinate playerPosition;
const result = a + b;
letplayerPosition: CartesianCoordinate;
Finally, you say that types are more important because they are important to the compiler, but compilers don’t care about the order of these definitions. Compilers exist to allow us to write easier to read code. They exist to convert high level languages to low level byte code. They exist to enable more readable code.
If you’re looking for declarations, some languages use const, let or var followed by the name of said variable. That’s a little easier to find than having a type name at the start, so I don’t think what you’re saying gives the other approach an advantage. The indentation is also more consistent with these keywords, which helps.
I realise some languages (like Python) don’t use these sorts of keywords during declaration. For those languages it could indeed be a disadvantage.
What you’re saying is more consistent, but I don’t think it’s more readable
I’m fine with let or var…if the compiler is going to infer the type thats all well and good. But it’s a replacement for the type - why would you write both? It should be either or
And if the type is being inferred, the next thing I want to know is where it came from. That tells you the type and more, I don’t want to have to see a type name that may or may not be there
Not… really. I can kinda see where you’re coming from, but if you are assigning a .ToString() to a variable, the only type it could be is a string.
It’s not guessing, it’s inference. You’ve provided enough information to know what the type is, so it is now that type. The moment you introduce ambiguity, such as var test = 1 there are many things that variable could be, so you can no longer infer its type.
Inference is not guessing. Can it go wrong? Certainly! But its quite rare. And the solution in those rare cases is explicit typing.
I come from a background of porting code between architectures, like 16 to 32 bit. The int type in C was (is) ambiguous in that case, 16 bit signed int on the 16 bit system, 32 bits on the 32 bit system. First thing I had to do to make the 500,000 LOC package start to run properly when ported from 16 bits to 32 bits was find and replace all " int "with " int16 ", “(int)” with “(int16)” etc. It was only going wrong “quite rarely” - but “quite rarely” doesn’t cut it, they ALL needed to behave predictably the same as they did before the move. I believe that effort took 3 solid work days, 24 hours of my life, because “int” was “good enough” for the previous team.
Er… okay, yes. That would be quite the annoyance, but thats a bit of an edge case in this instance. I’d also wager that current implementations of IDEs would allow you to intelligently replace int with Int16/Int32/Int64 depending on the context before migration. I believe Visual Studio proper has that as an option in its code analysis and cleanup tool. You can also do the same for var => string typing if I remember correctly.
My point is: as a programmer, you should always care how your value is handled. All variable types have limitations, edge cases, and resource demands (infinite capacity big-int representations are slow and memory intense, even if they never overflow or underflow.) KNOW what your code is doing with the value.
I’m O.K. with API style functions accepting all kinds of inputs and dealing with them in a predictable way once called, but if you’re writing code that handles values, once you have been assigned those values you should be getting, deterministically, the same result every time.
Otherwise, you’re like those kids in programming class writing while loops with floating point control variables that increment +0.1 per loop, thresholded to stop at v >= 100.0
You do realize that in C# at least, these compile to strongly typed variables? Barring a major change, such as migrating from 16 to 32 bit, you know what those value types are, you’re just not having to write them out. It saves you from having to type “LongDescriptiveTypeDescriptionBecauseSomeoneWasOverlyVerboseInTheirNaming” which is a small but nice thing to have. We arent talking about dynamics here.
Ooooh my poor fingers… yes, I used to worry about abbreviating everything as short as possible, and I still control my loops with i j and k, but when it comes to ambiguous var vs QString or int32 or float or double or whatever type du jour is, I’ll take the time and effort to write it out rather than taking the time later to untangle how the ambiguity might have resolved and all the unexpected things that might happen as a result of an unexpected resolution.
My language does that, as well as English in which I am fluent. I still find type-first to be impractical.
Also when you write the code, you are usually looking to create a variable, so maybe you type “var” or “const”, right, then you have a contextual name in mind, maybe salary. Then you can make a decision, which type it should be. Maybe “whole dollars”? “Dollars in a decimal number”? Or it could be a complex type in other contexts.
That’s how I prefer to write code. 👍
Maybe it makes more sense to someone who knows more than one language as well, e.g. languages that use a noun-adjective structure, like French, or Farsi. I don’t know. But for me it’s not about language, it’s about practicality. Findability and writability, if those can be considered words, lol.
My main language is french, and yet i prefer the type-name order. Maybe its because i first learned C, but i guess its also because it goes from general to particular, whereas name-type feels like going backward (being detailed with name, then vague with type, then more detailed with value assignment). Anyway, i guess you’re right, it’s probably not a lot about language.
Maybe this comes from a non-typed language perspective… As someone who learned in Java, I do not like it because yeah, type is way more important. If someone was coming from Python, I can see why they might think this…
I learned C++ first, have been using python for the last decade almost daily for various one off tasks. I like python, but if I had to build something that will be used even hundred of thousand times, I wouldn’t do it in python.
Anyway point being, despite me using for decades, I still yearn for C++.
I tried to use C++ in 1991 but the Borland Turbo C++ compiler was too buggy, so we used C instead. By 1996 C++ was “ready for primetime” on IBM-compatible PCs (yes, they still called them that, sometimes in 1996) and I switched - for 30 years.
I just spent 10 days building a proof of concept in Python, all the “common wisdom” says that was the fast way to get it done. Now that the prototype is done and the (initial) user feedback is addressed, I’m running a port to something better for lightweight, performant, easy deployment… sadly, C++ isn’t even on the radar for potential targets - top 3 candidates were Go, Rust and C#. I can’t abide the C# ecosystem, and Rust is just a little too rigid and immature for my tastes, so here we Go… anticipated to take 50% longer to port from Python than the Python took to develop in the first place… we shall see…
My perception is one of a treadmill. My fellow developers in C# are much more frequently analyzing migration from one incarnation to the next, updating and installing their license files, evaluating compatibility between versions, and generally spinning their wheels on things not required for getting work done on other platforms.
Back in the day, I was getting a new “99% compatible” DOS version every 6 months (until we transitioned to the PharLap 32 bit extender, got more memory to work with AND stopped the perpetual upgrade treadmill.)
That “99% compatible” thing means: in a 10,000 LOC codebase, you’ve got 100 things to fix before it works on the new DOS.
I really liked working with Qt from 2006-2024 or so, the only major break was 4-5 (must admit, I never migrated to 6, and nobody forced me to…) and the migration from 4-5 was less painful than a DOS version bump. Also, Qt fully insulated our code from garbage changes happening at lower layers.
I learned Java first. I think type should come second as well, like in TypeScript et al.
If you’re ever looking for the variable manually for some reason, by searching with your eyes, it’s easier to find it by searching in the first character column.
Otherwise, if you ever need to see the type of something, which… should be obvious from the context in quality code, your LSP should just be able to tell you directly, by some mechanism (hover with mouse, or some keyboard action).
Type is more important? So if the first argument of a function is minAge, which is an int, the important part is that it is an int? Just feed it any int?
No, the important part is the meaning, what the variable actually is, if you use a compiled language the compiler will handle types for you anyway. You’ll get a error if you feed it a string, or an water heater object, no surprises.
Leave the machine work to the machine (compiler in this case), and concentrate on the real work, which is the meaning here.
not precisely. Rust has let mut and Kotlin has val; ie the member layout and the mutability are treated differently, since those languages have mutability rules.
this is a circular argument anyway. the language designers could have figured out a way to do type inference like, eg, Java, but, again, explicitly chose not to.
Hard disagree. Is that a joke? Type is far More important than name. Just ask the compiler.
As other users have said, we aren’t compilers.
Types are important for type safety, so you don’t access properties that don’t exist, can use polymorphism etc. However, having worked in both duck-typing and hard typing languages, I believe the most important part of a type is it’s name.
Classes are are arbitrary constructs we create to help us understand and manage code. They are inherently organisational structures.
That may sound like an argument FOR putting the name of the class first. “If I know it’s a
ConnectionCredentialsQuery, I don’t need to know it’s name, the use-case is evident!” Classes often get reused though, like aCartesianPoint. You may create several instances of them. Which of the name and type below are more indicative of use?Types are, to some extent, implementation detail. The name tells you what the variable is for, which is more important.
Another point: You will always need to name variables well, because after declaration, whenever you see a variable, you will only see its name. You want to be able to fully understand what you are looking at without having to mouse over or go back to the declaration of a variable.
Additionally, many typed languages will allow you to use a syntax to altogether avoid declaring the type of a variable if derived from somewhere else.
var result = a + b; var customer = new Customer();Given that the type can be inferred, and therefore specifying it explicitly is optional, why make it the first thing you see? That means you need to move your eye back and forth when looking for the names of things. Which of these two are better for legibility:
var result = a + b; CartesianCoordinate playerPosition;const result = a + b; let playerPosition: CartesianCoordinate;Finally, you say that types are more important because they are important to the compiler, but compilers don’t care about the order of these definitions. Compilers exist to allow us to write easier to read code. They exist to convert high level languages to low level byte code. They exist to enable more readable code.
Thank you for coming to my TED talk.
Counter argument - putting the type first makes it easier to see where it is declared. Which is more important than the name or the type
If you’re looking for declarations, some languages use
const,letorvarfollowed by the name of said variable. That’s a little easier to find than having a type name at the start, so I don’t think what you’re saying gives the other approach an advantage. The indentation is also more consistent with these keywords, which helps.I realise some languages (like Python) don’t use these sorts of keywords during declaration. For those languages it could indeed be a disadvantage.
What you’re saying is more consistent, but I don’t think it’s more readable
I’m fine with let or var…if the compiler is going to infer the type thats all well and good. But it’s a replacement for the type - why would you write both? It should be either or
And if the type is being inferred, the next thing I want to know is where it came from. That tells you the type and more, I don’t want to have to see a type name that may or may not be there
Controversial take: it doesn’t matter in the slightest.
Breaking News: local dev argues peanut butter on jam is the same as jam on peanut butter.
Try to write some code and see if it matters. Try to argue against a compiler, please.
Typeless variables are a delusion, they’re just guessing what type they should be for you.
Not… really. I can kinda see where you’re coming from, but if you are assigning a .ToString() to a variable, the only type it could be is a string.
It’s not guessing, it’s inference. You’ve provided enough information to know what the type is, so it is now that type. The moment you introduce ambiguity, such as
var test = 1there are many things that variable could be, so you can no longer infer its type.Inference is not guessing. Can it go wrong? Certainly! But its quite rare. And the solution in those rare cases is explicit typing.
I come from a background of porting code between architectures, like 16 to 32 bit. The int type in C was (is) ambiguous in that case, 16 bit signed int on the 16 bit system, 32 bits on the 32 bit system. First thing I had to do to make the 500,000 LOC package start to run properly when ported from 16 bits to 32 bits was find and replace all " int "with " int16 ", “(int)” with “(int16)” etc. It was only going wrong “quite rarely” - but “quite rarely” doesn’t cut it, they ALL needed to behave predictably the same as they did before the move. I believe that effort took 3 solid work days, 24 hours of my life, because “int” was “good enough” for the previous team.
Er… okay, yes. That would be quite the annoyance, but thats a bit of an edge case in this instance. I’d also wager that current implementations of IDEs would allow you to intelligently replace int with Int16/Int32/Int64 depending on the context before migration. I believe Visual Studio proper has that as an option in its code analysis and cleanup tool. You can also do the same for var => string typing if I remember correctly.
My point is: as a programmer, you should always care how your value is handled. All variable types have limitations, edge cases, and resource demands (infinite capacity big-int representations are slow and memory intense, even if they never overflow or underflow.) KNOW what your code is doing with the value.
I’m O.K. with API style functions accepting all kinds of inputs and dealing with them in a predictable way once called, but if you’re writing code that handles values, once you have been assigned those values you should be getting, deterministically, the same result every time.
Otherwise, you’re like those kids in programming class writing while loops with floating point control variables that increment +0.1 per loop, thresholded to stop at v >= 100.0
You do realize that in C# at least, these compile to strongly typed variables? Barring a major change, such as migrating from 16 to 32 bit, you know what those value types are, you’re just not having to write them out. It saves you from having to type “LongDescriptiveTypeDescriptionBecauseSomeoneWasOverlyVerboseInTheirNaming” which is a small but nice thing to have. We arent talking about dynamics here.
Ooooh my poor fingers… yes, I used to worry about abbreviating everything as short as possible, and I still control my loops with i j and k, but when it comes to ambiguous var vs QString or int32 or float or double or whatever type du jour is, I’ll take the time and effort to write it out rather than taking the time later to untangle how the ambiguity might have resolved and all the unexpected things that might happen as a result of an unexpected resolution.
Are you a compiler?
Maybe, but i speak English that follows adjective - noun pattern. So I’m already conditioned to type - name
My language does that, as well as English in which I am fluent. I still find type-first to be impractical.
Also when you write the code, you are usually looking to create a variable, so maybe you type “var” or “const”, right, then you have a contextual name in mind, maybe
salary. Then you can make a decision, which type it should be. Maybe “whole dollars”? “Dollars in a decimal number”? Or it could be a complex type in other contexts.That’s how I prefer to write code. 👍
Maybe it makes more sense to someone who knows more than one language as well, e.g. languages that use a noun-adjective structure, like French, or Farsi. I don’t know. But for me it’s not about language, it’s about practicality. Findability and writability, if those can be considered words, lol.
My main language is french, and yet i prefer the type-name order. Maybe its because i first learned C, but i guess its also because it goes from general to particular, whereas name-type feels like going backward (being detailed with name, then vague with type, then more detailed with value assignment). Anyway, i guess you’re right, it’s probably not a lot about language.
Exactly, first language (spoken or programming) doesn’t seem to play a role. It’s more about the mental model. 👍
Maybe this comes from a non-typed language perspective… As someone who learned in Java, I do not like it because yeah, type is way more important. If someone was coming from Python, I can see why they might think this…
I learned C++ first, have been using python for the last decade almost daily for various one off tasks. I like python, but if I had to build something that will be used even hundred of thousand times, I wouldn’t do it in python.
Anyway point being, despite me using for decades, I still yearn for C++.
I tried to use C++ in 1991 but the Borland Turbo C++ compiler was too buggy, so we used C instead. By 1996 C++ was “ready for primetime” on IBM-compatible PCs (yes, they still called them that, sometimes in 1996) and I switched - for 30 years.
I just spent 10 days building a proof of concept in Python, all the “common wisdom” says that was the fast way to get it done. Now that the prototype is done and the (initial) user feedback is addressed, I’m running a port to something better for lightweight, performant, easy deployment… sadly, C++ isn’t even on the radar for potential targets - top 3 candidates were Go, Rust and C#. I can’t abide the C# ecosystem, and Rust is just a little too rigid and immature for my tastes, so here we Go… anticipated to take 50% longer to port from Python than the Python took to develop in the first place… we shall see…
Why not? I like working in C#, so I’m curious what about the ecosystem bothers you.
My perception is one of a treadmill. My fellow developers in C# are much more frequently analyzing migration from one incarnation to the next, updating and installing their license files, evaluating compatibility between versions, and generally spinning their wheels on things not required for getting work done on other platforms.
Yeah, fair. New versions release every year. It’s usually good stuff, but it does add some toil to existing codebases.
Back in the day, I was getting a new “99% compatible” DOS version every 6 months (until we transitioned to the PharLap 32 bit extender, got more memory to work with AND stopped the perpetual upgrade treadmill.)
That “99% compatible” thing means: in a 10,000 LOC codebase, you’ve got 100 things to fix before it works on the new DOS.
I really liked working with Qt from 2006-2024 or so, the only major break was 4-5 (must admit, I never migrated to 6, and nobody forced me to…) and the migration from 4-5 was less painful than a DOS version bump. Also, Qt fully insulated our code from garbage changes happening at lower layers.
I learned Java first. I think type should come second as well, like in TypeScript et al.
If you’re ever looking for the variable manually for some reason, by searching with your eyes, it’s easier to find it by searching in the first character column.
Otherwise, if you ever need to see the type of something, which… should be obvious from the context in quality code, your LSP should just be able to tell you directly, by some mechanism (hover with mouse, or some keyboard action).
I only use python and I don’t understand why someone might think that. The order in python’s type hints is wrong too.
Script languages are quick and dirty (but slow), I hate it when they try to shoehorn every high level concept into them.
Type is more important? So if the first argument of a function is
minAge, which is anint, the important part is that it is anint? Just feed it anyint?No, the important part is the meaning, what the variable actually is, if you use a compiled language the compiler will handle types for you anyway. You’ll get a error if you feed it a string, or an water heater object, no surprises.
Leave the machine work to the machine (compiler in this case), and concentrate on the real work, which is the meaning here.
a lot of modern languages explicitly disagree, eg Kotlin and Rust
I think that’s so type inference can work by just omitting the type, instead of having to use “var” or “auto” in front of the variable name
not precisely. Rust has
let mutand Kotlin hasval; ie the member layout and the mutability are treated differently, since those languages have mutability rules.this is a circular argument anyway. the language designers could have figured out a way to do type inference like, eg, Java, but, again, explicitly chose not to.
deleted by creator
sorry, I’m not a compiler, so no