41–50 of 88 posts
For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.
I, for one, don't know if I would have ever tried to start learning Haskell if I didn't discover some of the benefits of FP first hand through a familiar language.
Bravo for promoting functional programming and showing how it can be done in JavaScript. One issue concerns me, though: using strings to reference attributes. This makes static checking tools much less useful and can lead to difficult to find errors due to refactoring and typos.
Earlier quoted context omitted.
To be honest, using replaceState for this doesn't seem to make sense to me. A user would probably want to go backward and forward through this using browser history navigation (for instance using the navigation buttons on their mouse). If you're launching a link from a page you expected to come back to, surely opening the link in a new tab would be the way to accomplish this?
Yelp does this with its photo gallery, and it's really annoying. When the user is in a linear sequence such as a slide deck, photo gallery or similar, the "previous"/"next" buttons don't map to the browser's back/forward buttons, they navigate the sequence . Littering the history with the navigation history of this sequence does not make sense. However, it'd be nice if browsers could perhaps record the history (perha…
For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.
Strong agreement. "Adorable" is exactly how I describe it. Even if it's already producing practical advantage in Javascript, it's mostly a cute toy given how it stacks up against "normal" usage. Learn Haskell/OCaml and you'll see how to really take this kind of reasoning many, many orders of magnitude upward. Learn Coq/Agda to see yet another meteoric jump.
* In a large corporate office with heterogeneous skill-sets among developers, but where almost all had some experience with Javascript.
* Javascript Users Groups
In each case, the idea was to make the case that FP could offer them practical advantages. The goal was definitely not to teach them FP or to suggest the best FP tool.
There are definitely better languages in which to do FP. But if for whatever reasons you're working in Javascript, I would suggest that a functional style could be useful.
For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.
I'm very serious about this, because as far as I can tell, the next best aspect of FP might be first class functions, but those are starting to be used more in mainstream languages (at least the technique of applying transformations on generic data rather than writing special classes everywhere or using templates).
I'm beginning to feel that the real advantages of FP are being obfuscated by unusual syntax. There should be no reason why we can't go from some of the FP notations to the plain old algebra style (x=y) of C-style languages like Javascript. With better references and immutable variables, we should be able to split calculations up over several lines and have the compiler figure out how to optimize it into basically FP code.
P.S. I do know lisp, so I'm asking for a rather more enlightened answer than just to research it further.
Earlier quoted context omitted.
Yelp does this with its photo gallery, and it's really annoying. When the user is in a linear sequence such as a slide deck, photo gallery or similar, the "previous"/"next" buttons don't map to the browser's back/forward buttons, they navigate the sequence . Littering the history with the navigation history of this sequence does not make sense. However, it'd be nice if browsers could perhaps record the history (perha…
There's no real distinction. If the slides were implemented as separate pages you would get a new entry in your history as you navigate through each of them. Back doesn't mean to go back to the previous domain; it means the previous page. You don't think the slides should be separate pages, but that would mean you couldn't link to them.
These slides are very difficult to read on a touch device.