Live data from Hacker News

Microfeatures I'd like to see in more languages

buttondown.email

521–530 of 539 posts

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

#521
post #138

Earlier quoted context omitted.

Also on a function? var getDate() { return „no date“; }

That is often considered undesirable because it makes code less clear and compilation errors inscrutable. For instance the rust developers consciously decided to remove that from the language, named functions must be fully typed.

Static type inference is "fully typed".

  def getDate = "no date"
That defines a method `getDate` with the type `() => String` in Scala.

The type is statically know, of course.

But it's recommended to use explicit return types for public methods. This helps preventing breaking public API by refactoring the implementation of a method.

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

#522

More sugar for reflection: class Foo { @Max(10) int bar; @NonNull String name(); } var field = @Foo::bar; var max = @Foo::bar.Max; var method = @Foo::name; var foo = new Foo(); var name = method(foo); var bar = foo.field;

Just use a dynamic language like JS if you like code like that.

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

#524
post #277

this is usually a style thing not an enforced syntax and maybe a hot take but I actually really like leading commas in comma-delineated lists (like Elm and Haskell). Makes changing the order of things really convenient

Even better would be to get rid of this annoying syntax noise.

Commas in multi-line lists have no use besides making trouble in refactorings and diffs.

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

#525
post #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 fo…

Scala does a lot right here, but it's supper annoying with its arbitrary limitations for how you can name your methods.

If I want a method called `U+1F602`¹ it's not the business of the language to judge that.

---

¹ the actual glyph, which gets filtered out here, also for no reason

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

#526
post #6

I wrote a small DSL for easy compilation to SQL that included some similar features. It included datetime literals, but they were specified as just a string prefixed with "d". d'2020-02-20' I also tried to make it so that every comparison had both english and symbol representations, a range syntax, and an approximation/match comparison (e.g. "=~", "!~") which could work with both floating point numbers and strings pr…

Comparing floats is not a great idea, though. That's a foot gun.

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

#527

About kebab-case identifiers. What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. All those space imitations, whether they're dashes, underscores or camels - they're just imitations. Nothing compares to real spaces. If anything, underscores are closest ones, if you ask me.

That's a terrible idea given the fact that code is processed by human brains in a symbolic way, and not like a (western) written language.

https://news.mit.edu/2020/brain-reading-computer-code-1215

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

#528

Earlier quoted context omitted.

> What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. What would this look like, though?[1] How would you solve the problem of adjacent identifiers vs a single identifier which has spaces? Maybe having identifiers, and only identifiers, starting with a uppercase letter with no u…

Well, I would imagine that it requires designing a language which ordinary does not allow adjacent identifiers. Of course keywords must not be allowed as part of identifiers (or there should not be no keywords at all like with Lisp). Just an example of my head that I didn't think really much about: function print person (p: person) { var full name = p.first name + p.last name; if p.middle name != "" { full name += p.…

That's completely unreadable!

I can't "parse it" by looking at it, and a computer would have even more trouble doing so.

How do I tokenise something like `full name += p.middle name`?

Maybe as `(full) (name +=) (p.middle) (name)`? Or is it `(full) (name) (+= p.middle) (name)`?

How about `print person(c)`? Is it the call of the `print` function with `person(c)` as argument?

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

#529

I love all the sugar of Kotlin, but there is one thing I miss, and it is the indexing of arrays of Python when pulling out part of an array.

Kotlin is so close on so many things, but then keeps messing up. arrayOf(1, 2, 3) - why not [1,2,3]? emptyArray() - why not []? mapOf("key" to "value") - why not {key => value}? These are all solved problems. Why would they make up some harshly suboptimal syntax?

Because there are more than three collection types (Sets, Arrays, Maps) in rich static languages.

The ugly Kotlin syntax is of course just there to look different to Scala, where you would have:

  Array(1, 2, 3)
  Array.empty
  Map("key" -> "value")

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

#530
post #46

> 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 :)

Yeah, sure, because normal people count form zero…

Have you actually ever watched people counting things?

In a sane world the offset based counting (zero bases) would have never surface (besides in very specific and seldom circumstances).

Also it's a shame that the C languages started to call offset "index" (and there is not even a proper index operator!).

Post reply on HN