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

321–330 of 363 posts

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

#321

Post by rs86 »

CJefferson wrote: post #294
sheepmullet wrote: post #288

Earlier quoted context omitted.

> has been so incredibly successful in such a short time. 1) Our industry is obsessed with new and shiny. 2) There are a lot of developers and companies who don't have the time to invest in a new paradigm or language. 3) By learning/using golang these developers and companies can look "hip" and forward thinking with minimal effort. With a Java background and a 10 hour investment in golang you can write decent softwar…

The problem is, people tell me that if I just learn Haskell, Idris, Closure, Coffescript, Rust, C++17, C#, F#, Swift, D, Lua, Scala, Ruby, Python, Lisp, Scheme, Julia, Emacs Lisp, Vimscript, Smalltalk, Tcl, Verilog, Perl, Go... then I'll finally find 'programming nirvana'. While you might think it's worth spending 100+ hours learning Haskell, I don't (at the moment) have any reason to Haskell as a better time investm…

100 hours is really optimistic for haskell

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

#322

Post by rs86 »

pekk wrote: post #251
platz wrote: post #207

Earlier quoted context omitted.

> In haskell the application has to be an elegant diamond or the thing won't even compile! Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse). But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements. (unless you're refer…

If you are going to "throw everything in IO" then what advantage does Haskell have?

Lazyness, generic programming, algebraic datatypes, inferred typing

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

#323

Post by dukerutledge »

theoh wrote: post #218
steveklabnik wrote: post #216

Earlier quoted context omitted.

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.

I'd disagree. Most business logic is just transformation of data structures in disguise. Once you have a sufficiently rich set of data structures this becomes abundantly clear.

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

#325

Post by didibus »

lilactown wrote: post #269
didibus wrote: post #221

Earlier quoted context omitted.

That's a great call out, though I see this in most languages, Haskell and go equally have implicit non local behaviours, but I find the functional paradigm tend to have less, because of side effect free functions.

I find laziness (coming from more imperative, non-lazy languages) to be a huge source of implicit non-local behavior. Trying to figure out how efficient my code is without specific knowledge of how certain functions in the standard library work/how the compiler interprets my code is a impossible.

You're right, the execution context is non local. I'm actually not a big fan of laziness as the default myself. I love the option of lazy evaluation, because sometimes, it makes things really easy, like for infinite sequences, but most of the time, it does add complexity in reasoning about the code.

There's functional alternatives to Haskell which adopt the non-lazy as default, such as Elm, Rust, SML, Lisps, Fantom, Elixir, Scala, etc.

I have to admit though, this is a bit of a trade off situation. Working with pure functions is very simple, but to map those to unpure behavior, like IO, you need something that isolate that, and without laziness, I'm not sure how you can get that to be practical.

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

#326

Post by cube2222 »

kuschku wrote: post #313
cube2222 wrote: post #283

Earlier quoted context omitted.

I'm not sure if I understand, are you actually using Go for your UI backing or using it as a backend for your application?

The application described above is Java. Runs on Android and desktop Java with JavaFX. I tried to reimplement the desktop version with Go, due to native UI bindings. And failed.

Well, I don't see any problems with the logic part. Receiving, filtering, transforming, and notifying someone else about incoming messages (would probably do it in a few threads, sending messages between each other).

For the UI part: no wonder, Go, at least currently, is useless for UI's.

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

#327

Post by doall »

CJefferson wrote: post #294
sheepmullet wrote: post #288

Earlier quoted context omitted.

> has been so incredibly successful in such a short time. 1) Our industry is obsessed with new and shiny. 2) There are a lot of developers and companies who don't have the time to invest in a new paradigm or language. 3) By learning/using golang these developers and companies can look "hip" and forward thinking with minimal effort. With a Java background and a 10 hour investment in golang you can write decent softwar…

The problem is, people tell me that if I just learn Haskell, Idris, Closure, Coffescript, Rust, C++17, C#, F#, Swift, D, Lua, Scala, Ruby, Python, Lisp, Scheme, Julia, Emacs Lisp, Vimscript, Smalltalk, Tcl, Verilog, Perl, Go... then I'll finally find 'programming nirvana'. While you might think it's worth spending 100+ hours learning Haskell, I don't (at the moment) have any reason to Haskell as a better time investm…

Just a typo, but you mean Clojure？ :)

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

#328

Post by willtim »

willtim wrote: post #296
ngrilly wrote: post #262

Earlier quoted context omitted.

I don't understand the downvote. The main argument looks valid: > If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason w…

It's overly simplistic. For example, Haskell's do notation allows asynchronous programming in a linear "task list" (to use your phrase). Yet most popular imperative programming languages do not; one must instead use callbacks. As to whether programming with expressions is fundamentally harder, I'm not so sure. Since Fortran, most languages have supported arithmetic expressions over primitive numeric types, since they…

Forgot to mention that I didn't downvote either, despite disagreeing with much of the post.

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

#329

Post by CJefferson »

59nadir wrote: post #317
CJefferson wrote: post #297

Earlier quoted context omitted.

On the other side, I used XMonad for a while and it crashed frequently. I did submit a bug report and it did get fixed, but there was another crash I couldn't be bothered to try to track down, and just switched back to the standard ubuntu shell.

> I did submit a bug report and it did get fixed, but there was another crash I couldn't be bothered to try to track down, and just switched back to the standard ubuntu shell. Interesting. What was the bug, if I may ask? Do you have a URL for it and the resolution to it? What do you mean, you "switched back to the standard Ubuntu shell", exactly? XMonad is a window manager, it has nothing to do with shells. On top of…

By shell, I mean window manager.

I'll try and look up the bug.

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

#330

Post by mathw »

crimsonalucard wrote: post #307
platz wrote: post #266

Earlier quoted context omitted.

I'm not the downvoter, but I still don't understand the assertion why Haskell doesn't allow the "task list". There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.

You are right, but no beginner truly understands do notation. It's just magic to them. Do notation is an abstraction on top of monads which is an incredibly hard to understand abstraction on top of functional programming. Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that i…

I never found monads particularly difficult.

I still don't understand what the problem is with them.

It's just a box with some "stuff" in, a function that makes a new box with a thing inside, and a function that takes a box and a value and gives you a new box with some different stuff inside.

The hardest part for me was accepting that I can't look inside the box and don't actually need to.

I do get that there are a lot of people who'll look at monads and want to know why the heck they should bother when any "decent" or "reasonable" language just lets all their functions crap all over the filesystem whenever they like.

Post reply on HN