This is not really audio, but when it comes to programming, I don't think any sort of listening material (by itself) is ever going to top visual material. In that department, I recommend this app:
Yep. I think the names themselves are quite unambiguous to boot. A variable is something that varies in value, meaning it can be changed. A value is always that same value; 5 is never 6. Pretty straightforward if you ask me.
I'm guessing the parent is just complaining that if you are reading code very fast (particularly if you're browsing repositories on your phone) it is hard to distinguish between "val" and "var."
In many cases, you would get warnings when accessing a var that you don't get when accessing a val. Also, IntelliJ suggests converting to val if a var is never reassigned.
I'm personally a fan of the Rust way, i.e. `let` for const bindings and `let mut` for mutable ones. I think it's fairly clear which is which, and having to type four extra characters to get mutability helps reinforce the notion of const being the default choice.
Am I being a complete noob that only knows Python (I am) if I ask: Why do you need to declare that something is a mut or string or whatever? Python doesn't seem to need such extra lines with obvious declarations.
A couple important benefits (there are many others, as well as drawbacks) are
1) the compiler can then warn you when you violate your own declarations before the code is ever run. e.g. it can tell you that you've mutated something you said you didn't want to, or that you've taken the sum of an int and a list.
2) the compiler can guarantee certain things at compile time and thus eliminate the overhead of checking them at runtime. since a value in Python can be anything, before performing a string operation on a string the python runtime must first check that it is a string, while the runtime of a language like rust can assume that it is because that was guaranteed at compile time.
As others have mentioned, the idea is to have the compiler enforce certain things for you to reduce the chances of making an error. One illustrative way I've seen it explained is that if you accidentally make a variable immutable when you want it to be mutable, you get a very straightforward compiler error message saying something like "you can't mutate this variable since it's const; maybe you should make it mutable?". On the other hand, if you want a variable to be immutable but it's actually mutable and you change it, you can end up with all sorts of tricky bugs like race conditions which are much harder to debug.
mut listOfLeftHandedOralHygienistsInKazakhstan = getThem()
// several lines later
listOfLeftHandedOralHygienistsInKazahkstan = getThemAgain()
You thought you were reassigning the mutable variable, but you actually created a different immutable variable.
This can be prevented by having different operators for assignment and re-assignment. Some languages do that: in OCaml / F#, re-assignments use '<-' while declarations use 'let (mutable) x =' (they can't drop the 'let' because they use '=' as the Boolean equality operator).
Sure, but Kotlin is more about being explicit and less about evangelizing one style of programming over another. It's very pragmatic in that way. There are plenty of scenarios where you're maintaining local state (properly encapsulated within a class, exposing a functional interface, etc) and you need mutable fields. Even plenty of scenarios where you want to operate on a value mutably in a function and then return it. It may seem confusing at first but in practice I've never mixed the two up.
But this most likely is because Scala uses val/var.
If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is less important.)
val/var/const/whatever only describe the reference, not the value. It doesn't really make sense for that annotation to, say, swivel a collection between ImmutableList and MutableList.
Now, you might be right that it's confusing, this difference between reference mutability and value mutability. I see beginners struggle with it in Javascript's new let vs const all the time.
2. Java does a lot with the keyword 'final'. I guess here you're talking about the concurrency behaviors of it? Does it bother you that you can remove 'final' via reflection?
3. It's still useful (e.g. not needing to use yoda-style ifs in languages where you can assign inside an if expression Just In Case you forget an =), but not very. That's my whole point.
1. the issue is one of visibility; e.g. you can initiate and pass / share String objects safely between threads without synchronization or worries because underlying String there's a final char[] backing it.
What `final` guarantees is that the variable will be initialized and visible (along with all its referenced objects) before the class constructor is finished. Without this guarantee you'd need `volatile` semantics or locks, which are more problematic.
2. yes, I'm talking about multi-threading; if the user removes "final" via reflection, or modifies final references via reflection, then it gets what he's asking for; but no, it does not bother me because I never do that and I stay away from libraries using reflection anyway.
I thought that's how the majority of languages worked. It just means the variable cannot be changed to reference a different value. It does not make the value immutable.
It really depends on the language. 'const' in C works differently from 'const' in other languages (even C++, which has some great 'const' use cases that make guarantees about whether values will change, not just about the symbol binding), they both work differently than 'final'. Similar confusions with 'static'. If all you want to say is "cannot reassign this symbol", then 'val' is great and sidesteps this whole history of readability and meaning confusion.
In Rust, it does (in general) make the value immutable. Most mutations of values in Rust are done through mutably borrowing the value, which you can't do when the value is defined with `let` rather than `let mut`, the exceptions being things like `Mutex`, which gives you a value that can be mutably borrowed when you acquire the lock.
Kotlin as a language has expectations on IDE capabilities. I doubt the problem of accidentally typing "r" instead of "l" at the end of a keyword is as prevalent as someone typing "var" instead of "const" and not coming back to make it immutable. A quality compiler can warn about an unmutated mutable variable which solves all problems.
Remember recently on the Java mailing list there was a lot of bikeshedding concerning this point. I don't think it matters near as much as the discussion surrounding it thinks.
Oh, and finally, "const" has a specific meaning: compile time constants.
When it comes to reading it is very clear in the IDE. val variables look normal (since immutability is encourage), var variables are underlined. You get used to it very quickly
Only you can be sure of shortened words even if it looks obvious. Not good in a team.
I never understood people who shorten words to make the program look cryptic. Maybe it was someone who taught you how to program had it that way or somehow it makes you feel your program looks cooler if it looks more cryptic.
'value' is frequently a keyword or property on objects, and has specific meaning in a lot of contexts. For names, IMO 'k' and 'v' also work, but I find an abundance of single-letter variables hard to read. key and val it is.
`val` isn't the variable name, it's the declaration. I'd imagine `val multiplier = 2' to make perfect sense. `var` likewise doesn't connote any truly valuable information other than the label for the memory location that follows is mutable.
I find this syntax very clear, usually start with val and try to stick to it. Moving to var is one char-change only. Also val stands for "value" which is a well known term for immutable data. I think about const as static values, while val are instance values.
It's obviously very strongly influenced by Scala, to the point of adopting a number of its syntax decisions that are considered questionable (procedure syntax, infix notation, "=" function definitions).
I will echo what the others have said; it's not what I would choose, but in practice it's never been a problem when I'm writing Scala.
For the same reason omitting braces in C-style-syntax conditionals and loops is questionable, i.e. misleading indentation.
As a bit of an unreformed code golfer and a fan of ML-style syntax, I actually kinda like it myself; I was just listing a few things that are "considered questionable" (by some people) and present in both languages.
I still fail to see what makes this questionable. It's just syntactic sugar that you don't even need to use, and which is pretty clear when you see it in the wild.
I'm guessing here: With const there's always the disccusion about consts not being constant, e.g. when referencing an array or object (reference itself is constant). With "val" you don't have that confusion?
Const exists too, but for compile-time constant. Var and val are ok due to the general conciseness of the language (they don't get lost in the noise of other ceremonies).
Plus, being a language though to benefit from strong tooling, IDE's will generally display the two differently.
Rust has a pattern-matching "let" and then you can prefix names within any pattern with "mut" to make it mutable. So a basic mutable var is "let mut" but it's just a combination of two other features. I think it's a totally neat design.
The IDE underlines mutable variables at both definition and use sites. Values are not underlined. It's a perfectly fine way to visually distinguish them.
Pet peeve here: "variable" and "mutable" aren't concepts that are useful to conflate. Imagine a function that takes a variable and prints its value to the command line. There's no mutation of the variable going on, so the variable is immutable. And yet it's still a variable because each time that you call this function, the value that gets printed is allowed to vary. This is distinct from a constant, where each time you call the function the value of a constant must be the same.
One keystroke, not two? I type l<tab> in Xcode then I'm typing in the variable name. You'll have to arrow down if it's the wrong one then hit return.
You can argue that it's really not much extra work but it all adds up. Especially when you try to code on a tablet, which I find myself doing occasionally.
So the main complaint about SPP is that it screws password managers, but then there's this:
> Most password managers erase the clipboard as soon as they have pasted your password into the website, and some avoid the clipboard completely by typing in the password with a 'virtual keyboard' instead.
Isn't the latter approach much safer? If so, shouldn't it be the de facto standard since it prevents "clipboard stealing" and also removes the issue of not being able to paste content into an SPP form input?
Allowing apps to create virtual keyboards with which they may manipulate all other apps might not be a good idea. That's why it won't work with Wayland for example.
I mean your password manager already has all your passwords. The argument can be made that you can trust the man who already has a knife to your throat.
> Think of a prominent global-company CEO. Sir Martin Sorrell? Indra Nooyi? Elon Musk?
> Now, name the CFO and CMO. I bet you can’t.
I can't, but it's because it's not the CFO and CMO representing the company on the public realm, so they're not the faces and names I see when there's news about a company in which I do not work at or with.
If this "exposure" happens within a company as well, that's an issue for each company to assess and deal with accordingly.
Fair point. I inferred OP was in the US, considering the US election that just ended and people were jokingly talking about leaving the country[1] to other places.
https://play.google.com/store/apps/details?id=wiki.algorithm...
https://itunes.apple.com/us/app/algorithms-explained-and-ani...