<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 7/12/2016 3:36 PM, Warren Young
      wrote:<br>
    </div>
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">On Jul 12, 2016, at 3:15 PM, John J. McDermott, CPLP <a class="moz-txt-link-rfc2396E" href="mailto:jjm@jkintl.com"><jjm@jkintl.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">Do you know a strong functional programming language?
</pre>
        </blockquote>
        <pre wrap="">Yeah. I haven't found them valuable for "production" software, but I have used them.
</pre>
      </blockquote>
      <pre wrap="">
Take a look at F#.  It’s OCaml with the sharp corners and ugly bits knocked off.  Either of those is more accessible than Erlang or Haskell.

If its Microsoft origin bothers you, it’s completely open source, and runs just fine on OS X, Linux, FreeBSD, etc.:

  <a class="moz-txt-link-freetext" href="http://fsharp.org/">http://fsharp.org/</a></pre>
    </blockquote>
    OK. Will.<br>
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">These languages teach you the value of thinking of functions in the mathematical sense, which is that any function called with a given set of arguments should always return the same result.  Another way of saying the same thing is that functions should not have side effects.
</pre>
        </blockquote>
        <pre wrap="">I completely agree. I detest side-effects.
</pre>
      </blockquote>
      <pre wrap="">
That’s easy to say, but up-thread you were talking about DBMSes.  Except for SELECT and some of the built-in function calls, a SQL DBMS is nothing but side-effects.</pre>
    </blockquote>
    Ummm, I didn't mention SQL. BUT, sometimes software has to interact
    with the work of others.
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
(It amuses me when people talk about Erlang as a “pure” FP language when it ships with Mnesia, a disk-backed in-RAM DBMS, which amounts to a global variable store.  Talk about side-effects!)

Therefore, we practical software developers should not talk about eliminating side-effects, as the ivory tower types like to do, but instead talk about carefully walling off the places in our code where that happens, so that we can predict from the outside where such a thing is likely to occur.</pre>
    </blockquote>
    Agreed!
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">I want:
<a class="moz-txt-link-abbreviated" href="http://www.mysite.com">www.mysite.com</a> to behave in a way that a user would expect a website to behave: forms, nice view, etc.
<a class="moz-txt-link-abbreviated" href="http://www.mysite.com/db/table1">www.mysite.com/db/table1</a> or whatever to behave in a manner a JSON user would expect. I don't want different names.
</pre>
      </blockquote>
      <pre wrap="">
But you do have different names, which is good.  Instead of /api as I was suggesting, you have segregated the JSON/DBMS stuff under /db.</pre>
    </blockquote>
    Precisely. I should have included the example in my first message to
    avoid confusion. Sorry.
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
I still prefer /api, since I don’t see any particular reason to declare that I’m using a DBMS, but please yourself.</pre>
    </blockquote>
    That was only an example. It could be a physical system or other
    data source. I chose a db to make it easier to discuss. /api is
    fine. The point is (and that's why I suggested ignoring the names),
    is that I want two behaviors with one hostname and different routes.
    Based on your comment above, you see that as two names, so I
    understand your point. I think we agree on substance.<br>
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Are you suggesting I need (ignoring the actual names) <a class="moz-txt-link-abbreviated" href="http://www.mysite.com">www.mysite.com</a> and json.mysite.com?
</pre>
      </blockquote>
      <pre wrap="">
You could do that, too, though I’m not immediately clear on how you’d integrate name-based virtual hosting with Dancer.</pre>
    </blockquote>
    I don't want that, I just wanted to clarify.
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
(I’m assuming you meant both of those to resolve to the same host.  If not, then you’re talking about distributed computing, which adds a further layer of complexity.)</pre>
    </blockquote>
    Yes, on the same (virtual) host. I was just trying to clarify, as I
    noted.
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">To drag this back onto the topic of this particular thread, it is immaterial in my view whether the values passed to the Dancer route come from the URL’s query parameters, are defined as part of the route, or are passed in via a POST call in the request body.  Parameters are parameters, and a properly-written Dancer route handler should return the same data regardless of the exact mechanism used to pass those parameters.

</pre>
        </blockquote>
        <pre wrap="">Hmmm. I don't want the HTML page to have to be JSON. I want a more conventional form use (although it could be JSON).
</pre>
      </blockquote>
      <pre wrap="">
I think you might want to look at Angular and other SPA frameworks, then.</pre>
    </blockquote>
    Well, I've worked with Angular. I don't really like it. I could use
    a client framework, but the data I used in a real implementation of
    this didn't need a complex framework (I used datatables.js).<br>
    <br>
    --john<br>
    <blockquote
      cite="mid:565CCEFA-A2DD-4EAB-8A31-87E0B9C645DC@etr-usa.com"
      type="cite">
      <pre wrap="">
_______________________________________________
dancer-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dancer-users@dancer.pm">dancer-users@dancer.pm</a>
<a class="moz-txt-link-freetext" href="http://lists.preshweb.co.uk/mailman/listinfo/dancer-users">http://lists.preshweb.co.uk/mailman/listinfo/dancer-users</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      John J. McDermott, CPLP<br>
      Learning and Performance Consultant<br>
      jjm at jkintl.com 575/737-8556<br>
      Check out my <a href="http://cybersecurity.learningtree.com">
        security blog posts</a><br>
      Add an A for the Arts To STEM and get STEAM and a strong engine to
      move forward. </div>
  </body>
</html>