I had the same initial reaction, but it turns out that if you have at least one private member, even with the same signature, it works as the parent comment suggests.
For example, these two classes are distinct to TypeScript:
class Name {
constructor(private value: string) {}
getValue() {
return this.value;
}
}
class Email {
constructor(private value: string) {}
getValue() {
return this.value;
}
}
const email: Email = new Name(“Tim”); // Error: (paraphrasing) conflicting private declaration of “value”.
Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me.
For example, string interpolation:
"Hello, (msg)$!\n"
Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?
I think $() makes much more sense than ()$ in terms of parsing, when you see $ you're looking for a single word token, and $( you're parsing up to the matching )
Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket. Consider parsing "((x)$)" would require parsing the entire string to determine the first bracket wasn't a capture, then we can treat just the first character as a literal, then we have to re-parse the rest of the string again, and can't be sure it's a capture until the $, and then we can evaluate it as a real expression and then continue with the final $.
Other interesting cases would be "(x+(x)$)" or even "((x+(x)$)$)". I'm not sure I could easily predict the parsing of latter, but prefix and permitted unbracketed single word variable names "(x+$x)" is clearer and the second would either be "(x+$(x)$)" or "($(x+$(x)))" both of which are explicit using the prefix form and could simplify to "(x+$x$)" and "($(x+$x))" where the intent seems clearer.
There's the precedent that many languages already use the prefix form which would help newcomers with familiarity, and in fact many of these languages wouldn't even need the brackets and $var would be sufficient, and I can't really see why the spec requires the brackets in the ()$ syntax in string literals but not for expressions in code.
> Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket.
You don't have to: you can also just parse the string backwards.
That raises more questions though... Like, why does the capture syntax have to be attached to the captured element?
Rust for example has a single `move` syntax for all-capture vs. no-capture toggle, e.g. `|x| x + foo` (`foo` is stored as a reference) vs. `move |x| x + foo` (`foo` is moved into the closure). While I do want an additional mode for uniformly applying specific methods (typically `.clone()`) for captured elements, that is almost enough for typical closures.
Also, if my reading of the documentation is correct, `$` has to be attached to each occurrence of captured elements. Like, `:(i) = i + foo$ * (foo$ + 1)`. Doesn't that look strange? It is even possible to mix two variants of captures like `:(i) = i + foo$ * (foo&$* + 1)`, and it's not entirely obvious to me what will happen to `foo$` when `foo&$*` is updated. Treating these "upvalues" as a sort of an implicit structure (e.g. `$.foo`) is much more consistent, and a prefix form `$foo` can be regarded as its shorthand.
One thing I've noticed recently is that pretty much no language has a good way to simultaneously define a nested structure and assign that structure a name "for later reuse".
For example -- suppose I'm dealing with some serialized data structure that come from some external system. Very likely the data model behind this value involves "nested values" which have themselves have some type of which might be reused in multiple places by that external system.
When the goal is to just solve problems -- the approach i like to take is to focus on the values i want to consume and produce -- which might themselves contain lots of nested types each with some amount of reuse ...
I'd really like a language feature that supports simultaneously defining a type where it's relevant within some other data structure _and also allows_ giving that embedded thing a name for independent reuse ...
I wonder if this postfix $ syntax is related to that use case at all ...
(... this comment a speculation based on names of things only without even reading the whole article ...)
The priorities of a programming language syntax are to be readable first, consistent second.
When it comes to syntax that is used more frequently then the importance of readability increases, and the importance of consistency drops, because people will become familiar with the syntax through frequency of use, so there is no need for them to be guided by consistency. Yet they will be reading the code more often.
When it comes to syntax that is used infrequently then consistency is of more importance because you want users to be able to intuit the syntax. Since it will be infrequently used, the readability is of lesser impact.
The results described in the article talk about weight loss mostly in overweight and obese individuals. The other health benefits are improved blood sugar regulation and insulin sensitivity when eating in the morning rather than at night.
The book “How Not to Diet” by Dr. Michael Greger has a section about this, referencing similar studies.
I do like the ideas of webapps - that webapps can connect other services together or able to create 1 platform for "every" device.
Ah, The Platform.
The web development ecosystem is constantly evolving because The Platform is also constantly evolving.
I’m not saying that all of the churn is strictly necessary or what it’s not overwhelming, especially to beginners, and especially in hindsight.
The churn is in response to the fact that managing a development ecosystem for The Platform is a hard and impermanent problem to solve.
New solutions come about to address the complexity, but those have their own complexity that will eventually be addressed by another new solution. This can be frameworks and libraries, languages and tools, or alternative “platforms” altogether.
The reality is, most of the solutions available today are fine in their own respects. Plenty of real, production software is built on these technologies, even the “outdated” ones.
Try out some solutions. Pick one that clicks with you. Build your thing. You’ll learn valuable concepts. A lot of it will be transferable or analogous to other solutions you encounter in the future.
