Why make it complicated?
-
And then assign an int to a string just to mess with the interpreter.
only the linter gives a hoot - the interpreter will happily leave that footgun for later
-
Older variants used DIM for arrays and LET for other variables. DIM was originally called that because it was setting the dimensions of the array.
In modern BASIC variants, DIM has become a backronym: "declare in memory".
In modern BASIC variants, DIM has become a backronym: “declare in memory”.
TIL. I always thought it was a backronym for
declare in (yo) momma
. -
Can we talk about PHP functions with typehints too?
public static function foo(): string {
Practically every other language with similar syntax does this instead:
public static string foo() {
Rust and TypeScript use the return-type-at-the-end convention as well.
-
Because sometimes that
let
can be replaced by other things likeconst
. Which can be managed statically by the machine and not by my (imperfect) ability to know if it's mutated or notOk but, in the second example you typically just put final or const in front of the type to denote immutability. I still don't see the advantage to the first declaration.
-
Because sometimes that
let
can be replaced by other things likeconst
. Which can be managed statically by the machine and not by my (imperfect) ability to know if it's mutated or notI think you can do
const thing = ... as const
to lock down the mutation? -
Rust and TypeScript use the return-type-at-the-end convention as well.
Python too.
-
Good, now invent a keyword for variables you don't want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.
Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.
wrote on last edited by [email protected]In C#, you can use 'var' to have an impilict type variable.
String name = ""
var name = ""
-
Python too.
And Kotlin.
-
Ok but, in the second example you typically just put final or const in front of the type to denote immutability. I still don't see the advantage to the first declaration.
oh for sure, but I think that's the rarer case for language implementions. Having a consistent structure with alternative keywords in static positions is just easier to develop an AST for. Personally my favorite language doesn't even allow for const values (except by convention) so it's really just a matter of preference
-
In C#, you can use 'var' to have an impilict type variable.
String name = ""
var name = ""
So, a keyword
-
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
wrote on last edited by [email protected]Not to short-circuit the joke, but in this case, it's because the valid JavaScript version is...
let a
...and one of TypeScript's main design goals is to be a superset of JavaScript, that only adds syntax, and doesn't re-write it.
Beyond that, it's probably a case of some new language just using what the designer is familiar with.
-
So, a keyword
wrote on last edited by [email protected]So I think it's still probably unclear to people why "mix of keywords and identifiers" is bad: it means any new keyword could break backwards compatibility because someone could have already named a type the same thing as that new keyword.
This syntax puts type identifiers in the very prominent position of "generic fresh statement after semicolon or newline"
..though I've spent like 10 minutes thinking about this and now it's again not making sense to me. Isn't the very common plain "already_existing_variable = 5" also causing the same problem? We'd have to go back to cobol style "SET foo = 5" for everything to actually make it not an issue
-
oh for sure, but I think that's the rarer case for language implementions. Having a consistent structure with alternative keywords in static positions is just easier to develop an AST for. Personally my favorite language doesn't even allow for const values (except by convention) so it's really just a matter of preference
Is it rarer? I think a lot of modern languages go for the first option but pretty much all C style languages use the latter. It's probably a wash for which is more popular I'd think.
-
Rust and TypeScript use the return-type-at-the-end convention as well.
wrote on last edited by [email protected]TypeScript doesn't need the "function" keyword for a method in an object or on a class though.
const foo = { bar(): string { ... } }
which I assume is doable because the syntax is unambiguous.
PHP's object orientation is similar to languages like Java and C#, which is what I was comparing to.
-
Good, now invent a keyword for variables you don't want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.
Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.
wrote on last edited by [email protected]C++ has
auto
, which determines the type automatically. -
Even older variants required both a let to declare the variable and a dim to set its size.
I remember a
REDIM
command, but I really can't remember what basic it's from.The first programming language I used was Visual Basic (both VBA in Excel, and VB3 then VB6). I think it used redim to resize arrays.
-
Is it rarer? I think a lot of modern languages go for the first option but pretty much all C style languages use the latter. It's probably a wash for which is more popular I'd think.
I'm talking about quantity not the popularity of a given language. There are certainly a number of popular languages that follow that convention
-
Can we talk about PHP functions with typehints too?
public static function foo(): string {
Practically every other language with similar syntax does this instead:
public static string foo() {
JavaScript (Typescript for the type part) and python, the most popular scripting languages, use the same order as PHP.
It's usually compiled languages that do the other one.
-
That looks like rust ngl
It's also valid rust syntax.
But if it were rust, this meme would not make sense, since you would just type
let a
and type inference would do its thing. Which is much more ergonomic. -
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
Javascript gonna Javascript