let, var, val - Swift, Kotlin, JavaScript
-
C++/30 will consist entirely of keywords and variables will be inferred by the context.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Wait until you see VB.NET's array declarations. They still use the upper bound instead of the length because that's what VB6 did, despite the fact that the reason it did that no longer applies to VB.NET! :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
Wait until you see VB.NET's array declarations. They still use the upper bound instead of the length because that's what VB6 did, despite the fact that the reason it did that no longer applies to VB.NET! :-D
I haven't used an upper bound in a VB.Net array declaration for several years. The upper bound is optional and only really useful if you know ahead of time how big your array will be. Almost all the dotNet framework collection classes support this feature as well. There are times when it's useful but generally you don't need this feature.
-
If you do native iOS (Swift) and native Android (Kotlin now) and web dev (JavaScript), you will find that Swift, Kotlin and JavaScript will have you going crazy in their choice of usage of :
let,var, andvalThey use similar keywords all in different ways. Swiftlet pi = 3.14 // defines constant
var randValue = 55; // defines variableOf course, let does something different in JavaScript. Of course... :sigh: JavaScript
let x = 1; // outer scope
var y = 7; // (global scope)if (x === 1) {
let x = 2; // DIFFERENT x (local scope)
var y = 107; // SAME Y (global scope)console.log(x); // expected output: 2
console.log(y); // expected output : 107
}
console.log(x) // expected output: 1
console.log(y); // expected output: 107Kotlin Note: CP doesn't have a choice for Kotlin yet, so val keyword isn't blue.
val pi = 3.14 // defines constant
var randValue = 55; // defines variablevaris used by all three.letis used by Swift and JavaScript differently.valis only used by Kotlin. Language Design Ideas We know everyone steals design ideas from each other, so why didn't the designers of these languages steal from each other and makeletandvarmean the same darn things?!? X|Which is why using C# for native iOS and Android apps, as well as MacOS, tvOS, Linux, and web apps (with webassembly) makes so much sense. No Java, no Kotlin, no Swift, no JavaScript (or the myriad of JS libraries). Just C# for them all.
-
Recently, I stumbled over C# and C++ meaning rather different concepts with their "array". While I may seem rather snarky here, I think that language designers more often than not explicitly try to remain different from the existing stuff for the sake of, I guess, differentiation for the sake of it.
When I learned the way C# understands arrays, it gave me a deja-vu to Algol 68. In those days (the language definition was published in 1968), hardware wasn't fast enough to make such complex language very useful. Experience with optimizing such constructs were limited, too. So Algol 68 never made it into the mainstream. When I learned about it 10-12 years later (we didn't have a compiler, but studied its concepts, in the university compiler course) we saw it as a collection of great ideas that couldn't be realized in practice, in any useful way. So when I saw C# actually realizing those array concepts, it was sort of like a dream from my student days coming true.
-
If you do native iOS (Swift) and native Android (Kotlin now) and web dev (JavaScript), you will find that Swift, Kotlin and JavaScript will have you going crazy in their choice of usage of :
let,var, andvalThey use similar keywords all in different ways. Swiftlet pi = 3.14 // defines constant
var randValue = 55; // defines variableOf course, let does something different in JavaScript. Of course... :sigh: JavaScript
let x = 1; // outer scope
var y = 7; // (global scope)if (x === 1) {
let x = 2; // DIFFERENT x (local scope)
var y = 107; // SAME Y (global scope)console.log(x); // expected output: 2
console.log(y); // expected output : 107
}
console.log(x) // expected output: 1
console.log(y); // expected output: 107Kotlin Note: CP doesn't have a choice for Kotlin yet, so val keyword isn't blue.
val pi = 3.14 // defines constant
var randValue = 55; // defines variablevaris used by all three.letis used by Swift and JavaScript differently.valis only used by Kotlin. Language Design Ideas We know everyone steals design ideas from each other, so why didn't the designers of these languages steal from each other and makeletandvarmean the same darn things?!? X|The first thing that popped into my head was a line from the movie, "Bull Durham" when Nuke's father says, "let's say a prayer" and Susan Sarandon's character says, "oh, let's not."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
If you do native iOS (Swift) and native Android (Kotlin now) and web dev (JavaScript), you will find that Swift, Kotlin and JavaScript will have you going crazy in their choice of usage of :
let,var, andvalThey use similar keywords all in different ways. Swiftlet pi = 3.14 // defines constant
var randValue = 55; // defines variableOf course, let does something different in JavaScript. Of course... :sigh: JavaScript
let x = 1; // outer scope
var y = 7; // (global scope)if (x === 1) {
let x = 2; // DIFFERENT x (local scope)
var y = 107; // SAME Y (global scope)console.log(x); // expected output: 2
console.log(y); // expected output : 107
}
console.log(x) // expected output: 1
console.log(y); // expected output: 107Kotlin Note: CP doesn't have a choice for Kotlin yet, so val keyword isn't blue.
val pi = 3.14 // defines constant
var randValue = 55; // defines variablevaris used by all three.letis used by Swift and JavaScript differently.valis only used by Kotlin. Language Design Ideas We know everyone steals design ideas from each other, so why didn't the designers of these languages steal from each other and makeletandvarmean the same darn things?!? X|[obligatory XKCD](https://xkcd.com/927/)
I'd rather be phishing!
-
When I learned the way C# understands arrays, it gave me a deja-vu to Algol 68. In those days (the language definition was published in 1968), hardware wasn't fast enough to make such complex language very useful. Experience with optimizing such constructs were limited, too. So Algol 68 never made it into the mainstream. When I learned about it 10-12 years later (we didn't have a compiler, but studied its concepts, in the university compiler course) we saw it as a collection of great ideas that couldn't be realized in practice, in any useful way. So when I saw C# actually realizing those array concepts, it was sort of like a dream from my student days coming true.
What concepts are those? Because automatically managed dynamic generic type-safe arrays by themselves don't wow me as much, I've been using them extensively in Delphi as well and they're just as comfortable as in C#.
-
What concepts are those? Because automatically managed dynamic generic type-safe arrays by themselves don't wow me as much, I've been using them extensively in Delphi as well and they're just as comfortable as in C#.
First and foremost, ragged arrays - a vector of vectors (of vectors of ...), each of a different size. That requires a radically different memory allocation strategy and address calculation strategy. (Algol 68 also allowed arbitrary lower bounds, which unfortunately has not been carried over to C#.) Also, a function argument could be an array of any dimension; it was transferred by a descriptor stating the dimension of the actual argument. I am not sure if the actual argument could be dimensioned at runtime - with all the other mechanisms required for array handling, dynamic sizing woudln't add that much extra :-). Lots of the things you see in Algol 68 (in addition to ragged, dynamically sized arrays) are present / common in languages of today. But Algol 68 preceeded Pascal by two years, it appeared at roughly the same time as Fortran IV. While we were using named COMMON in Fortran, Algol 68 offered dynamic, ragged arrays, with index checks. And pointers. And user defined operators. And threads with semaphore synchronization. And ... It was like a brainstorming language. All the crazy ideas thrown out on the table at the same time. It took quite a few years to mold those ideas into something useful, and learn how they could be realized efficiently. Today we know how. But fifty plus years ago, the ideas seemed rather crazy to those who worried about the different address calculation whether you lay out fixed size, rectangular arrays by row (Pascal) or by column (Fortran). Algol 68 was in a completely different world, at that time.
-
First and foremost, ragged arrays - a vector of vectors (of vectors of ...), each of a different size. That requires a radically different memory allocation strategy and address calculation strategy. (Algol 68 also allowed arbitrary lower bounds, which unfortunately has not been carried over to C#.) Also, a function argument could be an array of any dimension; it was transferred by a descriptor stating the dimension of the actual argument. I am not sure if the actual argument could be dimensioned at runtime - with all the other mechanisms required for array handling, dynamic sizing woudln't add that much extra :-). Lots of the things you see in Algol 68 (in addition to ragged, dynamically sized arrays) are present / common in languages of today. But Algol 68 preceeded Pascal by two years, it appeared at roughly the same time as Fortran IV. While we were using named COMMON in Fortran, Algol 68 offered dynamic, ragged arrays, with index checks. And pointers. And user defined operators. And threads with semaphore synchronization. And ... It was like a brainstorming language. All the crazy ideas thrown out on the table at the same time. It took quite a few years to mold those ideas into something useful, and learn how they could be realized efficiently. Today we know how. But fifty plus years ago, the ideas seemed rather crazy to those who worried about the different address calculation whether you lay out fixed size, rectangular arrays by row (Pascal) or by column (Fortran). Algol 68 was in a completely different world, at that time.
Thank you for the explanation.
-
[obligatory XKCD](https://xkcd.com/927/)
I'd rather be phishing!
