Microfeatures I'd like to see in more languages • Hacker News Board

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

#351

Post by dima_vm » Fri, Jan 06, 2023, 7:42 AM UTC

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 three features, the code may look like that:

    routing {
        static("/statics") {
            files("css")
        }
        get("/foo") {
            call.respondText("Hello world!")
        }
    }

So you can make a config-looking file which is just pure Kotlin, with static type checking, autocomplete, suggestions, "this" etc.

It's so damned, I'm surprised author didn't mention it.

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

#352

Post by int_19h » Fri, Jan 06, 2023, 7:47 AM UTC

tlb wrote: 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…

Some languages use ~ for negation; wasting it (and other common chars) on bitwise ops is a waste in most languages that don't specifically target bit twiddling.

That said, have you considered making this outright illegal without explicit parentheses? I actually wish that more languages would require that any sequence of operators has the same precedence throughout; i.e. a+b*c would also be illegal. It's always a pain to remember the exact precedence rules, especially since they're not consistent across PLs, so I'd prefer any expression that is ambiguous to be explicitly disambiguated.

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

#353

Post by feoren » Fri, Jan 06, 2023, 7:49 AM UTC

recursive wrote: post #242

_a_a_a_ wrote: post #180

Earlier quoted context omitted.

What 'mod' is for, innit.

In c# -1 % 2 == -1. Doesn't help.

It's a little verbose and can probably be reduced, but "((x % m) + m) % m" always works. Although it's probably not better than a check if x I do think it's quite odd and frustrating that modulo can return negative numbers and I don't really get the reasoning there, but there's probably a good reason I don't know about.

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

#354

Post by int_19h » Fri, Jan 06, 2023, 7:55 AM UTC

armchairhacker wrote: post #281

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

They can be implemented as a library C++ thanks to templates and user-defined literals, and there's a proposal to add them to stdlib based on one of the existing implementations: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p19...

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

#355

Post by _a_a_a_ » Fri, Jan 06, 2023, 7:55 AM UTC

int_19h wrote: post #341

pavon wrote: post #206

Earlier quoted context omitted.

A nice alternative I've seen is that negative index is an error, but there is special syntax for indexing from the back like array[end], array[end-1], array[end-n], where n is a (positive) variable. Likewise, end can be used in range definitions like array[5:end]. Julia and Matlab both have this.

C# has a very nice approach to this: indices aren't simple numbers, but values of type Index [1], which store both the offset and the direction, and can be implicitly created for plain ints. When you do want to index from the end, you use the unary ^ operator to create a reverse index. Thus, you can write things like a[^1] or a[0..^1]. But, more importantly, it means that any custom collection type can define an inde…

That's a lot of machinery which I feel is going to benefit relatively few people and cases. I suppose I should learn it just in case but my suspicion is that MS is adding extra stuff which they hope people will use which will act as a lock-in to C#. Ergo the benefit of this is to MS not to the end user ISTM.

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

#356

Post by lelanthran » Fri, Jan 06, 2023, 7:55 AM UTC

iwsk wrote: post #46

davidhyde wrote: post #31

> You can write # 2001-08-12 # to mean the date 2001-08-12, instead of writing something annoying like Date(2001, 8, 12) I like this article but oh man dates just trigger me. Such a missed opportunity to use an unambiguous date example like 2001-08-13

It would have been unambiguous in a world where we all agreed that both months and days start at 0 :)

> It would have been unambiguous in a world where we all agreed that both months and days start at 0 :)

How so? Would 2021-08-12 mean month 08 or month 12? It doesn't matter if it starts from zero, it still looks ambiguous to me.

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

#357

Post by feoren » Fri, Jan 06, 2023, 7:56 AM UTC

ablob wrote: post #220

feoren wrote: post #209

Earlier quoted context omitted.

Right, the calling code needs to handle its own integer overflows, of course. And if your circular array has a size other than a power of 2 you can get only a partial enumeration in the cycle that includes overflow. Sure. But are you really indexing an array of unknown size with a uint8? It's really impossible that there might be more than 255 things you ever care about? No. Everyone who is using a uint8 to index arr…

The point made is independent of the integer size and I think we should assume in good faith, that uint8 was chosen for the purposes of an example.

Um, maybe, but then his example is sixteen million times worse than reality! If I argued against some technology by showing how bad it would be if it were sixteen million times worse, that's just not a very good argument, is it?

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

#358

Post by int_19h » Fri, Jan 06, 2023, 7:57 AM UTC

_a_a_a_ wrote: post #355

int_19h wrote: post #341

Earlier quoted context omitted.

C# has a very nice approach to this: indices aren't simple numbers, but values of type Index [1], which store both the offset and the direction, and can be implicitly created for plain ints. When you do want to index from the end, you use the unary ^ operator to create a reverse index. Thus, you can write things like a[^1] or a[0..^1]. But, more importantly, it means that any custom collection type can define an inde…

That's a lot of machinery which I feel is going to benefit relatively few people and cases. I suppose I should learn it just in case but my suspicion is that MS is adding extra stuff which they hope people will use which will act as a lock-in to C#. Ergo the benefit of this is to MS not to the end user ISTM.

All the indexed sequential collections in the standard library use it, for starters, and those collections are in turn used by the majority of users.

OTOH a convenience feature as a lock-in is hard to believe.

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

#359

Post by plucas » Fri, Jan 06, 2023, 8:00 AM UTC

dima_vm wrote: post #351

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?

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

#360

Post by melagonster » Fri, Jan 06, 2023, 8:02 AM UTC

david2ndaccount wrote: post #293

gnuvince wrote: post #287

Earlier quoted context omitted.

I like D's approach of using `d[$]` to get the last element, `d[$-1]` to get the element before last, etc.

`$` 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.