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

Everyday hassles in Go

crufter.com

Post reply on HN
Print view View original

231–240 of 297 posts

Re: Everyday hassles in Go

#231

Post by AnimalMuppet »

codygman wrote: post #205
AnimalMuppet wrote: post #194

Earlier quoted context omitted.

I've been trying to get my mind around this kind of stuff for maybe a year. And I have to say that monads don't look like the solution to any of the problems that I actually face or have ever faced, in a thirty-year career. So, no, it's not just that the words are unfamiliar. It's that the problems that they're trying to solve are so abstract that they're completely disconnected from the work that I actually do. And…

If you give some examples of the work that you do perhaps we can make some of the abstractions concrete.

Perhaps you could. That's not the same as making them useful for me, though.

I work primarily in embedded systems, where sequence is critical, many things are stateful, and there are multiple threads of control. So, for example, I could take the sequential aspects and re-write them as a monad. Or I could just do nothing, and let them be sequential imperative code.

I know that in a pure functional world, sequence can be written as a monad. But why should I care? In my world, it does nothing for me. I'm not going to try to write imperative code in a monad to build an illusion of non-sequential purity when the essence of what I need to be doing is so sequential.

Re: Everyday hassles in Go

#232

Post by lmm »

ominous_prime wrote: post #225
lmm wrote: post #210

Earlier quoted context omitted.

By that logic why bother with for? You can implement any control structure with goto, after all. The value of using map is precisely that it can't do everything a for loop can. It can only do one simple thing, which makes it easy for the reader to understand what it's doing.

> You can implement any control structure with goto, after all. Because a for loop is the most appropriate construct in the given language . That's different than comparing hypothetical constructs that a language doesn't have. Go has higher-order functions, and you can write all the maps funcs you want, it just doesn't have the ability to create generic combinators with parametric polymorphism. That's a trade-off I a…

But we're talking about language design. Of course it's harder to use the feature the language doesn't have than the feature the language does have. The whole point is that the language should have that feature, because if it did have that feature then code using that feature would be better than code using the current features.

> It's like complaining that a functional language doesn't have an easy way to write mutating procedural code.

I do complain about such languages. That's why I use Scala.

Re: Everyday hassles in Go

#233

Post by NateDad »

theseoafs wrote: post #189
NateDad wrote: post #166

Earlier quoted context omitted.

The point is that everyone assumes you need generics to reuse code. And that's simply not true. For some very specific problems that can be true, but in many many cases it's not. My point is not that you never need anything outside the standard library, just that the standard library does a hell of a lot and it is by definition reusable.

Go's standard library uses generics a lot. In fact, Go's built-in datatypes are the only parts of the language that are allowed to use generics.

Built ins are not the same as the standard library. The standard library consists of packages written in normal go for things like networking, web servers, JSON, regular expressions, etc.

Re: Everyday hassles in Go

#234

Post by codygman »

jondubois wrote: post #123

Statically typed languages impose unnatural hardware-oriented constraints on your business logic - It forces you to spend extra time and effort to make sure that your logic is in a format which the compiler can understand. Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the…

Your comment certainly doesn't apply to languages with expressive type systems.

Re: Everyday hassles in Go

#235

Post by sea6ear »

This really seems like a guy who doesn't want what Go has to offer. At every place he compares Go and Haskell, he wants Go to be like Haskell.

There's already a language like that - Haskell.

Re: Everyday hassles in Go

#236

Post by gnuvince »

Peaker wrote: post #224
gnuvince wrote: post #201

Earlier quoted context omitted.

OCaml is currently my language of choice. I love functional programming, been doing it for a while now, but it's nice to know that if I read an algorithm in a textbook, I can just implement it as-is instead of doing a translation to be purely functional (and sometimes having to fight to get back the asymptotic complexity). The module system is also absolutely great, and should be copied shamelessly by more languages.

Haskell doesn't ban imperative programming, it simply distinguishes it in the types.

True, what I mean is that I can be "messy" in OCaml for the sake of expediency. In principle, I prefer Haskell's clean approach, in practice I'm a bad programmer who sometimes does naughty things.

Re: Everyday hassles in Go

#237

Post by zodiakzz »

tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

Dart. https://www.dartlang.org

Re: Everyday hassles in Go

#238

Post by codygman »

AnimalMuppet wrote: post #231
codygman wrote: post #205

Earlier quoted context omitted.

If you give some examples of the work that you do perhaps we can make some of the abstractions concrete.

Perhaps you could. That's not the same as making them useful for me, though. I work primarily in embedded systems, where sequence is critical, many things are stateful, and there are multiple threads of control. So, for example, I could take the sequential aspects and re-write them as a monad. Or I could just do nothing, and let them be sequential imperative code. I know that in a pure functional world, sequence can…

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've already written for one.

Re: Everyday hassles in Go

#239

Post by Peaker »

the_af wrote: post #212
waps wrote: post #134

Earlier quoted context omitted.

Application in Haskell is left associative so its ((Map String) Any) You seem to have stumbled on the exact conflict. Anybody who's seen the theory of lambda calculus will recognize the significance of what you've written, and how it applies to partial binding of functions. Anybody who hasn't will either be thinking of lisp or just be totally confused. This is where the conflict is. Many developers actually know some…

I'd find it depressing if there was any programmer out there who had trouble understanding the concept of "left associativity". I think I learned it in high school.

He's talking about the concept of currying, not left-associativity.

Re: Everyday hassles in Go

#240

Post by Peaker »

ufo wrote: post #19
lmm wrote: post #4

Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.

> Is that a function call, A type declaration? If its following a "::" then its part of a type signature and its a type constructor application. Otherwise, its part of an expression and its a regular function call. BTW, Haskell capitalization is significant in Haskell. Identifiers starting with lower case are always regular functions. Types and type constructors always start with upper case. > What's a parameter to w…

GHC type errors are far from ideal.

But if you give too few or too many arguments, you usually do get an error like: "Perhaps `foo` is applied to too [many|few] arguments?"

Post reply on HN