4 ms·

>Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e.

by scythe 4y ago

>Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. The weird thing about these comments to me (as someone who doesn't use Rust) is that the most difficult syntax in the original examples represents a semantic detail that most languages don't have to deal with: the lifetime. The amount of times I think about the lifetimes of variables I write in Python is zero. Parsing the symbols and understanding the code here aren't separate; that weird apostrophe thing in angle brackets is a symbol I don't use referencing a concept I don't use, which fits. If you replaced the symbols with keywords or something, it would just be longer, not simpler. Also, it's a choice to write your code like he did. You can define local variables that hold intermediate results and subexpressions and give them descriptive names, if you want. You could assign `drop = (|_| ())` for example.

mftb 4y ago
Yea, so pretty much every programmer needs to be aware of thinking about lifetimes. The classic issues are creating a local and then giving a reference to it, to something much longer lived, or even undying. In that last case, if your doing it a lot, with no regard to the objects change in lifetime, your effectively creating a leak (I can guarantee you someone, somewhere, is making this mistake in js right now). Most collection strategies won't touch an object that still has a reference to it. The second issue that became really common when people stopped paying attention to lifetimes, is that many resources you may be using (file handles, db connections, etc...) have very different constraints than memory. So you have to be cognizant of the fact that even though something has gone out of scope, it's lifetime really doesn't end until the gc gets around to collecting it. This is the reason special syntax and functions, like "with" and Dispose had to be added to languages like C# and Java. Python with it's reference counting maybe somewhat less susceptible to this second issue than the others, but it's not immune to it. Finally in many cases being aware of object lifetimes and specifically manipulating them can get you performance speed ups.

by scythe 4y ago

mftb 4y ago

Yea, so pretty much every programmer needs to be aware of thinking about lifetimes. The classic issues are creating a local and then giving a reference to it, to something much longer lived, or even undying. In that last case, if your doing it a lot, with no regard to the objects change in lifetime, your effectively creating a leak (I can guarantee you someone, somewhere, is making this mistake in js right now). Most collection strategies won't touch an object that still has a reference to it. The second issue that became really common when people stopped paying attention to lifetimes, is that many resources you may be using (file handles, db connections, etc...) have very different constraints than memory. So you have to be cognizant of the fact that even though something has gone out of scope, it's lifetime really doesn't end until the gc gets around to collecting it. This is the reason special syntax and functions, like "with" and Dispose had to be added to languages like C# and Java. Python with it's reference counting maybe somewhat less susceptible to this second issue than the others, but it's not immune to it. Finally in many cases being aware of object lifetimes and specifically manipulating them can get you performance speed ups.