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

Alan Donovan and Brian Kernighan Answer Questions on Go

features.slashdot.org

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#101

Post by bkeroack »

rubiquity wrote: post #97
atilaneves wrote: post #30

Go is as far removed from "extreme abstraction" as any other language I know. I don't know how it can even for a second be considered to have that desireable attribute. I, for one, don't like abstraction and power just because I'm a PL geek. I admit those are also reasons, but the truth is I use them to make my codebase smaller, simpler, and easier to reason about. For some, achieving that goal means writing for loop…

Agreed. There's abstraction and then there's abstraction. I might have been in the camp of Go enthusiasts if my experience with abstraction only included C++ or Java. But once I discovered Standard ML and OCaml I found out how wonderful abstraction can be.

I'm not sure many people are arguing that abstraction isn't good for those who are writing the code--that's the whole point of abstraction after all, to make the developer's job easier.

The problems tend to crop up for other people trying to decipher and read it. Sometimes also for the machine trying to execute it.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#102

Post by mcguire »

jfb wrote: post #57
mcguire wrote: post #56

Earlier quoted context omitted.

This is not idiomatic Java code and in my experience not many competent people will do this. New Java programmers who ask for help with a piece of code that ignores the error are told immediately to check the error. And experienced Java programmers simply do not ignore the error. Also, you don't need the semicolon.

It's not idiomatic, or good, but neither is ignoring the return value from a go function call. Both languages fail to provide better affordances for error checking.

That it's bad style is kind of the point: The standard response from Go advocates is that ignoring errors is not idiomatic, but it's not good style anywhere, in any language where it isn't outright illegal.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#103

Post by Vendan »

vox_mollis wrote: post #67
dawkins wrote: post #27

Earlier quoted context omitted.

I thought the same. I use it every day and its great. I dont understand why it doesn't get more traction.

Because visually, it's reminiscent of Eclipse 1.0. For better or worse, a sizable proportion of developers choose IDEs on the basis of looks.

Heh, I choose IDEs based on performance, not looks, and liteide is blazing fast compared to anything else I've used.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#104

Post by AnimalMuppet »

jerf wrote: post #31
Nexialist wrote: post #29

Earlier quoted context omitted.

Although a lot of people are pointing out (correctly) that it's trivially easy to ignore a checked exception, it does at least do two things: 1. Signal to the calling programmer that some error condition can occur. For example having to catch SomethingNotFound tells them that it's possible that Something might not be found. 2. You just put in your coding standards that you must do something sensible inside of a catch…

I've got a blog post on deck that basically says that just as Joel on Software proposed that the vast bulk of the advantage of scripting languages in the 2000s was garbage collection, I propose that the big advancement in error handling lately is simply the idea that it ought to be stuck in the programmer's face, and the exact manner in which it does so isn't really very important. By that standard, exceptions actual…

jerf, when you write that blog post, would you submit it on HN? I'd like to see it.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#105

Post by bjz_ »

pcwalton wrote: post #62
stcredzero wrote: post #60

Here's a solution to the diamond dependency problem: Imports can only be done for a specific lexical scope. Also, imports must specify a particular version. Lastly, calls to a package go to a specific version of the package, and types are defined in a specific version. (This is why all imports must be done for a specific lexical scope.) The same scheme could be used to resolve diamond dependencies in multiple inherit…

That's essentially the solution Rust and Cargo adopt. It occasionally causes strange errors like "expected Foo, found Foo" (where the first Foo was, say, Foo version 1.1 and the second was Foo version 1.2), but the compiler now detects this situation and tries to explain what's going on. I'm certain I'm biased, but in my experience it's been the most robust way to handle versioning that I've dealt with.

> the compiler now detects this situation and tries to explain what's going on.

Oh really? That's great news! I remember having that problem earlier this year and thinking that it wasn't the greatest from a usability standpoint.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#106

Post by to3m »

to3m wrote: post #84
4ad wrote: post #53

Earlier quoted context omitted.

> Are there still systems where you can't get a C99 compiler? In windows it's pretty annoying to get a C99 compiler. The "standard" compiler to do Windows development is Microsoft's, and it doesn't support C99. Of course you can install MinGW (gcc); most open source software on Windows uses it, but it's very unusual for the average Windows developer to even have gcc, and completely unheard of in the commercial space.…

Visual studio 2013 supports enough C99 that you can get by (VLAs are the main omission). Visual Studio 2015 is supposedly fully conforming.

