grasleya · HackerTrans

il y a 9 ansdiscuss

Functional languages are perfectly capable languages so you can typically use them for anything you'd use any other language for. But if you want a project that specifically showcases functional programming, writing a parser using parser combinators can be fun and instructive.

grasleya

il y a 9 ansdiscuss

The universe will end before we can decide on 2.7 or 3.

grasleya

il y a 9 ansdiscuss

I think you can put this more generally as "syntax is not semantics." Go takes some syntactic cues from python (but who doesn't these days?) but its semantics can be pretty different. I think it's pretty common for new programmers especially to get caught up in the syntax of languages without giving enough attention to their semantics, which causes the sort of problems the author highlights here.

grasleya

il y a 9 ansdiscuss

I agree that template metaprogramming can get overly complex. I think it would probably be a mistake to bolt a full C++ template metaprogramming system onto go. But just a standard generics system like Java's would go a long way to improving the language.

grasleya

il y a 9 ansdiscuss

I can buy using generics sparingly (especially in the form of complex template metaprogramming). But never using it at all? Can you imagine convincing the C++ community to give up Boost because its use of templates is too complex?

They also seem to admit that if they were to do it over again and start from scratch they'd use exceptions:

> Things would probably be different if we had to do it all over again from scratch.

grasleya

il y a 9 ansdiscuss

Checked vs unchecked exceptions is kind of a separate thing from exceptions vs no exceptions. There are plenty of modern languages without checked exceptions but few with no exceptions period.

grasleya

il y a 9 ansdiscuss

More golang Stockholm syndrome. These arguments are always weird to me. Go has plenty of complex features that go developers don't seem to think cause too much cognitive burden (automatic gc, structural subtyping, etc.). Why is it that relatively simple and ubiquitous language features like exceptions and generics are just way too much and cause an unacceptable amount of complexity? I just don't buy it.

Turn the argument around. Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? Are there people who say that even though these languages have generics you shouldn't touch them because they're bad? Do any devs with option/maybe types really want to go back to unsafe code that can fail if you forget to check for nil/null? Show me someone who hasn't drunk the go kool-aid who still makes these sorts of arguments and I might actually start listening.

grasleya

il y a 9 ansdiscuss

The catch-all top level error handler isn't typically a hallmark of good design but I think it's pretty relatable as a quick fix when you need to get something working on a deadline.

grasleya

il y a 9 ansdiscuss

You can code golf in any language and it will probably result in less comprehensible code. If there's one thing I think I agree with the original author on, it's that terseness is not an end unto itself. But I think the overall point that terseness can sometimes be bad so therefore we shouldn't work at a higher level of abstraction is really at odds with everything we've learned about programming in the last century.

grasleya

il y a 9 ansdiscuss

A counterpoint is that more declarative code can often remove the need for tedious step by step debugging because the behavior of the code is more transparent. I do most of my work in Haskell and find I don't typically need to debug it like I would for a less declarative language because the meaning of the code is much more clear.

grasleya

il y a 9 ansdiscuss

This is a hilariously bad take. If we follow the argument to its natural conclusion then go is itself a poor choice of language. After all, go removes memory management boilerplate in favor of an automated gc system. By the author's argument go should force you to manage your memory yourself. In fact, we really should all just code in assembly because it has the clearest relationship between code and what is going on under the hood. True, coding in assembly requires a lot of needless boilerplate but by this article's argument that's actually a feature.

Go has so many truly bad design decisions (lack of generics being the most damning) and it's sad to see its fanboys try to argue that they're actually good.

comments