I really just want every language to support operator overloading.
Yes, `matrix * vector` rather than `matrix.VecMult(vector)`
Microfeatures I'd like to see in more languages
311–320 of 539 posts
Re: Microfeatures I'd like to see in more languages
#312I really adore Python's iterable- and keyword-unpacking operators (*some_iterable, **some_mapping): arr = [0, 1, 2, 3, 4] head, *body, tail = arr # head=0, body=[1, 2, 3], tail=4 head, *rest = arr head, *_, tail = arr *_, tail = arr first, second, third, *rest = arr foo = {"a": 1, "b": 2, "c": 3} bar = {"b": 9, "x": -1} {**foo, **bar} # -> {"a": 1, "b": 9, "c": 3, "x": -1}
why bother with the distinction between one * and two *?
in javascript the … operator neatly does both
Re: Microfeatures I'd like to see in more languages
#313> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12 Frink? Frink ? This Visual Basic erasure can not stand. The #-delimited date literal syntax has been found all over the VB family: Visual Basic, VBA, VBScript, and it persists to this day in Visual Basic .NET. Of course, being a VB syntax, it's completely cursed. You can put # 01/05/2023 # in a VB file, and what date…
> what date it represents will depend on what locale it's.. compiled? executed? evaluated?
oh VB. you were so close to perfection. never change.
Re: Microfeatures I'd like to see in more languages
#314> roughly three classes of language features [...] 3. Quality-of-life features that aren’t too hard to add I'd regrettably add another class, quality-of-life features which you'd have hoped weren't too hard to add, but because of past choices, now are. Examples: Adding javascript-like dots a.b.c for Julia Dict's a[:b][:c] would conflict with "wasn't intended to be public but has been" Dict implementation fields, like…
You can build method access in Ruby trivially enough but you will forever be explaining to users which node.class isn't node[:class]. And now every method added to that Hash/Dict-like object is a breaking change because someone somewhere could have used that already to access a key.
The { a,b | } syntax is also still ambiguous with hash literals, unless you require that | to be there, and that looks like it gives the parser a whole lot of look-ahead work to do in order to distinguish hashes from lambdas.
Re: Microfeatures I'd like to see in more languages
#315Comments Section In Next Generation Shell I've experimented by adding section "arbitrary comment" { code here } and this is staying in the language. It looks good. That's instead of # blah section - start code here # blah section - end Later, since NGS knows about sections, I can potentially add section info to stack traces (also maybe logging and debugging messages). At the moment, it's just an aesthetic comments an…
You can do something similar in JavaScript
> const love = "love"; > { // Section > console.log(`What is ${love}`); > }
Re: Microfeatures I'd like to see in more languages
#316Re: Microfeatures I'd like to see in more languages
#317Comments Section In Next Generation Shell I've experimented by adding section "arbitrary comment" { code here } and this is staying in the language. It looks good. That's instead of # blah section - start code here # blah section - end Later, since NGS knows about sections, I can potentially add section info to stack traces (also maybe logging and debugging messages). At the moment, it's just an aesthetic comments an…
You can do something similar in JavaScript > const love = "love"; > { // Section > console.log(`What is ${love}`); > }
Not the same ergonomic.
The language doesn't "understand" it's a section (no opportunities listed in the original comment).
Re: Microfeatures I'd like to see in more languages
#318I really adore Python's iterable- and keyword-unpacking operators (*some_iterable, **some_mapping): arr = [0, 1, 2, 3, 4] head, *body, tail = arr # head=0, body=[1, 2, 3], tail=4 head, *rest = arr head, *_, tail = arr *_, tail = arr first, second, third, *rest = arr foo = {"a": 1, "b": 2, "c": 3} bar = {"b": 9, "x": -1} {**foo, **bar} # -> {"a": 1, "b": 9, "c": 3, "x": -1}
why bother with the distinction between one * and two *? in javascript the … operator neatly does both
Technically, `...` acts as either the spread or the rest operator, depending on the location. I recall there was an initial impression of intimidation among people who were familiar with ES5 syntax when trying to adopt to these new features because of this.
On the other hand, I'm fairly certain that having to visually disambiguate between `` and `*` and remembering which did what would have gotten a similar reaction.
Re: Microfeatures I'd like to see in more languages
#319Comments Section In Next Generation Shell I've experimented by adding section "arbitrary comment" { code here } and this is staying in the language. It looks good. That's instead of # blah section - start code here # blah section - end Later, since NGS knows about sections, I can potentially add section info to stack traces (also maybe logging and debugging messages). At the moment, it's just an aesthetic comments an…
I sometimes do something like:
var foo string
{ // Do stuff
// ...
foo = "..."
}
{ // Other section...
}
Of course, your language will need to have block scope, or at least blocks.