Too late to edit, but, looking through the archives, it looks as if I might be incorrect about VS2015: https://news.ycombinator.com/item?id=10278704

Nevertheless, I stand by my comments re VS2013+. If you're accustomed to working on projects that support varied platform/compiler/libc combinations, but you've still specifically found VS2010 (and earlier) particularly difficult to work with due to the insistence on C89, you'll probably find VS2013 (and later) substantially more to your taste, and by quite some margin.

(That's certainly been my experience anyway. After some initial effort to work around library differences, my C99 code builds with gcc/clang/VS2013 - and does so, ongoing, with very little effort.)

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#107

Post by jfb »

mcguire wrote: post #102
jfb wrote: post #57

Earlier quoted context omitted.

It's not idiomatic, or good, but neither is ignoring the return value from a go function call. Both languages fail to provide better affordances for error checking.

That it's bad style is kind of the point: The standard response from Go advocates is that ignoring errors is not idiomatic, but it's not good style anywhere , in any language where it isn't outright illegal.

I think we're in violent agreement. I wasn't saying that Go's affordances solve this problem, merely pointing out that checked exceptions in Java aren't any kind of a dispositive solution.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#108

Post by Retra »

incepted wrote: post #79
Retra wrote: post #47

Earlier quoted context omitted.

You (the programmer) still have to handle it. If I (as a person) don't know how to handle the exception, passing it up the call stack doesn't solve the problem, it just moves it to somewhere else. The problem is that I don't know where it should be handled, because it was exposing cryptic and obscure exception types that probably make sense to someone who really understands cryptography. I don't, so I just can't use…

> it just moves it to somewhere else. That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it. > The problem is that I don't know where it should be handled Then don't handle it at all and let it crash the program. But at least you didn't add boiler plate simply bubbling up an Err at every level of the stack frames. > If those were runti…

I'm not talking about handling the error, I'm talking about boilerplate. In order to get the program to even crash on error, I had to handle 4 different kinds of exceptions. I'm as much a fan of expciciteness as anyone, but there's a difference between explicit and verbose. And there's a lot to be said for constructs that don't force you to indent your code every time you call a function.

My goal wasn't to write correct code, it was to test something out. To get comfortable with the library and the task. Checked exceptions get in the way of that.

>Languages that take correctness seriously should offer you both options.

Rust and Haskell take correctness seriously and offer neither. Checked exceptions make perfect sense in terms of ensuring correctness, but they are awful for usability and they are not the only way to achieve correctness.

>Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions).

Shouldn't the user determine that, not the implementor? Why should any exceptions not be checked?

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#109

Post by incepted »

Retra wrote: post #108
incepted wrote: post #79

Earlier quoted context omitted.

> it just moves it to somewhere else. That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it. > The problem is that I don't know where it should be handled Then don't handle it at all and let it crash the program. But at least you didn't add boiler plate simply bubbling up an Err at every level of the stack frames. > If those were runti…

I'm not talking about handling the error, I'm talking about boilerplate. In order to get the program to even crash on error, I had to handle 4 different kinds of exceptions. I'm as much a fan of expciciteness as anyone, but there's a difference between explicit and verbose. And there's a lot to be said for constructs that don't force you to indent your code every time you call a function. My goal wasn't to write corr…

> Why should any exceptions not be checked?

Because there are exceptions you can't do anything about (e.g. OutOfMemoryException) and exceptions that you don't know what to do with (e.g. an NPE where you didn't expect it).

NPE is the poster child for an unchecked exception: if you know your code is throwing an NPE here, just fix it instead of catching the NPE.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#110

Post by jasonwatkinspdx »

wtetzner wrote: post #90
jasonwatkinspdx wrote: post #83

Earlier quoted context omitted.

I'm convinced this is the right approach: dependencies should be purely local to a module. The tooling should make it easy to detect you have a diamond, but let each module get what it needs. As generally everyone moves towards more continuous update and integration, at the end of the day it's all gonna be sha's anyhow.

But what do you do in a typed language? For example, suppose you have modules A and B, which depend on module C. Let's also say that module A has a function foo that return a value of type C.t, and module B has a function bar that accepts a value of type C.t. Now let's say that module A is depending on version 1.0.0 of module C, and module B is depending on version 1.5.2 of module C. Does B.bar(A.foo()) still work? I…

I think the pragmatic approach is to just let that be a type analysis failure and force the user to deal with it. We don't need the module system to be automatically perfect in every imaginable extreme, we need it to be fundamentally safe, and then do sane useful things in the situations that are safe.
Post reply on HN