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

371–380 of 539 posts

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

#371

Post by rwmj »

lillecarl wrote: post #280
jameshart wrote: post #252

> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12 Frink? Frink ? This Visual Basic erasure can not stand. The #-delimited date literal syntax has been found all over the VB family: Visual Basic, VBA, VBScript, and it persists to this day in Visual Basic .NET. Of course, being a VB syntax, it's completely cursed. You can put # 01/05/2023 # in a VB file, and what date…

We don't have to follow locale, we could just force ISO 8601 and there won't be any ambiguity.

Yeah, but this is Windows we're talking about. Even the SCHTASKS program (kind of like /usr/bin/at) takes a date which is locale sensitive, making it absolutely useless for scripting. Check out this answer to a question about how to use it: https://stackoverflow.com/a/18730884

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

#372

Post by kwhitefoot »

rwmj wrote: post #153
masklinn wrote: post #135

Earlier quoted context omitted.

> I don’t know if they also allow it for hex numbers. They do e.g. Python >>> 0x_ab_cd_01_23 2882339107 or >>> 0b_0010_0100 36

Even C these days, although they chose ' instead of _ :-(

My guess is that they did that because there are real human languages where ' is used as a thousands separator.

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

#373

Post by jbverschoor »

lolinder wrote: post #253
unnouinceput wrote: post #238

Earlier quoted context omitted.

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…

Not OP, but I'm still confused. Is this assuming that the language is naive in its implementation of string concatenation so it screws up Unicode? I'm just not sure what the syntax has to do with the semantics of string concatenation.

I’m even more confused now

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

#374

Post by blackbear_ »

ddejohn wrote: post #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}

I was really disappointed when they removed support for argument unpacking. It was just so useful, especially in lambdas, for example

    Mdist = lambda (x1,y1),(x2,y2): abs(x1-x2)+abs(y1-y2)
    
    p1,p2=(1,2),(3,4)
    
    Mdist(p1,p2)  # 4

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

#375

Post by SebastianKra »

IIsi50MHz wrote: post #297
xigoi wrote: 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.

Except I find the concept of state "doing something with" other state unhelpful.

Why is bar working with baz and not baz working with bar?

I struggle with this in Unity:

    Player.collect(PickUp) // this?
    PickUp.boost(Player)  // ...or this?
Instead, the code should describe the interaction between the two units of state:

    onCollide(Player, Pickup)
If we structure our code like in the last example, it makes sense to weaken the `a.b` vs `b(a)` distinction, and instead use the dot as a kind of pipe-operator.

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

#376

Post by kwhitefoot »

int_19h wrote: post #354
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...

You can implement it in C# too with zero run time cost.

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

#377

Post by qsi »

signaru wrote: post #324
dataflow wrote: post #264

Earlier quoted context omitted.

I'm fine with an array type that supports this, but not as the default. I've been bitten in the past by code that ran error-free while giving incorrect output due to this feature suddenly making the indexing valid. I'd prefer it to be opt-in somehow so that the default behavior for negatives is invalid, not silently wrong yet valid behavior.

Matlab has the opposite where your syntactically valid but mysteriously non-working code suddenly has a large array. EDIT: On the other hand, I think Matlab's array(end - number) indexing syntax is a good compromise of convenience and less error prone explicitness.

You can also overload end in Matlab for your custom classes as it's actually a method.

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

#378

Post by randomdata »

int_19h wrote: post #344
randomdata wrote: post #306

Earlier quoted context omitted.

Interestingly, there was once a solid effort to add a try operator to Go. While the proposal was quite well received, upon closer inspection it was realized it would be essentially useless in the real world as, given how the rest of the language works, you almost never would want to simply early return with the value received. The data revealed that the vast majority of the code in the wild that the syntax sugar woul…

In Rust, when you use `?`, it includes a step to convert the error type of the expression it was used on into the (possibly different) error type that the current function returns. So if you need to map low-level errors to high-level ones in a consistent way, you'd just do it once when defining that error type.

Which too requires the language to have a 'the producer is always right' over a 'the customer is always right' design, which Rust does. It all works well when the language is designed for it, but it has to be there at the macro level. Definitely not a 'microfeature'.

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

#379

Post by LandR »

pgorczak wrote: post #217
wging wrote: post #28

Earlier quoted context omitted.

Tail call optimization can get you that, too. If you've written Scheme and/or gone through SICP you might be familiar with this: you write a recursive function, with the recursive function call as the last thing the function does ('tail-recursion'), and the compiler/runtime is able to optimize those recursive calls out rather than consuming one stack frame of space per call ('tail call optimization'). Clojure has loo…

Oh I didn’t know it was kind of a workaround. I do like the fact that loop is not a function though but an expression like if or case. FWIW I think in Clojure you can use “recur” inside functions too to specifically indicate tail call recursion without relying on automatic optimization

> without relying on automatic optimization

I didn't think Clojure had any automatic optimization at all, due to the JVM not supporting it.

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

#380

Post by ivan_gammel »

andix wrote: post #170
ivan_gammel wrote: post #166

Earlier quoted context omitted.

No, but I think that was a good choice. In local code this is great, but in an interface contract being explicit about data type is a virtue.

For interfaces this would obviously not work (there is no implementation). But for class members it would. I think this concept works very well in typescript and F#.

I mean interface not as a language construct, but as a declaration of how module (class, component etc) can be used. You want to see the type in such declaration, not to infer it based on implementation details.
Post reply on HN