Just so everyone knows, if you need something from me, ask soon. I leave on a two-week vacation early Sunday morning.No computers, no internet. Beach, books, volleyball, campfires, and absolutely no defect resolution or production problems!

@joneshf i disagree. these statements "types is where we all slip up" i'd argue is an university academic point of view and not pragmatic programmer. so far i never mistaken my array of ints to be an array of objects.

it only becomes a problem in languages like swift, where time hasn't really moved on since the 70s and I still have to chose Int8, Int32, Int64 (and UInt8, UInt32 etc) combined with a compiler that doesn't help me with "a < b" when a and b are different integer types (and don't get me started on nil and Optional types).

javascript on the other hand doesn't have this problem mainly because it reduces the complexity by not even differentiating between float and integers combined with some (mostly non surprising) type inference (for example, truthy falsey is a great thing).

i'd say that part of javascript's success on the server is to do with productivity. less code and more done. and a big part of that is writing less type expressions to satisfy some over zealous compiler.

IMHO falsey and truthy are sad concepts. I can't understand how some JS programmers are happy with such awful semantics inherited from a language (C) that didn't even have booleans. 0 is false, -1 is true, empty string is false, empty array is true. Arbitrary complexity is the worst type of complexity.

@paldepind and no, an adequate type system can't prevent NPE since we are working in a world that is full of null. a network request may very well return nothing. same for reading a file. and we can wish for non-nil as much as we want – but we are working with computers.

no. i'm saying this is one of the key things you have to be aware of as a programmer. many times you have to expect null and many times you don't. swift's optionals makes the compiler treat more cases than necessary as expecting null resulting in endless amount of fluff to satisfy the compiler.

yes. i'm new to functional programming, so i expect there to be interesting solutions to that kind of chaining i haven't seen yet.

This these (2005)describes "a mechanism to translate classic pointwise code into the point-freestyle. This mechanism can be applied to a λ-calculus rich enough to representthe core functionality of a real functional programming language."

Do you know (or anybody else that might be interested) some papers on thesubject?

@algesten it seems like an academic point of view because the vast majority of languages have such non-expressive type systems that the vast majority of "pragmatic programmers" don't even realize that problems like NPE, out of bounds indexing, invalid comparisons, implicit type coercion, and whatever other common issues (which are type errors!) simply don't have to exist.

also note that there are different levels of type errors

mistaking an array of ints for an array of objects is one level that most static analysis can catch: type checker, unit tests, linter maybe?

and there are higher levels of type errors that most static analysis can't catch: array indexing, demeter violations, LSP.

Using swift as the basis of a comparison is not good. Like you said, it's stuck in the 70's with one or two more recent features

null is not something we HAVE to deal with. It's something we deal with because we made poor decisions in the past, and continue to make them now.

Also, i don't see much difference in what swift asks of you and what coffeescript asks of you. You're still forced to write unnecessary syntax to combat the issue.All those question marks are something you shouldn't have to worry about.

The solution has nothing to do with FP, but it has a whole lot to do with programming languages. And the solution is quite simple: don't put null in the language. Anything else is an attempt to mitigate the problem, not a solution. Yes, that means we can't actually "fix" the current languages that have null (without breaking changes). Yes, that means this problem won't go away so long as we continue to use these languages (read: many many decades if not centuries). But that's what happens when an industry is young. We made mistakes, we just need to educate ourselves and move on.

@joneshf true. the whole problem may be say cocoa, stdlib, etc etc. a entire libraries that have null returns. however this is reality.

the big difference with swift and coffescript is to do with said libraries. working with swift is impossible without a big IDE that helps me show the return type, with javascript/coffee i use emacs. Example:

with swift, at this point, i have absolutely no idea what cell contains. could be a UITableViewCell or perhaps UITableViewCell? who knows? it’s actually AnyObject for some reason. which means I must downcast it first. but since i can’t know that, or whether it’s an optional or not, i can’t just get on with it reading any property of it. cell!.prop (perhaps if-let?) or cell.prop. the only way to know is letting the compiler run and litter my IDE with angry red errors telling me that i didn’t deal with the type properly.

for javascript this just wouldn’t be a problem. cell would be an object (or null). period. maybe a prototyped object, but i don’t care. cell?.prop would suffice in coffee.

Also, I guess we should be clear when talking about swift being stuck in the 70's, it's stuck in the algol-based 70's not the 70's that had actually solved many issues already. Considering sml and similar languages didn't even have null to begin with at that time.

Hello all, I've learning how to write better promise chains using Ramda. I came up with my first in an answer to my own question Writing promises without opening then calls. I would love it if someone from the Ramda community could talk a look at my answer and offer any suggestions.

@SeeThruHead, we did have R.isNaN briefly. You now have two options: Number.isNaN (if your environment defines it) or R.equals(NaN).

@reggi, promises don’t compose. I’d like to write a post explaining why I think in 5–10 years the JavaScript community may be as dissatisfied with promises as it currently is with callbacks. You should have a look at plaid/async-problem if you’re interested in alternatives.

thanks @davidchambers, I'm trying hard to get up to speed with using this library. if anyone could point out what's wrong with this i would be immensely grateful const responseGen = compose(times(jsonGenerator), defaultTo(20), not(Number.isNaN), Number);

oh i think i know what i'm doing wrong here

is there a good way of wrapping NaN like you would null/undefined with Maybe?

@reggi, async/await may improve the situation for imperative JavaScript programming, but I want composability rather than more keywords for control flow. Of the approaches in the async-problem repo, futures come out ahead based on the requirements. Here is the main function:

It's like all I've been told about promises is a lie! @davidchambers you might have just contributed to my structure of reality crumbling. I'm gonna go study up on futures a bit. This seems to be the lib you're using https://github.com/folktale/data.task, any reason why they call them Task and you call them Future?

The problem is that the Promise-based readFile is not a pure function, because applying it triggers a side effect (reading from the file system). The Future-based readFile, on the other hand, is a pure function because no side effects occur until we .fork(). So with futures we can compose pure functions whereas with promises we end up with sequences of effectful computations which contaminate the small bits of code which could be pure functions. Basically we’re left with one big main.

i'm having a hard time with writing functional style as i feel sometimes its a bit too contrived and underperformant. For example, in pointfree style, although the code is DRY, the execution isn't necessarily as there aren't any tmp vars and some things might need to be calculated multiple times. Am I just being paranoid?

@blup, unless you’re actually seeing your application load slowly or scrolling is laggy, I think you’re being paranoid. Ask yourself is it fast enough? rather than is it as fast as it could be? We could, after all, write assembly if the goal is to write code that’s as fast as possible. ;)

No problem, @reggi. Welcome to the wonderful world of functional programming!

Theres a syntax that @davidchambers and others have been using to express how Ramda methods work something like (a -> [b]) -> [a] -> [b] the documentation, coding examples, github issues, and even comments in code all have it. I'm completely unfamiliar with this notation. I've been learning it (erh* ignoring it) slowly enough to pickup that an arrow is a returned value and the values are object types? Can anyone point me in the direction of some documentation / a name for this notation?

I'm writing this talk on point-free programming and I'm choosing to write all the helpers on the fly, and make all of them unary to drive home currying. Also so I don't have to explain how ramda's curry and compose works. I have a module on converge and I remember hearing that you could use compose in place of converge. How you'd do that isn't occurring to me though.