News for hackers. Stuff that matters.
Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @07:51AM (#16347094)
And for non-functional languages?

Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing.

[rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing functional programming everywhere is IMO just insanity and everybody is silent about many warts and weirdness of purely functional programming. [/rant]

Re:In web design, everything easy is hard again by dbrgn on Saturday February 10, 2018 @08:09AM (#16347152)
Elm is the opposite. From this article:

https://medium.com/@eeue56/why-type-classes-arent-important-...

"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."

And

"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."

Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!

You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.

Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @10:48PM (#16351070)
Thanks! Do you know any good (Udemy?) course in Elm that won't take too much time and gets into important parts quickly and thoroughly?
Re:In web design, everything easy is hard again by dbrgn on Tuesday February 13, 2018 @10:27AM (#16367797)
The guide is probably the best resource to get started: https://guide.elm-lang.org/ It introduces you to the language as well as the concepts / architecture.
Re:In web design, everything easy is hard again by machiaweliczny on Sunday February 11, 2018 @12:47PM (#16353707)
I don't get why you need udemy course. Just read official tutorial with open sandbox/project.
Re:In web design, everything easy is hard again by csmiller on Sunday February 11, 2018 @06:56PM (#16355533)
Re:In web design, everything easy is hard again by pka on Saturday February 10, 2018 @09:08AM (#16347315)
> And for non-functional languages?

I would recommend Typescript then.

> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.

True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.

Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @10:55PM (#16351092)
> I would recommend Typescript then.

Funny, all people using Typescript I know use it in functional way (computer vision/AR in a browser).

Re:In web design, everything easy is hard again by mafribe on Saturday February 10, 2018 @08:44AM (#16347246)
I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition.

Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching.

Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.

Re:In web design, everything easy is hard again by seanmcdirmid on Saturday February 10, 2018 @09:07AM (#16347312)
Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more.

The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.

Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @09:11AM (#16347332)
Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.
Re:In web design, everything easy is hard again by naasking on Saturday February 10, 2018 @09:31AM (#16347414)
> Debugging is one of the biggest problems with FP

I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.

Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @10:11AM (#16347594)
I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.
Re:In web design, everything easy is hard again by pka on Saturday February 10, 2018 @10:53AM (#16347799)
Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e:

    do
       x <- newIORef 0
       writeIORef x 2
       print =<< readIORef x
will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints.

[0] https://en.wikipedia.org/wiki/Software_transactional_memory

Re:In web design, everything easy is hard again by seanmcdirmid on Saturday February 10, 2018 @10:58AM (#16347822)
For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).
Re:In web design, everything easy is hard again by naasking on Saturday February 10, 2018 @12:12PM (#16348220)
Indeed there are some quirks in VS 2015 even in C#, like writing a function as a generator isn't as pleasant as it could be. Haven't tried VS 2017 yet. I think we're a little spoiled on .NET though, we've forgotten how bad debugging is in other languages!
Re:In web design, everything easy is hard again by tome on Saturday February 10, 2018 @11:29AM (#16347967)
Interesting. Where do you hear that? What I've heard (and experienced) is that Haskell makes is easy to come back and understand code written a long time ago (because the language allows one to structure code very clearly).
Re:In web design, everything easy is hard again by mafribe on Saturday February 10, 2018 @04:10PM (#16349617)
I'm not a historian. It's certainly true that monads or monad-like things where discovered independently in many context. This isn't even surprising, given how natural, and trivial in a sense monads are. But the systematics realisation of the concept and its wide applicability comes from algebra and the efforts to recover algebra categorically. Let me quote from Wadler's [1]:

The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework.

[1] P. Wadler, The essence of functional programming.

Re:In web design, everything easy is hard again by bitL on Saturday February 10, 2018 @09:09AM (#16347317)
Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.
Re:In web design, everything easy is hard again by nickjj on Saturday February 10, 2018 @09:05AM (#16347304)
It's not that bad.

I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.

I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.

I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.

This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.

After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).

Re:In web design, everything easy is hard again by ptx on Saturday February 10, 2018 @09:17AM (#16347350)
If you want an imperative and statically typed language, try Kotlin: https://kotlinlang.org/

...which targets JavaScript in addition to the JVM (and being an officially supported language for Android development): https://kotlinlang.org/docs/reference/js-overview.html

Re:In web design, everything easy is hard again by mmargerum on Sunday February 11, 2018 @07:56AM (#16352484)
Immutable dats structures in CLJS pairs well with react type frameworks. Trying to make js pretend it supports immutable structures is what turned me off the most about react/js

I ended up going with vue which uses mutations instead of having to return structure copied from functions.

Just made more sense to me. Maybe MobX does this for react? Idk