Hacker Newsnew | past | comments | ask | show | jobs | submit | _davidchambers's commentslogin

SEEKING WORK • Berlin, Germany • Remote or on-site • Software developer

I'm a software developer with 13 years of experience. I love leveraging software to save people time. I have a background in (visual) design and consider design to be crucial to the development of all software (even software with no visible interface).

I have deep knowledge of JavaScript. I have also worked professionally with TypeScript, Python, and Haskell. I enjoy working with HTML and CSS. I know React, and I'm looking for an opportunity to learn htmx.

I have created Sanctuary (https://sanctuary.js.org/) and several other libraries. :)

https://davidchambers.me/cv/


Location: Berlin, Germany

Remote: Yes

Willing to relocate: Possibly

Technologies: JavaScript, TypeScript, Python, Haskell, Clojure, Bash, SQL, HTML, CSS, React, htmx, functional programming

Résumé/CV: https://davidchambers.me/cv/

Email: dc@davidchambers.me

Author of Sanctuary (https://sanctuary.js.org/) and several other libraries. I love writing parsers and interpreters. I enjoy writing shell scripts more than is healthy (ShellCheck is amazing). I love hyperlinks and discovering web standards.


These two functions are equivalent:

  const f1 = function(s) {
    let data;
    try {
      data = JSON.parse(s);
    } catch (err) {}

    if (data != null &&
        data.a != null &&
        data.a.b != null &&
        typeof data.a.b.c === 'string') {
      let x = parseFloat(data.a.b.c);
      if (x === x) {
        return x;
      }
    }
    return null;
  };

  const f2 =
  R.pipe(S.parseJson,
         R.chain(S.gets(['a', 'b', 'c'])),
         R.filter(R.is(String)),
         R.chain(S.parseFloat),
         S.fromMaybe(null));
Note that in the first function we have an unsafe expression,

  data.a.b.c
which we must guard with null/undefined checks. Unsafe expressions can easily get out of sync with their corresponding guards.

We can apply functional programming concepts to JavaScript code to obviate the need for null/undefined checks. The fact that we can't have all the benefits of FP in JS shouldn't dissuade us from taking advantage of the ideas which are applicable.


Less as a real argument than as devil's advocate, here's a shorter non-library version:

   function f1(s) {
      try {
         let data = JSON.parse(s);
         let x = parseFloat(data.a.b.c.substr(0));
         if (x === x)
            return x;
      } catch(e) {}
      return null;
   }
...ok, it's a bit golfy, and in JavaScript you don't get much control over exception catching. But in general, exceptions can be used like an implicit Maybe/Either monad, just as mutability is an implicit IO monad.

(Also, you picked an odd task - it's unusual to expect a float to be represented as a string in a JSON object, and a check that rejects NaN but accepts weird floats like Infinity is not terribly useful.)


It's a contrived example, certainly.

Your counterexample is informative. I hadn't thought of exceptions in this way. The downside of putting everything in a `try` block, of course, is that we'll potentially catch exceptions arising from a bug in our code which should crash our program.


Food for thought David, thanks!


There's an off-by-one error in this thread's title. ;)



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: