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

Three Months of Go, from a Haskeller’s perspective (2016)

barrucadu.co.uk

Post reply on HN
Print view View original

211–220 of 363 posts

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#211

Post by mafribe »

kod wrote: post #141
gothrowaway wrote: post #81

When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy. Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3). The other thing is the general flow I've see with Haskell programmers…

In over 10 years the most productive people I've worked with were able to learn Scala and ship code in Scala quickly, without worrying about whether they would rather be programming Haskell.

The best programmers I've met created ML, Scala and Haskell.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#212

Post by woah »

edmccard wrote: post #184
j2kun wrote: post #174

> But Go does have generics, for the built-in types. Arrays, channels, maps, and slices all have generic type parameters. Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map? (Not a go programmer yet, but honestly curious)

>Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map? Nope. There are only a few functions that accept type parameters, and they must be called with concrete types, and they only work with certain aggregate types. For example, "make" can only be used to create slices, maps or channels, so you could create a slice of 10 bytes with "make([]bytes, 10)" bu…

I think it's better to not even think of them as "generic functions". Think of them as language keywords which happen to have the syntax of functions.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#213

Post by [deleted] »

shmageggy wrote: post #147
TheCondor wrote: post #134

Earlier quoted context omitted.

I don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness? I ask as an old SML guy, I like the math theory, I like the promise of bett…

Off the top of my head, Pandoc, a tool for converting between different markup/down flavors, and xmonad, a tiling window manager for linux. Both are well known and popular.

[deleted]

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#214

Post by davesque »

theoh wrote: post #193
shmageggy wrote: post #147

Earlier quoted context omitted.

Off the top of my head, Pandoc, a tool for converting between different markup/down flavors, and xmonad, a tiling window manager for linux. Both are well known and popular.

Is there anything actually interesting about what they do, though? Converting markup is not a complex task.

Pandoc actually converts between a wide range of document formats.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#215

Post by fauigerzigerk »

coldtea wrote: post #118
noir_lord wrote: post #104

Earlier quoted context omitted.

I prefer less powerful languages (that have sufficient power to clearly express the domain). I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. This gets even worse when you have multiple people on the team doing clever things(TM).

> I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. They also allow you to do sensible things(TM) like use the one and single, battle tested, standard library's generic sort, btree, etc implementation, instead of having to roll (and then read) 1000s of your own over the span of a year... And it's a false dichotomy that you can't…

The problem with "too clever" isn't just about cleverness that is actually in the code. It's also very much about cleverness that could potentially lurk behind any particular syntactical expression.

When you look at a line of code, what can you tell about its semantics without considering non-local information? What is invariant and what could potentially be redefined?

I think the answer to this question is extremely important for readability when you're not already familiar with a codebase.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#216

Post by steveklabnik »

theoh wrote: post #193
shmageggy wrote: post #147

Earlier quoted context omitted.

Off the top of my head, Pandoc, a tool for converting between different markup/down flavors, and xmonad, a tiling window manager for linux. Both are well known and popular.

Is there anything actually interesting about what they do, though? Converting markup is not a complex task.

Parsing is something that's very pleasant in Haskell. Other languages can use parser combinators too, of course. It's good at it though.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#217

Post by voutasaurus »

unscaled wrote: post #148
canes123456 wrote: post #129

Earlier quoted context omitted.

No one is arguing to roll your own when there a generic sort in the standard library. The issue with clever things is that people try to make a all purpose solution for what could be a simple one off solution. The all purpose is only used for 2-3 uses and it never battle tested.

Clever things like a sort function that can sort both ints and floats and any new type that implements a comparison function?

https://golang.org/pkg/sort/#Slice

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#218

Post by theoh »

steveklabnik wrote: post #216
theoh wrote: post #193

Earlier quoted context omitted.

Is there anything actually interesting about what they do, though? Converting markup is not a complex task.

Parsing is something that's very pleasant in Haskell. Other languages can use parser combinators too, of course. It's good at it though.

Yeah, fair point. That'll be a function of the fact that Haskell has tended to prioritize the concerns and problems of writing the compiler.

Complex transformations of data structures are part of the compilation activity too, but they're more difficult to spot in the wild of applications.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#219

Post by bborud »

base698 wrote: post #196
bborud wrote: post #62

Earlier quoted context omitted.

What do you mean by "powerful"? How is a language powerful? Or not?

From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power con…

So when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#220

Post by anistas »

steveklabnik wrote: post #216
theoh wrote: post #193

Earlier quoted context omitted.

Is there anything actually interesting about what they do, though? Converting markup is not a complex task.

Parsing is something that's very pleasant in Haskell. Other languages can use parser combinators too, of course. It's good at it though.

C-to-Rust converter is written ... in Haskell https://github.com/jameysharp/corrode
Post reply on HN