15 ms·

If you're an analytics shop (presumably) working with streams of events, I'm going to go out on a limb and say that not picking a functional language (purescri

• oatmealsnap 11y ago
  I know zero developers who know purescript or elm. That is a hiring problem, especially for young companies.
  • jdhawk 11y ago
    Then hire someone who knows Coffee or Type and teach them Purescript? Its not that hard for developers to pick up a new syntax if they understand the framework and ecosystem around it...
    • 15155 11y ago
      Calling PureScript "new syntax" is a huge understatement. I love PureScript (and Haskell, FWIW), but it's a huge paradigm shift from CS, TS, or JS.
  • alanh 11y ago
    I know a few Elm developers. Using a less mainstream language can actually be a boon to hiring. (Isn’t there a classic PG essay on how ViaWeb benefitted enormously from using a Lisp when no competitors did?) > Had our first hire start today who applied because we use @elmlang in production. He rocked it! > PS: still hiring :) https://twitter.com/rtfeldman/status/656238188961226752 https://twitter.com/rtfeldman/status/656238188961226752 Furthermore, I’ve learned so many languages on the job in my career that I am unsympathetic to companies who refuse to believe that people who have learned programming can continue to learn programming!
    • kornish 11y ago
      PG has a couple essays directly related to this topic. The first about using a language which is implicitly more powerful than others ("Beating the Averages") [1] and the other is about how using a less common language is a positive selector in the hiring process ("The Python Paradox") [2]. [1]: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html [2]: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
      • omtanks 11y ago
        Agree on the first. On the second, "And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.". I disagree, I like to solve problems more in Java. I tried several including Python over the years. I'm asked to do something in Python I will but for my money, Java is more readable than Python. It's an acute and false observation that he made. Less common does not necessarily equate to smarter/better/faster.
        • dllthomas 11y ago
          This was dramatically more true of Python when he wrote it than presently. FWIW, I've recently been using Python for a job and find it deeply unsatisfying. I'm inclined to think that current-gen Java may well be better; the last time I used Java in anger it was basically a different language. Though to be fair, truly modern Python is also a bit different than what I've been working in.
    • smt88 11y ago
      PG isn't God, and he related a single anecdote. I won't believe that argument unless I see current data that's language-specific. For example, I could imagine easily being able to hire devs to work on Go, but it'd probably be really hard to get them to work on Haskell.
      • alanh 11y ago
        > PG isn't God Can you prove that? Absence of evidence isn’t evidence of absence, after all. You’re being a bit militant in your pg-atheism. Okay, in all seriousness, you are correct. Ability to hire coders to work in a particular language is a legitimate concern to have. Still, it’s sad to see lack of usage drive, well, lack of usage – sometimes it looks to me like an unexamined assumption, or a self-fulfilling prophecy. To take it back to the land of religious arguments: it’s a bit cargo-culty.
  • lewisl9029 11y ago
    Try ClojureScript. There are plenty of developers, especially here on HN, who would absolutely love to work with Clojure/ClojureScript full-time.
    • iLemming 11y ago
      I desperately want to extend my exposure to Clojure/Clojurescript. Unfortunately I can't use in my current company. I'm trying to play with it in my own time, which is of course very scarce. I wish more companies realized how amazing Clojurescript is.
  • Fiahil 11y ago
    I don't know purescript or elm, so I can't speak for their qualities. But, I also don't know half the languages cited nearby either (livescript, clojurescript). How can I pick and learn "the right one"? They all seem the same to me, and I think that's the problem.
  • boothead 11y ago
    It's counter intuitive but picking one of these niche technologies means: 1) you'll need less people (better more reusable code) 2) the best people will speak you out. This was very much my experience when I put a Haskell team together, and everyone I've spoken to who has done the same has said the same. It's an opportunity for a young company, not a problem.
  • masklinn 11y ago
    > That is a hiring problem On the one hand there's a smaller pool of people, on the other hand a primary issue in hiring is sifting people who can do the job from a random draw[0], in which case interest and/or knowledge of Elm or Purescript is a huge prefilter, and can draw/poach people who wouldn't otherwise be interested (pg's "the python paradox"[1] talks about that) [0] or worse, you don't get a random section of developers, you get a section of developers currently looking for a job, so the average competence of your draft is below average. [1] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
  • dllthomas 11y ago
    A while ago, I had occasion to look for Haskell programmers, to hand off a project to. Despite promising to offer substantially below market rate, with no chance of a major pay-day, I got quite a pile of seemingly serious applicants for the position, some quite impressive. While the project had some non-profit volunteering good vibes around it, I think the experience is still worth noting for those interested in the ease of recruiting developers of niche languages.
• cpursley 11y ago
  Agreed, and a good middle-ground between JS and purescript/elm is livescript: http://livescript.net/blog/functional-programming-in-javascript-using-livescript-and-prelude-ls.html http://livescript.net/blog/functional-programming-in-javascr...
• ksikka 11y ago
  > not picking a functional language As opposed to what? In what ways do you not consider Javascript to a be a functional language?
  • Touche 11y ago
    var a = 1; a = 2; window.someGlobal = 'foo';
    • ksikka 11y ago
      https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      • Touche 11y ago
        const a = {b: "foo"}; a.b = "bar";
        • dangoor 11y ago
          const a = icepick.freeze({b: "foo"}); Granted, that's not as elegant as built-in support but that is literally what I'm doing at the moment when I want immutability.
          • Touche 11y ago
            So if you go to extraordinary lengths you can use JavaScript functionally but it's not very functional by default aside from the first-class functions. Personally I just embrace it's imperative/functional blended nature and go with it.
            • deleted 11y ago
              [deleted]
        • pyrophane 11y ago
• a-saleh 11y ago
  I don't think it makes that much sense w.r.t stream events: 1. most of the analytics/event-stream processing will be done on the backend anyway 2. If you are picky enough you can do functional programming in js. Reative.js is decent library for processing streams of events. What screams to use something more haskell-like, is their example of 'Trys', i.e: class GraphQuery extends Query { static parse(object: any): Try<GraphQuery> { return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => { return Filter.parse(object.where).flatMap((filter: Option<Filter>) => { return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => { return new Success(new GraphQuery( filter, groupBy, timeRange )); }); }); }); } } should look like something like: parse : Any -> Try GraphQuery parse object = do timeRange <- TimeRange.parse object.over filter <- Filter.parse object.where groupBy <- GroupBy.parse object.by return (createGraphQuery filter groupBy timeRange) (haven't used haskell in quite some time, so maybe I am missing something)
  • jiaweihli 11y ago
    You're absolutely right! I was hoping someone would point this out, since this is a much cleaner way of writing this code. This is pretty close to how it's done in Scala. For the purposes of this article, we tried to avoid too much syntax sugar to make it more accessible. That aside, I'd love to add something like this to monapt![1]. [1] https://github.com/jiaweihli/monapt https://github.com/jiaweihli/monapt
    • roryokane 11y ago
      Here’s a sketch of some potential syntax to simplify your TypeScript so it’s like that Haskell code. class GraphQuery extends Query { static parse(object: any): Try<GraphQuery> { return TimeRange.parse(object.over) .combinedWith(() => Filter.parse(object.where) ) .combinedWith(() => GroupBy.parse(object.by) ) .withCombinedValues((timeRange, filter, groupBy) => { return new Success(new GraphQuery(filter, groupBy, timeRange)); }); } } In this design, `combinedWith` is a lot like `then` when using promises. It’s a bit more complicated because `then` assumes that arguments are always passed directly from the previous function, so you need special support to store the return value and retrieve them later as arguments. If the type system requires it for some reason, you could add a `.startCombining()` call at the end of the first line within the method, so that `combinedWith` is sure to be possible.
• aikah 11y ago
  Would make more sense to use a FRP library like Rx.js . Introducing yet another language+pipeline just for that is questionable.