Live data from Hacker News

Microfeatures I'd like to see in more languages

buttondown.email

491–500 of 539 posts

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

#491

Elixir’s testing library uses meta programming to show the code that fails and what the values were at both sides of a comparison. IE a = 1; b = 2 assert a == b Will fail with error like: Assertion failed, a == b Left is 1 Right is 2 So you don’t have a bunch of assert-functions; you just assert anything and it will spit out a decent error.

This is one that I like a lot. Years ago (1997 timeframe) I had implemented it in a Java compiler, and a few years later in a Java library (https://github.com/oracle/coherence/blob/4e6e343e1ffd9bbfea3...) that would create an exception on the assertion failure and parse its stack trace to find the source code file name, and read it to find the text of the assertion that failed, etc. so it could build the error message ...

In Ecstasy, we built the support directly into the compiler again:

    val a = 1;
    val b = 2;
    assert a == b;
Produces:

    IllegalState: a == b, a=1, b=2

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

#492
post #406

Earlier quoted context omitted.

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

I don't know why teenagers insist on taking a negative work and making it positive, especially when teenagers don't like adding emphasis to words so you have no idea whether they think it's good or bad. Not that I was completely innocent of this at that age. /Rant.

That's so sick.

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

#493

One of the best truly micro features I've seen recently (can't remember which langauge unfortunately - it wasn't a mainstream one), is general binary literal syntax of the form: 0x[de ad be ef 00] So much nicer than the usual condensed format. And I think it'd be valid syntax in any language that allows binary integer literal.

It's an interesting mix of "hex" and "array" into one syntactic composition. I do kind-of like it.

Here's how we ended up supporting byte strings (# prefix) in Ecstasy, in this case multi-line:

    Byte[] bytes = #|12 34 56
                    |78 9a BC
                    |dE f0
                   ;

    console.println($|bytes=
                     |{bytes.toHexDump(4)}
                   );
Which prints:

  bytes=
  00: 12 34 56 78 .4Vx
  04: 9A BC DE F0 .¼Þð

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

#494

I'm partial to for-else-loops. They fit perfectly into languages with compound expression (produce a value from a break in the loop or from the else block). They don't come up that often, but when they do they're really the best solution.

I hate the Python syntax using "else" for this, but I love the feature.

I've often wanted both a "then" and an "else" from both for and while loops. The "then" would be for a successful completion (no break), and the "else" would be for when the loop doesn't even run a single iteration.

But that didn't make it into our "language budget", unfortunately. It's easy to implement, but hard to argue for when it doesn't get used often

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

#495
post #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.

It reminds me of Scala too, but I have no idea which started when. And of course both could have come up with this fairly independently. (After all it is the norm in functional style.)

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

#496

I really just want every language to support operator overloading.

just allow nice infix functions :)

(which is allowing nice postfix ones with currying)

Scala does it pretty well. and nowadays finally the function names don't require a PhD in ancient Egyptian hieroglyph decoding.

so requiring alphanum names for functions is pretty important imho. (sure it's okay if it's just a stern lint warning and the developer has to opt-in. but searching for iteratee is easier than searching for \∆>> or whatever.)

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

#497

Elixir's sigils are amazing. There are date sigils that allow you to do what the OP does: ~N[2023-01-01 12:00:00] But you can also define your own sigils to create new "custom syntax" for almost any struct. Kind of a special case of reader macros, I guess. Very convenient.

Swift has the expressibleby Type literal series of protocols for this. For example you could write an extension on Date to add initialization from a string: extension Date: ExpressibleByStringLiteral { public init(stringLiteral value: String) { // parse the string here. } } You can then do things like: let happyNewYear: Date = “2023-01-01 12:00:00” There are a protocols for all literal types. For example, you could i…

It's "funny" that things that are considered an anti-feature and something that needs to be avoided by all means in one place is considered a great feature in another place. This points strongly in the direction that there is no logic behind such "considerations".

What you just showed was a implicit conversion from String to Date. Something you would get beaten up for in Scala land.

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

#498

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…

> 1. Lambda functions can be defined with {}.

Directly "stolen" form Scala.

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

Just a irregular syntax quirk that tries to get around the fact that Kotlin does not support multiple parameter lists, like the language where most Kotlin features come form, Scala.

> 3. Interfaces that require only one method can be implemented on-side with a lambda function (i.e. {} syntax for no-param function).

That doesn't have anything to do with Kotlin. That's Javas SAM (Single Abstract Method) feature.

> I'm surprised author didn't mention it.

The author seems not to know any Scala. Otherwise the lists would show mostly only Scala features… ;-)

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

#499
post #495
post #405

Earlier quoted context omitted.

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

It reminds me of Scala too, but I have no idea which started when. And of course both could have come up with this fairly independently. (After all it is the norm in functional style.)

Almost all Kotlin features are Scala rip offs.

Kotlin was started even as just a poor Scala clone. (Because JetBrains didn't manage to get a working Scala plugin for their IDE, so they thought it would be simpler to create their own "simpler" version of the language).

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

#500
post #413

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…

Kotlin's features are amazing for designing DSLs but I think your code sample uses more than just the 3 points you mentioned. Specifically the `call.respondText(..)` part. I assume that in this example the second argument to the `get` function is actually a "lambda with receiver", which means that the lambda executes with another object as the receiver (and that object is bound to "this" inside the lambda block), whi…

Isn't it cool that you can't know what the code is actually by just looking at it? /s

Kotlin's scope injection is one of the most terrible "features" ever invented. It's dynamic scoping on steroids!

But dynamic scoping was long ago deemed a horrible bug and never ever made it again into any new language.

Post reply on HN