3 ms·
Is the intended user a Lisp programmer forced to work on a php code base...or a Lisp programmer looking to take advantage of some of php's native server scripti
by mkrecny 16y ago
Is the intended user a Lisp programmer forced to work on a php code base...or a Lisp programmer looking to take advantage of some of php's native server scripting features?
- mahmud 16y agoHAH! I think, strictly, the former. (I actually laughed out loud at this :_)
- mkrecny 16y agoFair enough. I've never programmed in lisp. I just assumed that lisp didn't have native server abstractions like $_REQUEST - and that Pharen may expose those.
- randallsquared 16y agoWhile no or few lisps have that sort of thing baked in natively, they mostly have libraries that expose it, which is arguably better in any case.
- Scriptor 16y agoBoth really, since interop with PHP is pretty easy so you can use those native features in a lispy way.
- Zak 16y agoDo you believe there are or will be good reasons to choose Pharen over Scheme, Common Lisp or Clojure in a situation where one isn't forced in to using a PHP backend? With Clojure, for example, I consider the baked-in concurrency models and data structures very valuable, but haven't had much cause to care that it runs on the JVM.
- Scriptor 16y agoThat's a really good question. The main case I can see is if someone is already familiar with PHP and its deployment and doesn't want to learn another language/platform. It might also be useable for basic scripting tasks (the compiler has an --executable flag that adds a PHP hashbang to the top of a script). Other than that Pharen is still pretty new and nowhere near the same level as mature lisps. Making debugging and interop with 3rd party libraries easier are the main long-term goals, so maybe after that it'll be at least a little viable.