Live data from Hacker News

Microfeatures I'd like to see in more languages

buttondown.email

291–300 of 539 posts

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

#291
post #236

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.

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

In Haskell, if all the functions in the pipeline are pure, I'd probably write that as

    wood
    & measure 12
    & cut 40 WZ
    & sand 220
    & paint Red
See https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-...

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

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

NASA reference: https://nssdc.gsfc.nasa.gov/nmc/spacecraft/display.action?id...

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

#293

Negative array subscripts. So a[-1] means the last element of an array, a[-2] means the second last, and so on.

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

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

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

APL uses ¯ for negative numbers. - is a ambivalent function (it can work as a monadic or dyadic function)

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

#296
If unit testing makes the cut, then I think standardized documentation and doctests should be included also. Python (string literal at the beginning of a class/function), C# (structured comments) and Rust (doc attributes) are three different, valid ways of adding this to the language.

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

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

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

To me, these are "Tell bar's foo to do something with baz." and "Tell foo to do something with bar and baz.". So being 'able' to flipflop the syntax is at least temporarily semantic'ly confusing.

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

#298
I really adore Python's iterable- and keyword-unpacking operators (*some_iterable, **some_mapping):

    arr = [0, 1, 2, 3, 4] 
    head, *body, tail = arr # head=0, body=[1, 2, 3], tail=4
    head, *rest = arr
    head, *_, tail = arr
    *_, tail = arr
    first, second, third, *rest = arr

    foo = {"a": 1, "b": 2, "c": 3}
    bar = {"b": 9, "x": -1}
    {**foo, **bar}  # -> {"a": 1, "b": 9, "c": 3, "x": -1}

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

#299

Earlier quoted context omitted.

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

Just so you know, Lua's concatenation operator is ".."

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

#300

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

Which will also cause an array-bounds error. So you're covered!
Post reply on HN