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

331–340 of 539 posts

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

#331

Post by lelanthran »

feoren wrote: post #216
tester756 wrote: post #158

Earlier quoted context omitted.

if it works on literals only, so a[x] doesnt work if x is negative, then ok. otherwise seems like an errors that are hard to spot.

This is such a weird take to me. You're saying: I want to add a rule, where this structure responds to a request in a certain way, based on how the programmer wrote the request in the calling code. Layer upon layer upon layer of weird, janky, edge-case, pseudo-rules, with no consistency, no clear mental model; an absolute nightmare of a programming language. No longer can you possibly intuit what a[-1] really means,…

> This is such a weird take to me.

TLDR: Not that weird. If it is something that is almost certainly going to fail code-review, then may as well let the compiler fail it.

Long:

Just because I want only literals allowed someplace, or only values allowed in other places is not even close to weird.

Most places, code review won't let a function call like `foo(true, false, true, false, true)` through, because the potential for errors is so high and the readability is low.

With this take I can see code review easily getting into the weeds for each `bar[x]` to determine if x will wrap around, while letting `bar[4]` through because it is clear it will not.

Right now, with most languages, we simply let `bar[x]` through because if it is out of bounds it will throw an error/panic/etc. I think it can only silently return wrong data in C and C++.

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

#332

Post by makapuf »

WalterBright wrote: post #302
nicoburns wrote: post #91

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.

D's approach would be: 0xde_ad_be_ef_00

Wouldn't endianness interfere with this notation and the preceding one?

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

#333

Post by lelanthran »

btown wrote: post #131

> [In Chapel] there’s the config keyword. If you write config var n=1, the compiler will automatically add a --n flag to the binary. As someone who 1) loves having configurable program, and 2) hates wrangling CLI libraries, a quick-and-dirty way to add single-variable flags seems like an obvious win. Letting people define configurable variables at their call site is incredibly valuable, even if you don't have compile…

> Sometimes, you don't need language support if you have some clever distributed-systems thinking :)

I think you may have outwitted yourself here; I know what that looks like because I've done it so many times in the past :-)

I'm afraid your solution is not distributed-system safe, as a different bootup order of the nodes[1] in your system would result in a different config value for that key. And, at some point, your nodes are going to come up in a different order.

[1] Nodes == instances of your code that run.

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

#334

Post by throwaway4good »

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…

Initializing at what type and value?

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

#335

Post by int_19h »

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…

A VB date literal is and always has been locale-independent. Originally, they did make the mistake of making it always US-style, M/D/Y. VB.NET added more sane formats such as YYYY-MM-DD.

Now if you tried to convert a Date value to String at runtime, yeah, that would use the current locale. That was a constant source of bugs in VB6 apps running on non-US locales (including, famously, at least one Microsoft installer).

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

#336

Post by kgeist »

ilyash wrote: post #307

Comments Section In Next Generation Shell I've experimented by adding section "arbitrary comment" { code here } and this is staying in the language. It looks good. That's instead of # blah section - start code here # blah section - end Later, since NGS knows about sections, I can potentially add section info to stack traces (also maybe logging and debugging messages). At the moment, it's just an aesthetic comments an…

C# has #region/endregion

They are foldable in IDEs

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

#337

Post by int_19h »

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…

FWIW the implicit result variable is as old as FORTRAN and ALGOL, although the common practice then was to name it the same as the function. Delphi is one language that inherited that (via Pascal) but renamed it to Result, although I don't know whether it originated there, or whether Nim picked it up from Delphi.

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

#338

Post by lelanthran »

vbezhenar wrote: post #326

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.

> 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 uppercase in the rest of the identifier? Then lines like `if MySubRoutine()` is easily parsed as `if My Sub Routine`, and `MyVarType MyVarName;` becomes an easily parser `My var name My var type;`.

Looks harder to read than the usual camelCase, kebab-case and PascalCase identifiers though.

[1] I ask because I'd like to do something like this when writing a program that comes with it's own language for the end-user to use to enhance the program.

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

#339

Post by int_19h »

jdmichal wrote: post #271
ilyt wrote: post #259

Earlier quoted context omitted.

you can do func sum(nums []int) (result int) { for _, n := range nums { result += n } return } and it will work same as if you would do return result As for omitting return entirely I hated it in every language where I saw it. It just feels wrong to not have return in functions that return stuff

I think missing `return` works if the language is designed around everything being expressions, so the function is just written as a single expression. I agree that in procedural type paradigms I like having the `return` keyword over things like "return the result of the last expression".

This case is a bit different - omitting the return simply returns the implicitly declared result variable, which makes perfect sense.

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

#340

Post by Too »

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}

Maybe more obvious, it also works the other way around. Saving you from doing [head] + body + [tail] or keeping copies of temporary arrays manipulated with append and extend.

    arr = [head, *body, tail]
Same with dictionaries, often very useful when you need to include **os.environ with modifications into a subprocess.
Post reply on HN