Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microfeatures I'd like to see in more languages

buttondown.email

Post reply on HN
Print view View original

231–240 of 539 posts

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

#231

Post by nine_k »

mikepurvis wrote: post #112
whatshisface wrote: post #95

Earlier quoted context omitted.

If you mean without closing parentheses, I think you can also do that in languages like Haskell with non-parenthetical function calls.

I'm not a Haskell user, but my experience with this in the Nix language is a bit mixed. It definitely works sometimes , but then you get a pileup of parenthesis nesting anyway, because the default is greedy and you have to control which functions get which arguments.

Don't $ signs work in Nix the way the work in Haskell?

E.g. https://mmhaskell.com/blog/2021/7/5/function-application-usi...

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

#232

Post by jonasenordin »

Good observations. Actually more important than it looks, I think. All those little helpful things.

Also worth discussing: micro-misfeatures to be avoided when designing new languages. Maybe non-micro-misfeatures, ie the lack thereof, can be considered a microfeature. Like, for example, uniformity.

And I just have to trot out my favorite example: Java import statements do not allow keywords and numbers in package names. So we can't put our Java source code in folders named 'import', 'long', or in paths like '2023/01/'. Great. For no good-enough reason - the syntax would actually be cleaner with a separate package name syntax. (BTW, this could be fixed, I think.)

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

#233

Post by jlokier »

dragonwriter wrote: post #185
krapp wrote: post #181

Omitting parens in a function signature when calling with one or no arguments.

This means you can’t reference the function itself by name without some kind of quoting construct or other circumlocution; also, while the no-arg case might make sense as a special case, if you allow the one arg case, you might as well admit the general case.

The general case adds ambiguity which makes it more of a design choice, rather than an obviously good generalisation.

In the general case of 2 or more comma-separated arguments, is "func a, b" a call with two arguments, or a tuple containing a call with one argument? Feel the same about "x = (func a, b)"? What about when this appears in list syntax like "[x, y, func a, b]", or the argument list of another function like "obj.method(x, y, func a, b)"?

They are easily solvable with a design decision about precedence, but arguably the syntax is a little confusing or worth a warning in all but simple cases.

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

#236

Post by pavon »

whatshisface wrote: post #95
mikepurvis wrote: post #88

Earlier quoted context omitted.

Chaining without nesting.

If you mean without closing parentheses, I think you can also do that in languages like Haskell with non-parenthetical function calls.

It also allows you to invert the order of the calls so they are written in the order they occur. Instead of paint(sand(cut(measure(wood)))), you can write wood | measure | cut | sand | paint, which is easier to read, especially if it splits over multiple lines or has additional arguments:

paint(sand(cut(measure(wood, 12), 40, :WZ), 220), :red)

wood | measure(12) | cut(40, :WZ) | sand(220) | paint(:red)

IIRC you can do that in Haskell as well, but I forget the name of the feature. Many OOP libraries have started to adopt a chained method call style similar to this, but it is nice to be able to do with any function.

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

#237

Post by dunham »

dan-robertson wrote: post #187
4ad wrote: post #15

> Instead of writing 10000500, you can write 10_000_500, or 1_00_00_500 if you’re Indian. I hate this so much. It means I can't grep for a constant.

The funny way I’ve seen this go wrong in practice is a typo like: // we don’t want more than 100m because … quota = 1000_000_000 Where people assume the underscores are in the expected place.

This is why I like the underscores, it's easier for me to see the typo in:

    quota = 1000_000_000
than it is in:

    quota = 1000000000
And also when I'm typing the number, it's easier for me to be sure I got it right when I can count the zeros in groups of three. It's rare that I've needed this, but I've used it in Java a few times in my career.

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

#238

Post by unnouinceput »

jbverschoor wrote: post #132
unnouinceput wrote: post #80

Earlier quoted context omitted.

And that's why all modern languages implement streams/string helpers/string builders. You do not want to actually write strings/manipulate them using "+" (concatenation symbol) in code directly because, in modern Unicode world, it tends to become a point of failure for obscure bugs / a maintenance horror show.

I don't understand the link with parent, nor why + would be bad, besides a) because language is naive about concatenation / allocation, and b) if the language allows / doesn't differentiate between a char 'x' and an integer, bc that would result in an integer addition instead of a concatenation.

If you manipulate strings in code using "+" (string concatenation symbol) from a user input you'd be in a world of hurt where you either do a lot of regex (which is ugly and unmaintainable) or you limit the user input to known characters only (which would be a bad user experience and later on your manager would ask you to lift such constraint anyway because they want to support a new feature from now on). Therefore you use, for example, a stream and simply dump your user input in the stream buffer, as they come, and go with that stream in your code from that point on. This way you're future proof too if your manager wants a new feature to support, as example, Chinese and/or Japanese keyboard

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

#239

Post by robertlagrant »

duped wrote: post #223
robertlagrant wrote: post #150

Earlier quoted context omitted.

You could say the same about a function call or a function that takes an object as an argument - who knows what code lies behind the impenetrable barrier of structured or object oriented programming?

That's actually a feature of encapsulation. The object (ideally) is used to abstract away those details so I don't need to know about them, only how to create the object. Encapsulation is a different feature than reuse. The exception is in languages that use that syntax as a way to implement keyword arguments, but I would still ask people to destructure it in the parameter list or at the top of the function so I can…

But how would you know how to call it if it takes an object as an argument? How different would the process be for looking at a named standard set of arguments?
Post reply on HN