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

301–310 of 539 posts

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

#301

Post by whartung »

rwmj wrote: post #137

Perl's if and unless operators, which can also be postfixed, eg: die "can't be negative" unless $i >= 0; Perl is full of usability features, like for reading input, inline literate coding annotations, implicit $_.

Can’t say this was the source but it harkens back to DEC BASIC-PLUS on the PDP.

It has the concept, I think, of “statement modifiers”.

You could do things like:

    S=S+A[I] IF A[I]>5 FOR I=1 TO N
It always read really well.

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

#302

Post by WalterBright »

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

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

#303

Post by WalterBright »

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

D has had these for a long time.

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

#305

Post by hinkley »

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…

But is that December 8th or August 12?

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

#306

Post by randomdata »

jamincan wrote: post #164

For rust, it is probably the try (?) operator. Fundamentally, it's just syntax sugar for a match statement with an early return in the Error or None cases, but it really improves the ergonomics of dealing with Result and Option types.

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 would replace returned something else.

So while it is indeed a nifty feature if the rest of the language is also designed for it, it's not something that is easily tacked on to a language that is not.

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

#307

Post by ilyash »

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 and (I think) easily skip-able code section when reading.

Symbols

I've decided not to have symbols in NGS. My opinion (I assume not popular) is that all symbols together is one big enum, instead of having multiple enums which would convey which values are acceptable at each point.

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

#308

Post by lamontcg »

timmaxw wrote: post #260
happyrock wrote: post #3

I have long wondered why Ruby's symbols aren't in every language.

Personally, I found Ruby's symbols to be a source of bugs because they can easily get mixed up with strings. The article gives the example of dict[:employee_id]. But what happens if you serialize "dict" as JSON, then parse it again? The symbol :employee_id will be silently converted to "employee_id", which is treated as a different dict key from :employee_id. I found it was easy to lose track of whether a given dicti…

Yeah symbols are terrible and they lead to using Mashes or "Hashes with indifferent access" to attempt to allow both syntax. This helps with round tripping to JSON and back and getting consistent access either way, but values are still not converted. And values shouldn't be symbolized from JSON which means round tripping through JSON typically converts symbols into strings.

It would be a lot easier if symbols had been just syntactic sugar for immutable frozen strings so that :foo == "foo".freeze == "foo" would be true.

And under the covers these days there is very little difference. It used to be that symbols were immutable and not garbage collected and fast. And that strings were mutable and garbage collected and slow.

These days symbols are immutable and garbage collected and fast and frozen strings are immutable and garbage collected and fast (and short mutable strings are even pretty fast).

Symbols as a totally different universe from Strings I would consider to be an antipattern in language design. They should just be syntactic sugar for frozen strings if your language doesn't already have frozen strings by default.

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

#309

Post by lamontcg »

jonasenordin wrote: post #232

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

Ruby having anonymous functions being defined like { |args| } and for no arguments you can drop the || entirely. Rust's |args| { } with || { } being mandatory for no args removes the ambiguity in parsing.

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

#310

Post by KMag »

barrkel wrote: post #22
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…

Implicit result var is also in Delphi, as Result. The original Pascal is to assign to a variable with the same name as the function, which looks kind of odd, and is overloaded in recursive scenarios, since functions with no args don't need parens to invoke.

The last I used Matlab, it also required you to assign your return value to a variable with the same name as the function. Presumably Gnu Octave also has the same feature.
Post reply on HN