Live data from Hacker News

Microfeatures I'd like to see in more languages

buttondown.email

401–410 of 539 posts

Re: Microfeatures I'd like to see in more languages

#401

# Function Shorthand #### I like how functions in js can be `arg => result`. In F# I have to do `fun arg -> result` with the `fun` keyword. It makes sense since `MyArgType -> MyResType` is a type signature in f#, but I feel like the compiler can just check if the arguments are references to types or are argument bindings. # Multiline Lists/Arrays #### I like how F# doesn't require delimiters for multiline lists. So I…

Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issu...

Re: Microfeatures I'd like to see in more languages

#402

> 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…

But is that December 8th or August 12?

>> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12

> But is that December 8th or August 12?

I didn't even think YYYY-DD-MM is a possibility. Maybe I can grant 08/12/2022 is ambiguous and so is 08-12-2022 but can we please agree YYYY-MM-DD can't have variations?

Re: Microfeatures I'd like to see in more languages

#403
post #312

Earlier quoted context omitted.

why bother with the distinction between one * and two *? in javascript the … operator neatly does both

Python has keyword arguments to functions. In that context, a single star packs or unpacks a list of positional arguments and a double star packs or unpacks a dictionary of keyword arguments.

To complete the description, dictionaries are iterable by key only by default[1], so *dict would be ambiguous if it could splat both.

[1] a misfeature, IMNSHO.

Re: Microfeatures I'd like to see in more languages

#404
post #4

My favorite is uniform function call syntax. In several languages (Nim, Koka, D, …), you can always write bar.foo(baz) instead of foo(bar, baz) and vice-versa. Another one from Nim is the implicit result variable. Instead of having to do this: func sum(nums: seq[int]): int = var result = 0 for num in nums: result += num return result you just do this: func sum(nums: seq[int]): int = for num in nums: result += num It…

I've only seen this proposed as a feature to help with template meta-programming (though it could also make similar sense in any dynamic language). There, it helps if a template can say `t.foo()`, and, with UFCS, can use that template with any t for which either `foo(t)` or `t.foo()` exist. In contrast, in C++ today, a template using `t.foo()` limits its own use only to types that have a foo() method, probably unnece…

I think not introducing UFCSs originally in C++ is one of Stroustrup biggest regrets.

Re: Microfeatures I'd like to see in more languages

#405

Absolutely damned is combination of Kotlin's several features: 1. Lambda functions can be defined with `{}`. 2.`foo(bar, somefunc)` is the same as `foo(bar) somefunc`. In other words, if the last parameter is a function, it can be provided AFTER closing parenthesis. 3. Interfaces that require only one method can be implemented on-side with a lambda function (i.e. `{}` syntax for no-param function). Combined those thr…

All of these were copied from Groovy, in case you didn't know it.

Re: Microfeatures I'd like to see in more languages

#406
post #359

Absolutely damned is combination of Kotlin's several features: 1. Lambda functions can be defined with `{}`. 2.`foo(bar, somefunc)` is the same as `foo(bar) somefunc`. In other words, if the last parameter is a function, it can be provided AFTER closing parenthesis. 3. Interfaces that require only one method can be implemented on-side with a lambda function (i.e. `{}` syntax for no-param function). Combined those thr…

What exactly do you mean by "damned" here?

I am assuming the author is using it as one would use "wicked" (with a positive conotation)?

Re: Microfeatures I'd like to see in more languages

#407

Earlier quoted context omitted.

`$` refers to the length of the array, so `d[$]` is an array-bounds error. `d[$-1]` is needed for the last element, but you can’t do that blindly, you have to check that the length is nonzero or you’ll get unsigned underflow to ulong.max

perl have $d[$#d] represent the index of last element.

$my_properly_named_array[$#my_properly_named_array] doesn't look like QoL.

Re: Microfeatures I'd like to see in more languages

#408

Agree with kebab-case. > Most languages have multiline literals, but what makes the Lua version great is that the beginning and ending marks are different characters. This solves the infuriating “unnestable quotes” problem string literals have, and you don’t have to escape all your literal \s. That paragraph also uses “nestable marks”.

FWIW, Raku and XPath support kebap-case. If you really mean subtraction, you have to add whitespace.

That works, but isn't necessary in Raku. As long as the right side of the hyphen does not start with an alphabetic character, you're good:

my $a = 45; say $a-3; # 42

Re: Microfeatures I'd like to see in more languages

#409

Strongly-typed units and unit literals (e.g. 3mL, 10gal, 15m / 3s = 5m/s) AFAIK F# has these and that's about it

There's a Java compiler extension, Manifold[1], that adds this to Java.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

Re: Microfeatures I'd like to see in more languages

#410
post #286

I might add kebab-case to my current language project. From all the code I've written, I only found a handful of - operators not surrounded by spaces, so that ambiguity wouldn't bite me often. Also, I wish the unary negation operator was more visually salient. `foo * -bar` is very different from `foo * bar`, but it's only a handful of pixels on the screen. I've thought about trying to render it as an em-dash or somet…

I have a similar opinion on using the exclamation point for the NOT operator.

It can be very hard to spot sometimes, especially after an opening bracket - if(!something())

Of course its generally better to try and rename functions or refactor to avoid the negative if possible.

Post reply on HN