It's not nasty :) It's about cultural differences :)
In the 70s/80s, dynamic languages were much more present than in the past 20
years.
People understood the difference between interpretation vs code packaging
for production use.
Suspending evaluation at packaging time of some expressions is ok,
especially if you have side effects like connecting to an application database.
Who would want to that at build time ?
It's a (little) price to pay to get the best of both worlds, a REPL with
dynamic evaluation,
the ability to get your code verified before run time by the compiler and
allowing you to deliver runnable code without source code with a faster
startup time.
Not including the ability to patch a living process ... yeah !
I work with near like embedded systems in Clojure. We deliver AOT all the way
in production.
AOT has a bad reputation for reasons that leave me expressionless.
I understand the dev. reasons for avoiding it but when it's time to package for
production
it has a definite value.
Luc P.
> Much clearer now :) Never heard of that *compile-files* var. Having to
> resort to it looks pretty nasty anyway - I'd rather refactor my code
> instead.
>
> Thanks for the answer Luc!
>
> On Thu, Feb 28, 2013 at 2:44 AM, Softaddicts
> <lprefonta...@softaddicts.ca>wrote:
>
> > Of course, the expression needs to be evaluated at runtime only :)
> > Presently, your jetty server gets started just after the expression is
> > compiled.
> >
> > When you want to defer evaluation at runtime when generating compiled code
> > ahead of time, you need to wrap expressions like these with this:
> >
> > (def server (when-not *compile-files* (jetty/...
> >
> > This will defer evaluation of the expression when the code actually runs,
> > not after it got compiled.
> >
> > Remember, expressions are compiled then evaluated immediately.
> > Be cautious, you can get stuff started this way while building your
> > targets.
> >
> > It's unlikely that you want this to happen...
> >
> > Luc P.
> >
> > > So I was playing with AOT for the first time. My main reason to use it is
> > > so the consumer Java code doesn't look so alien / run-timey.
> > >
> > > The thing is, I encountered that the following line causes `lein compile`
> > > to hang:
> > >
> > > (def server (jetty/run-jetty #'app {:port 8000 :join? false}))
> > >
> > > (for those not familiar with Jetty, the expression causes a web server to
> > > launch.)
> > >
> > > I can sort of see why this code represents a fault, from a compiler's
> > point
> > > of view. But OTOH, in e.g. Java it's not that much of a rare practice to
> > > bind a the result of a side-effectful op to a variable definition, right?
> > >
> > > My question is quite simply, why can't the given code compile? It is not
> > > entirely clear to me, as I don't thoroughly understand how Clojure's
> > > compiler works (or any compiler at all, for that matter).
> > >
> > > --
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> > > ---
> > > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > an email to clojure+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> > >
> > >
> > --
> > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
