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

Avoid Else, Return Early (2013)

blog.timoxley.com

Post reply on HN
Print view View original

531–540 of 601 posts

Re: Avoid Else, Return Early (2013)

#531

Post by dorgo »

okbake wrote: post #521
xg15 wrote: post #465

Earlier quoted context omitted.

> Same way you move on from heavy OO to dicts/lists. Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them. I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and…

I'm a fan of TypeScript's structural typing for this reason. I can define an interface that describes the shape of a "plain old object" (it's fields and their types), and then write functions that accept/returns an object of that interface. What's great about structural typing is I don't have to explicitly say "create a new object of this type", any object that satisfies the shape of the interface is valid (object li…

Don't you get problems with equal Signatures but different meaning or different scale? Example:

interface SomethingWithAge{ age(); }

class Person{ age(); // age in years }

function classify( SomethingWithAge item ){ if( item.age() p = new Person( 33 ); classify( p ) // prints 'old'

class Message{ age(); // age in milliseconds }

c = new Message( 231443 );

classify( c ); // prints 'old'

Re: Avoid Else, Return Early (2013)

#532

Post by pmarreck »

aiham wrote: post #528
crooked-v wrote: post #453

Earlier quoted context omitted.

And in Javascript, once do-expressions go from a proposal to a common part of the language, this will be a thing: let value = do {if (boolean) { this_value } else { other_value }} ...which is even closer to the Elixir style than JS's ternary operator (which is identical to Java's).

What's the advantage over JS's ternary operator?

I guess it depends on whether "if" is treated as an expression which returns a value, which I don't think is the case due to the fact that I don't think there is an implicit value return in JS (such as in Ruby; the final line in any scope is the value that scope returns; same as in Elixir)

Re: Avoid Else, Return Early (2013)

#533

Post by Const-me »

xg15 wrote: post #465
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Same way you move on from heavy OO to dicts/lists. Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them. I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and…

Right, dictionaries everywhere is a reliable way to slow down every language to the speed of dynamic languages like Python or JavaScript.

My understanding is, by “heavy OO” they mean custom container-like classes implemented by encapsulating a list or dictionary, but exposing non-standard APIs for get/set/erase/replace.

By the OO books that’s the way to go, because object state encapsulation. Practically, exposing raw lists/dictionaries/vectors/iterators at the class API boundary is more flexible because it makes the collection compatible with lots of other code, both in standard runtime and third-party libraries.

Another thing, if the only state that container holds is the collection of items, maybe you don’t need any container class at all. Just write global functions / static class / static methods that directly process lists or dictionaries of these items.

Re: Avoid Else, Return Early (2013)

#534

Post by recursive »

monocasa wrote: post #360
klmr wrote: post #338

Earlier quoted context omitted.

`finally`/RAII doesn’t depend on checked exceptions. It always runs (short of something that aborts the program without unwinding the call stack; and in those cases single-exit won’t save you).

Mixing finally and RAII into the same category doesn't really make sense here. And I'm not saying that finally depends on checked exceptions, I'm saying that pattern is very brittle. You change lower code to throw a new exception, and you change the above code to catch it like you're supposed to, but now the middle code has no idea that there's this new exception and leaks resources. So you end up either having britt…

`finally` doesn't depend on catching any particular errors. If control flow exits its block for any reason, then the `finally` block executes.

Re: Avoid Else, Return Early (2013)

#535

Post by mynameisasecret »

dv_dt wrote: post #482
DonaldPShimoda wrote: post #408

Earlier quoted context omitted.

This is my favorite research quote from a Civilization game (Civ IV, narrated by Leonard Nimoy). I use this as my mantra for all design-oriented aspects of my life now. Or... I try to. Sometimes it's hard not to want to add more haha.

FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".

I learned this as a rule for all Art. Does this mean programming is an Art? (just joking; I know that it Can be).

Re: Avoid Else, Return Early (2013)

#536

Post by sedachv »

WorldMaker wrote: post #511
sedachv wrote: post #492

Earlier quoted context omitted.

> I just have to write these {} things all over the place because every other language is a gramatically bloated mess. In what way are context-free languages "a grammatically bloated mess?" Whitespace delimited languages like Python have context-sensitive grammars. Now that is a mess.

Most bracket languages aren't strictly context-free either (the Dangling else problem [1] alone somewhat guarantees that most programming languages are not strict, unambiguous CFGs in a mathematic sense). There's no right/wrong/superiority in context-free versus context-sensitive, they are tools in the toolbox and not really "levels in a superiority hierarchy". [1] https://en.wikipedia.org/wiki/Dangling_else

> There's no right/wrong/superiority in context-free versus context-sensitive

Dismissing the whole field of formal language theory with that statement is so bogus, it "is not even wrong." There are tools and techniques for parsing context-free languages that are impossible with context-sensitive languages. Parser generators, structured editing, metacompilers, composable grammars; those are all impossible with context-sensitive languages. Context-free languages are faster to parse, easier to write compilers/interpreters for, and much easier to write tooling for (editors, linters, etc).

Ambiguous context-free grammars are a very different thing from context-sensitive grammars. You can't point to the former and say "so whitespace sensitivity is ok."

Re: Avoid Else, Return Early (2013)

#537

Post by dv_dt »

eggpy wrote: post #517
dv_dt wrote: post #482

Earlier quoted context omitted.

FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".

Do you know what the context of that quote is? I have used it as a sort of mantra specifically when programming, but I'm guessing it probably was intended for writing.

I don't, but it seems like it would find good use in both writing and aviation.

Re: Avoid Else, Return Early (2013)

#538

Post by your-nanny »

vpribish wrote: post #316
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

Wow, you captured so many things I saw in my own education. let me add one: Same way you learn to let some code fail instead of handling every exception.

In my case, half the time I don't know how to handle the exception usefully, and the other half of the time hard failure is the better option. But that's mostly for data analysis.

Re: Avoid Else, Return Early (2013)

#539

Post by edwinyzh »

drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

Anybody has an example for "Same way you move on from heavy OO to dicts/lists"?

Re: Avoid Else, Return Early (2013)

#540

Post by your-nanny »

lisper wrote: post #279
alunchbox wrote: post #157

Earlier quoted context omitted.

python fans are going like "what are braces?"

The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to…

That is clever. Ugly, yes. But clever.
Post reply on HN